Hallo! Ich brand neu in dem Gebiet (21 Jahre alt, E-Techniker) und würde Gerne (Habe hier dazu was in einem anderen Thread aufgeschnappt) µC STM32 mit Qt-Visualisierung programmieren (Ja das Weg ist lang. Starten möchte ich trotzdem). Gibt es eine Möglichkeit zu programmieren und simulieren ohne Hardware zuhause zu haben (Ja, Hardware wird noch besorgt), ich möchte erstmal ohne starten aber dennoch etwas "sehen". Danke!
Die Simulationsprogramme sind weitgehend vom Markt verschwunden, weil aktuelle Mikrocontroller eine Debugger Schnittstelle haben, mit der du qasi zugucken kannst, was im Chip passiert. Soweit ich weiß, gibt es für ARM basierte Controller wie den STM32 keine Simulatoren. Kaufe dir ein Nucleo Board für ca. 15 Euro, dann hast du etwas zum loslegen. Siehe http://stefanfrings.de/mikrocontroller_buch2/index.html Was meinst du mit "Qt visualisierung"?
ErsterBeitrag schrieb: > Gibt es eine Möglichkeit zu programmieren und simulieren ohne Hardware > zuhause zu haben (Ja, Hardware wird noch besorgt), ich möchte erstmal > ohne starten aber dennoch etwas "sehen". Man kann diese beiden Dinge (µC und Qt) erst mal getrennt von einander lernen. Qt geht auch auf dem PC, und µC-Entwicklung kann man auch erst mal ohne das ganze graphische machen. Wie gut sind denn deine C++-Kenntnisse? Bevor du so was anfängst, solltest du zunächst dort einigermaßen sattelfest sein. Dann mal Qt auf dem Computer benutzen und dann mal mit µCs allgemein anfangen. Wenn das alles jeweils klappt, dann kannst du das zusammenführen.
Hallo Danke für die Antworten. Ich denke ich kann etwas proggen. Ich hab etwas Klassen und structs in c++ benutzt, eigene Header, funktionen, exeption handling, if, while, for, do-while, switch-case, streams. mit cpp-11. allerdings alles für die Console. Rolf M. schrieb: > Man kann diese beiden Dinge (µC und Qt) erst mal getrennt von einander > lernen. Qt geht auch auf dem PC, und µC-Entwicklung kann man auch erst > mal ohne das ganze graphische machen. Ich hab mich kurz auf der Qt-Webpage informiert. Da werden ein paar Boards empfohlen und man kann sich das graphische auch direkt auf dem PC-Anzeigen lassen. Was mich etwas verwirrt ist ob ich jetzt zwei IDEs brache oder alle über die Qt-IDE machen kann? Gibt es da einen guten deutschen Beginner-Guide? Ich kann zwar recht gut englisch... muss aber gestehen, dass neues auf Englisch zu beginnen für mich sehr mühsam ist.
ErsterBeitrag schrieb: > Was mich etwas verwirrt ist ob ich jetzt zwei IDEs brache oder alle über > die Qt-IDE machen kann? Leider hast du meine Frage nicht beantwortet, was du mit "Qt visualisieren" meinst. Wenn du den PC Programmieren möchtest, dann dürfte die Qt Creator IDE für den Einstieg hilfreich sein. Qt kann man aber auch mit anderen IDE oder ohne IDE verwenden. Du hattest nach einem Tutorial für Qt gefragt: http://stefanfrings.de/qt_lernen/index.html (M)ein Tutorial für STM32 habe ich dir weiter oben genannt. Die STM32 Mikrocontroller kannst du auch mit der Qt Creator IDE programmieren. Allerdings muss man dazu eine ganze Menge konfigurieren. Für den Anfang würde ich zur STM32 Cube IDE raten, weil die passend vorkonfiguriert ist und Projekte passend zum Mikrocontroller generiert. Möchtest du Qt auf dem Mikrocontroller verwenden? Das ist schon sehr speziell. Mache das erst, wenn du sowohl mit Qt (auf dem PC) als auch mit der Programmierung des Mikrocontrollers vertraut bist. Weil: Zu viele Baustellen gleichzeitig führen selten zum Erfolg. Langer Rede kurzer Sinn: Ja, fange besser mit zwei getrennten IDEs an. Wenn es dir darum geht, grafische Elemente auf einem Display darzustellen, dann schau Dich mal nach aktiven Displays mit integriertem Controller um. Zum Beispiel von der Marke Nextion. Falls es um einfache Formen wie Linien, Kreise, Text und Bilder geht: Dafür braucht man kein Qt. Dafür gibt es zahlreiche um Welten schlankere Bibliotheken zum freien Download.
Stefan ⛄ F. schrieb: > ErsterBeitrag schrieb: >> Was mich etwas verwirrt ist ob ich jetzt zwei IDEs brache oder alle über >> die Qt-IDE machen kann? > > Leider hast du meine Frage nicht beantwortet, was du mit "Qt > visualisieren" meinst. Danke für die Tipps. Ich dachte das wäre klar rüber gekommen, sorry. Ich möchte Qt-Visis für MCUs nutzen, ja.
ErsterBeitrag schrieb: > Qt-Visis Kenn ich nicht, Google auch nicht. Hast du mal einen Link? Achte auf die Systemanforderungen. Qt bewegt sich traditionell in Größenordnungen von Megabytes, während die meisten Mikrocontroller in der Liga darunter (kilobytes) zu hause sind Außerdem benutzt Qt viel dynamische Speicherverwaltung, was ohne MMU zu einem Krampf ausartet. Die meisten Mikrocontroller haben keine MMU.
Stefan ⛄ F. schrieb: > Wenn es dir darum geht, grafische Elemente auf einem Display > darzustellen, dann schau Dich mal nach aktiven Displays mit integriertem > Controller um. Zum Beispiel von der Marke Nextion. > > Falls es um einfache Formen wie Linien, Kreise, Text und Bilder geht: > Dafür braucht man kein Qt. Dafür gibt es zahlreiche um Welten schlankere > Bibliotheken zum freien Download. Welche beispielsweise? Ich weiß, dass es mittlerweile APIs wie Sand am Meer gibt aber Qt ist derzeit sehr beliebt... unabhängig davon finde ich das persönlich sehr interessant und die Darstellungsweise absolut überragend.
Stefan ⛄ F. schrieb: > ErsterBeitrag schrieb: >> Qt-Visis > > Kenn ich nicht, Google auch nicht. Hast du mal einen Link? Visi = Visualisierung.
Stefan ⛄ F. schrieb: > Leider hast du meine Frage nicht beantwortet, was du mit "Qt > visualisieren" meinst. Und auch, welche Art Anwendungen auf dem MC überhaupt laufen sollen. Qt stellt ja doch sehr hohe Anforderungen. Vermutlich wird auch ein OS benötigt, was dann die Echtzeitfähigkeiten des MCs schon erheblich einschränkt und auch die direkten Hardwarezugriffe. Für Steuerungen (z.B. PID-Regelungen) kann das massive Probleme bereiten.
ErsterBeitrag schrieb: > Welche beispielsweise? Ich weiss nichts über deine Anwendung und Hardware. Es macht daher wenig Sinn, hier eine unpassende Empfehlung zu geben. Ein Kandidat wäre z.B. die Adafruit GFX Library, die in der Regel mit einer LCD Library kombiniert benutzt wird.
Das normale Qt läuft jedenfalls nicht auf Mikrocontrollern. Die kleinsten Geräte, die dazu passen sind Raspberry Pi und Smartphones. Die basieren aber auf SOC, nicht auf Mikrococontroller. Das ist ein ganz anderer Fachbereich. Mir ist bekannt, dass es in der Vergangenheit mehrere Ansätze gab, Qt für Mikrocontroller abzuspecken. Ich kenne allerdings kein solches Projekt, dass über eine Machbarkeitsstudie hinaus gekommen ist.
Stefan ⛄ F. schrieb: > ErsterBeitrag schrieb: >> Welche beispielsweise? > > Ich weiss nichts über deine Anwendung und Hardware. Es macht daher wenig > Sinn, hier eine unpassende Empfehlung zu geben. Ein Kandidat wäre z.B. > die Adafruit GFX Library, die in der Regel mit einer LCD Library > kombiniert benutzt wird. Ganz naiv gefragt: Warum ist das wichtig zu wissen für was? Ich verstehe das Technikerproblem dahinter. Wenn ich einen Motor ansteuern will, will ich eine "sexy"-visi dazu. Wenn ich LED-Farben manuel wechseln will -> "sexy"-visi... Heizungssteuerung... Egal welche steuerbare Funktion, ich möchte es im Qt-Stil bedienen. Das ist das Ziel. Deshalb frage ich hier nach dem Weg. :)
ErsterBeitrag schrieb: > Qt ist derzeit sehr beliebt... Nicht auf Mikrokontrollern, lass dir das nicht einreden. Qt ist was für Desktops. Wenn du das trotzdem unbedingt willst bist du hier nicht richtig, suche unter PC-Programmierung, da gibt es Threads über Qt. Georg
ErsterBeitrag schrieb: > > Das ist das Ziel. Deshalb frage ich hier nach dem Weg. :) Es kann auch gerne ein Workaround ala "Zentrage Steuereinheit gibt befehle an verschiedene MCUs weiter" sein.
georg schrieb: > ErsterBeitrag schrieb: >> Qt ist derzeit sehr beliebt... > > Nicht auf Mikrokontrollern, lass dir das nicht einreden. Qt ist was für > Desktops. Wenn du das trotzdem unbedingt willst bist du hier nicht > richtig, suche unter PC-Programmierung, da gibt es Threads über Qt. > > Georg Hi! Das sieht hier nicht so aus. :/ https://www.qt.io/migrating-from-mpus-to-mcus
Stefan ⛄ F. schrieb: > Möchtest du Qt auf dem Mikrocontroller verwenden? Das ist schon sehr > speziell. Mache das erst, wenn du sowohl mit Qt (auf dem PC) als auch > mit der Programmierung des Mikrocontrollers vertraut bist. Weil: Zu > viele Baustellen gleichzeitig führen selten zum Erfolg. Genau das war auch die Idee hinter meiner Antwort. Du hast es aber klarer formuliert. Stefan ⛄ F. schrieb: > Achte auf die Systemanforderungen. Qt bewegt sich traditionell in > Größenordnungen von Megabytes, während die meisten Mikrocontroller in > der Liga darunter (kilobytes) zu hause sind Ja, eine Qt-GUI wird auf einem µC in der Regel massiv mehr Ressourcen brauchen als alle anderen Funktionalitäten zusammen. > Außerdem benutzt Qt viel dynamische Speicherverwaltung, was ohne MMU zu > einem Krampf ausartet. Die meisten Mikrocontroller haben keine MMU. Warum sollte für dynamischen Speicher eine MMU nötig sein? Die ist eigentlich nur nötig, wenn man Prozesse mit separaten Adressräumen braucht. Peter D. schrieb: > Stefan ⛄ F. schrieb: >> Leider hast du meine Frage nicht beantwortet, was du mit "Qt >> visualisieren" meinst. > > Und auch, welche Art Anwendungen auf dem MC überhaupt laufen sollen. > Qt stellt ja doch sehr hohe Anforderungen. Vermutlich wird auch ein OS > benötigt, was dann die Echtzeitfähigkeiten des MCs schon erheblich > einschränkt und auch die direkten Hardwarezugriffe. Für Steuerungen > (z.B. PID-Regelungen) kann das massive Probleme bereiten. Es gibt inzwischen auch eine Qt für bare-metal-Programmierung, also für µCs ohne Betriebssystem. Stefan ⛄ F. schrieb: > Das normale Qt läuft jedenfalls nicht auf Mikrocontrollern. Die > kleinsten Geräte, die dazu passen sind Raspberry Pi und Smartphones. Die > basieren aber auf SOC, nicht auf Mikrococontroller. Das ist ein ganz > anderer Fachbereich. > > Mir ist bekannt, dass es in der Vergangenheit mehrere Ansätze gab, Qt > für Mikrocontroller abzuspecken. Ich kenne allerdings kein solches > Projekt, dass über eine Machbarkeitsstudie hinaus gekommen ist. Inzwischen gibt's das ganz offiziell von der Qt Company. https://www.qt.io/product/develop-software-microcontrollers-mcu Und speziell für STM32: https://www.qt.io/microcontrollers-st
:
Bearbeitet durch User
ErsterBeitrag schrieb: > Ganz naiv gefragt: Warum ist das wichtig zu wissen für was? Weil nicht jede Lösung zum Problem passt. Und es gibt viele Lösungen. Sehr viele sogar. Ich kenne nur einen winzigen Bruchteil davon.
Rolf M. schrieb: > Inzwischen gibt's das ganz offiziell von der Qt Company. > https://www.qt.io/product/develop-software-microcontrollers-mcu > Und speziell für STM32: > https://www.qt.io/microcontrollers-st SO wie ich das sehe ist das ganze so neu, dass man sich selbst reinfuchsen muss. Also der Weg über separate Tutorials für STM32 und Qt. ... Na dann los.
Rolf M. schrieb: > Warum sollte für dynamischen Speicher eine MMU nötig sein? Weil Systeme ohne MMU unter Fragmentierung des Heap leiden. Die MMU alleine löst das Problem zwar nicht, ist aber Voraussetzung für alle aktuellen Betriebssysteme, die wirksame Gegenmaßnahmen enthalten.
ErsterBeitrag schrieb: > Ich ... würde ... gerne ... STM32 mit Qt-Visualisierung programmieren Du könntest damit anfangen, ein STM32 Board mit einem Tablet zu verbinden. Den STM32 programmierst du mit der STM32 Cube IDE, das Tablet programmierst du mit Qt Creator. Die Kommunikation dazwischen geht über USB CDC oder Bluetooth. So hast zu zwei weitgehend unabhängige Baustellen mit einer relativ simplen Kommunikation dazwischen. Die Variante, den Mikrocontroller selbst mit Qt zu programmieren, kannst du dir für später aufheben.
Wie sieht es eigentlich mit der Lizenz von Qt auf Mikrocontrollern aus? Soweit ich verstanden habe, muss man die kostenlose Version von Qt dynamisch linken. Das wird wohl kaum gehen, ohne Betriebssystem mit Filesystem. Oder doch? Kennt sich jemand damit aus?
> Mir ist bekannt, dass es in der Vergangenheit mehrere Ansätze gab, Qt > für Mikrocontroller abzuspecken. Ich kenne allerdings kein solches > Projekt, dass über eine Machbarkeitsstudie hinaus gekommen ist. Das liegt aber an dir. :-) Es gab mal eine ganze Reihe von Sharp Zaurus deren Grafikoberflaeche darauf basiert haben. (Embedix) Das lief so vor 15-20Jahren auf ARM Controllern mit etwa 200Mhz. (Und war ziemlich cool!) Ein weiteres Beispiel dafuer war der erste Chumbi den ich auch in Qt programmieren konnte. Aber natuerlich waren das damals nicht wirklich Microcontroller. Mittlerweile haben Microcontroller aber eine Leistungsklasse erreicht wo das langsam denkbar wird. Leider ist Qt natuerlich in den letzten 20Jahren auch nicht gerade schlanker geworden. Trotzdem versucht die Firma es derzeit mal wieder in dem Bereich Fuss zu fassen. Das ist aber sicher nichts fuer Anfaenger und fuer viele Probleme die man mit Microcontrollern loesst ist es auch Unsinn. (Timing,Zeitverhalten) Gleichwohl ist es nicht komplett uninteressant. Ich denke in 5-10Jahren wenn dann 400-500Mhz Microcontroller mit mehreren Kernen normal werden, wird das interessant werden. Trotzdem wuerde ich einem Anfaenger dringendst empfehlen einfacher anzufangen! Beachtet das viele Leute bereits heutige Systeme intellektuell nicht mehr durchdringen und dann lieber Kruecken wie Python oder Lua verwenden. Also nicht gleich zu gross anfangen sonst bleibt man auf der Strecke. Olaf
Olaf schrieb: > Das ist aber sicher nichts fuer Anfaenger und fuer viele Probleme die > man mit Microcontrollern loesst ist es auch Unsinn. > (Timing,Zeitverhalten) Gleichwohl ist es nicht komplett uninteressant. > Ich denke in 5-10Jahren wenn dann 400-500Mhz Microcontroller mit > mehreren Kernen normal werden, wird das interessant werden. > > Trotzdem wuerde ich einem Anfaenger dringendst empfehlen einfacher > anzufangen! > Beachtet das viele Leute bereits heutige Systeme intellektuell nicht > mehr durchdringen und dann lieber Kruecken wie Python oder Lua > verwenden. Also nicht gleich zu gross anfangen sonst bleibt man auf der > Strecke. > > Olaf Hi Olfa. Die zeit des "Alleserfassende" ist überall vorbei. In jedem Gebiet. In der Mathematik schon lange. Man muss das anders betrachten. Das sind teil alles unterschiedliche Berufe. Einmal die, die Systeme schaffen und einmal die Anwender. Aber selbst die Schaffenden sind gleichzeitig Anwender von dingen, die sie nicht erfassen können! Kleines Qt beispiel. Qt-Visualisierung-Designs sind mit Photoshop erstellt, con Designerne, die ganrichts mit Elektronik am Hut haben. Diese nutzen aber dingen (Das Programm) welche von Softwareentwicklern erstellt wurden. Diese Softwareentwickler nutzen wiederum PCs zum schreiben der Software, also Hardware. Dazwischen kommen noch die Compiler-Entwickler... usw.usw. Mein Prof. sagte schon Damals, dass ein Leben nicht reicht alles der Elektrotechnik zu erschlagen. Er hat recht. Es kommt drauf an in welcher Tiefe des Verständnisses es keinen Sinn mehr für die Anwendung macht und man sich verrennt. LG.
es gibt noch lvgl und touchGFX. lvgl ist open source: https://github.com/lvgl/lvgl https://lvgl.io/ Hat hauptsächlich ein Ungar in über 10 Jahren entwickelt, es ist mittlerweile richtig gut geworden. Kann leicht auf verschiedene µC portiert werden, ist in C geschrieben aber mit Widgets als Objekten. Es gibt keinen Wysiwyg Editor, aber dafür eine Simulation. Da kann man den µC Code bzgl. GUI testen. Die Widgets können relativ zueinander positioniert werden, das ist auch ein guter Ansatz wenn die GUI auf verschiedenen Auflösungen laufen soll. touchGFX ist kommerzieller, man kann es zwar mittlerweile kostenlos nutzen, aber nur weil ST es sich gekrallt hat und nur noch für STM verfügbar ist. Vorher gab es das auch für NXP und andere. Es hat einen Wysiwyg Editor, aber der war auch dringend nötig. touchGFX arbeitet mit einem MVC Modell, da müssen eine Menge Klassen für eine einfache View instanziiert werden. Ohne Editor war das sehr aufwändig. Weil die µC sehr schnell geworden sind, sehen die GUI mit Animation sehr fluffig aus, schon so wie man es vom Smartphone gewohnt ist.
Johannes S. schrieb: > es gibt noch lvgl und touchGFX. > lvgl ist open source: > https://github.com/lvgl/lvgl > https://lvgl.io/ Das sieht auch sehr nice aus!
> Das sieht auch sehr nice aus! Und lvgl ist ungefaehr 10-100x einfacher als Qt embedded. Ich hab z.B etwa 3-4h gebraucht mir einen eigenen Emulator fuer lvgl in Qt zu schreiben um einem Problem nachzugehen weil ich gar nicht wusste das es einen anderen Emulator gibt. :) > Kleines Qt beispiel. Qt-Visualisierung-Designs sind mit Photoshop Brauchst du mir nicht zu erklaeren. Ich arbeite in der Entwicklung. Bei mir laufen aber drei Mikcrocontroller, ein LCD und eine sehr komplexe Messhardware mit 3mA. Wer mit den ganzen Schickimickitools arbeitet wird eher 300mA und einen Kuehlkoerper brauchen. Und ich staune auch jedesmal am Geldautomat wie 1s nachdem ich meine 4-stellige Pin eingegeben habe das erste Sternchen im Display auftaucht. Aus meiner Sicht waere es daher dringend wuenschenswert wenn sich der Nachwuchs mal auf den Hosenboden setzt und etwas gruendlich lernt. .-) Olaf
Stefan ⛄ F. schrieb: > Soweit ich verstanden habe, muss man die kostenlose Version von Qt > dynamisch linken. Nein. Die kostenlose Version steht unter LGPL. Das heißt, wenn man das Programm weitergeben will, muss man demjemigen, dem man es gibt, die Möglichkeit geben, das Programm mit einer eigenen z.B. von ihm selbst modifizierten Qt zu nutzen. Dynamisches Linken ist auf dem PC die einfachste Methode, das zu gewährleisten (eben durch Austausch der Qt-Libs), aber man könnte z.B. auch die Object-Files weitergeben, so das der Abnehmer das Programm selbst linken kann. Und generell gilt es sowieso nur, wenn man das Programm überhaupt weitergeben will. Ansonsten kann man damit eh machen, was immer man möchte. Olaf schrieb: > Ich denke in 5-10Jahren wenn dann 400-500Mhz Microcontroller mit > mehreren Kernen normal werden, wird das interessant werden. Die sind ja heute schon nichts ungewöhnliches mehr. Meist ist für Qt eher der Speicher zu klein.
:
Bearbeitet durch User
> Die sind ja heute schon nichts ungewöhnliches mehr. Naja, ich weiss das es das gibt. Aber im Alltag ist es IMHO noch nicht ganz angekommen. Bei mir liegen die Controller mittlerweile so bei 50-80Mhz, laufen die meiste Zeit mit 1Mhz und werden nur kurz mal hochgefahren wenn es nicht anders geht. > Meist ist für Qt eher der Speicher zu klein. Das kommt noch obendrauf. Aber ich denke wenn der naechste Die shrink im Microcontrollerbereich kommt wird sowas wie Qt embedded sinnvoll werden. Vorausgesetzt es gibt noch einen zweiten Core der sich um hartes Timing kuemmern kann. Olaf
Stefan ⛄ F. schrieb: > Rolf M. schrieb: >> Warum sollte für dynamischen Speicher eine MMU nötig sein? > > Weil Systeme ohne MMU unter Fragmentierung des Heap leiden. Die MMU > alleine löst das Problem zwar nicht, ist aber Voraussetzung für alle > aktuellen Betriebssysteme, die wirksame Gegenmaßnahmen enthalten. Magst du mal erläutern wie eine MMU der Fragmentierung des Heap verhindert bzw. welche Gegenmaßnahmen eine MMU ermöglicht die ein System ohne nicht ergreifen kann?
Da du nach Simlatoren/Emulatoren gefragt hast: Schaue dir das Renode Projekt an. Es müsste auch optimal LCDs geben, und die meisten STM32 sind vorhanden.
Μαtthias W. schrieb: > Magst du mal erläutern wie eine MMU der Fragmentierung des Heap > verhindert bzw. welche Gegenmaßnahmen eine MMU ermöglicht die ein System > ohne nicht ergreifen kann? Wie gesagt ist es nicht die MMU, die das Problem löst. Aber alle mir bekannten Betriebssysteme, die kein Problem mit fragmentiertem Heap haben, benötigen eine MMU. Das ist so wie Geld keine schönen Häuser baut, aber jeder mit einem schönen Haus braucht Geld.
Stefan ⛄ F. schrieb: > Μαtthias W. schrieb: >> Magst du mal erläutern wie eine MMU der Fragmentierung des Heap >> verhindert bzw. welche Gegenmaßnahmen eine MMU ermöglicht die ein System >> ohne nicht ergreifen kann? > > Wie gesagt ist es nicht die MMU, die das Problem löst. Aber alle mir > bekannten Betriebssysteme, die kein Problem mit fragmentiertem Heap > haben, benötigen eine MMU > > Das ist so wie Geld keine schönen Häuser baut, aber jeder mit einem > schönen Haus braucht Geld. Typischerweise läuft die Verwaltung des Heaps eines Prozess komplett im Userspace und damit ohne Zugriff auf die MMU. Deiner Meinung nach gibt es seitens des OS also noch einen Mechanismus der gegen Fragmentierung hilft. Würde mich immer noch interessieren welcher das ist.
ErsterBeitrag schrieb: > Gibt es eine Möglichkeit zu programmieren und simulieren ohne Hardware > zuhause zu haben (Ja, Hardware wird noch besorgt), ich möchte erstmal > ohne starten aber dennoch etwas "sehen". Und es muß als Allererstes ein STM32 sein? Und dort soll auch noch per QT etwas zum Angucken (Visualisieren) sein? Also ein buntes TFT? Und du stehst in Sachen µC noch ganz am Anfang, sowohl wissensmäßig als auch bauteilemäßig? Ich sehe da leichte Schwierigkeiten. Wie wäre es, wenn du: a) QT am PC benutzt und dort visualisierst was du magst oder b) erstmal mit dem Kennenlernen von µC anfängst und dazu nicht als allererstes einen Cortex M hernimmst, sondern etwas kleiner anfängst? oder der eher haarige Weg: c) dich in die Cortex Chips einliest (kann ja STM32 sein, LPCxxx von NXP wären da auch was), dich in Verwendung von EDA (vulgo Leiterplattenprogramme) übst und dir dann überlegst, wie du mit so etwas eine Leiterplatte realisierst, wo neben dem µC auch noch all das drauf ist, was du für ein TFT so benötigst? Mein Rat: nicht alles auf einmal, sondern das Gesamtproblem aufteilen in mehrere kleinere Probleme und die dann der Reihe nach angehen. Ach ja: und eine eigentliche Zielsetzung sollte es eigentlich auch geben, also ein Zweck, dem das µC-System nebst der von dir dort realisierten Visualisierung per QT am Ende dienen soll. W.S.
Μαtthias W. schrieb: > Deiner Meinung nach gibt > es seitens des OS also noch einen Mechanismus der gegen Fragmentierung > hilft. Würde mich immer noch interessieren welcher das ist. So genau kenne ich mich da nicht aus. Ich weiß, dass Heap Fragmentierung sowohl bei Windows 98 als auch bei Linux zu dieser Zeit noch ein großes Thema war. Aber bei beiden Betriebssystemen wurde die Situation durch Änderungen am Kernel erheblich verbessert. Hier gibt es ein paar vage Informationen dazu: https://www.linux-magazine.com/Issues/2015/179/Kernel-News https://savvinov.com/2019/10/14/memory-fragmentation-the-silent-performance-killer/ https://www.uninformativ.de/blog/postings/2017-12-23/0/POSTING-en.html
Ich empfehle dir STM32F429 DiscoveryKit, statt QT erstmal TouchGFX https://www.st.com/content/st_com/en/products/evaluation-tools/product-evaluation-tools/mcu-mpu-eval-tools/stm32-mcu-mpu-eval-tools/stm32-discovery-kits/32f429idiscovery.html https://www.st.com/content/st_com/en/search.html#q=cube%20mx-t=tools-page=1 https://www.st.com/content/st_com/en/products/embedded-software/mcu-mpu-embedded-software/stm32-embedded-software/stm32cube-expansion-packages/x-cube-touchgfx.html
Stefan ⛄ F. schrieb: > Μαtthias W. schrieb: >> Deiner Meinung nach gibt >> es seitens des OS also noch einen Mechanismus der gegen Fragmentierung >> hilft. Würde mich immer noch interessieren welcher das ist. > > So genau kenne ich mich da nicht aus. Ich weiß, dass Heap Fragmentierung > sowohl bei Windows 98 als auch bei Linux zu dieser Zeit noch ein großes > Thema war. Aber bei beiden Betriebssystemen wurde die Situation durch > Änderungen am Kernel erheblich verbessert. > > Hier gibt es ein paar vage Informationen dazu: > https://www.linux-magazine.com/Issues/2015/179/Kernel-News > https://savvinov.com/2019/10/14/memory-fragmentation-the-silent-performance-killer/ > https://www.uninformativ.de/blog/postings/2017-12-23/0/POSTING-en.html Da geht's aber immer nur um die Speicherverwaltung vom Kernel selber und nicht um den Heap von Userspace Prozessen.
Μαtthias W. schrieb: > Da geht's aber immer nur um die Speicherverwaltung vom Kernel selber und > nicht um den Heap von Userspace Prozessen. Ja das stimmt wohl. Um den Heap müssen sich die Prozesse (zumindest bei Linux) immer noch selber kümmern.
Stefan ⛄ F. schrieb: > Μαtthias W. schrieb: >> Da geht's aber immer nur um die Speicherverwaltung vom Kernel selber und >> nicht um den Heap von Userspace Prozessen. > > Ja das stimmt wohl. Um den Heap müssen sich die Prozesse (zumindest bei > Linux) immer noch selber kümmern. Das ist auch besser so. Ein syscall für jedes malloc wäre für die Performance nicht sonderlich förderlich.
W.S. schrieb: > ...dich in Verwendung von EDA (vulgo > Leiterplattenprogramme) übst und dir dann überlegst, wie du mit so etwas > eine Leiterplatte realisierst, wo neben dem µC auch noch all das drauf > ist, was du für ein TFT so benötigst? Moin. Ich habe Erfahrung. Genau deshalb antworte ich dir. Weil ich nicht verstehe, was ein Leiterplatten-Layouter mit uC Programmierung zutun haben soll. Ich hab etliches Designt und kenne mich sogar mit ESD und co aus aus. Ich habe ET fertig studiert und kann dennoch mit stolzer Brust sagen, dass ich von uC Programmierung keine Ahnung habe. Ich kann dir auch sagen warum: Das eine hat mit dem anderen garnichts zutun. Ich verstehe die Leute nicht, die meine man müsse für die Benutzung der Sprache verstanden haben wie die Grammatik funktioniert. Wäre das so, würde kein Kind jemals sprechen. Diese Sitte sollte unbedingt schon während der Lehre zum Techniker/Ingenieur ausgetrieben werden... Weiß ja auch nicht jeder Nutzer wie die LED mittels Bandgab Engineering in ihrer physikalischen Mikrostruktur konstruiert worden ist ... Mfg.
Gruss zum Sonntag Abend Ich bringe hier mal, als Erwähnung , "Eclipse" ein. Einfacher als Qt, das wird ja im Internet als handlich dargestellt, find ich Java GUI und der Java Server lasst sich zu Fuss angehen, incl. Computerfunktionen. Ich meine wenn es nicht zu kompliziert werden soll. Manche die an Eclipse ran gehen, erreichen das aber nicht. Noch einen schönen Abend. Dirk St
Die STM32 Cube IDE ist eine Eclipse IDE mit den für STM32 notwendigen Plugins bereits vorinstalliert. C++ und Qt Unterstützung gibt es für Eclipse wiederum als Plugin. Siehe https://www.linux-magazin.de/ausgaben/2010/01/ordentlich-aufgemotzt/3/ Ich bin allerdings der Meinung, dass die Eclipse IDE besonders für Anfänger verwirrend sein kann. Da wirken alle anderen mir bekannten IDEs deutlich aufgeräumter. Mit der Stabilität der IDE bin ich auch alles andere als zufrieden.
Stefan ⛄ F. schrieb: > Die STM32 Cube IDE ist eine Eclipse IDE mit den für STM32 > notwendigen > Plugins bereits vorinstalliert. > > C++ und Qt Unterstützung gibt es für Eclipse wiederum als Plugin. Siehe > https://www.linux-magazin.de/ausgaben/2010/01/ordentlich-aufgemotzt/3/ > > Ich bin allerdings der Meinung, dass die Eclipse IDE besonders für > Anfänger verwirrend sein kann. Da wirken alle anderen mir bekannten IDEs > deutlich aufgeräumter. Mit der Stabilität der IDE bin ich auch alles > andere als zufrieden. Linux ist auch son Ding, was noch auf meiner Liste steht. Leider bin ich ein armes Kerlchen und der Speicherplatz auf meinem Notebook reicht nicht mehr aus für eine Linux VR :D
ErsterBeitrag schrieb: > Linux ist auch son Ding, Leider .. der Speicherplatz auf meinem > Notebook reicht nicht mehr aus für eine Linux VM Wenn du auf die GUI verzichtest, sollten etwa 4GB reichen. Aber wenn Speicherplatz knapp wird, dann könnte sowohl die STM32 IDE als auch QT Creator zum Problem werden, denn die belegen zusammen mehrere Gigabytes. Falls du einen neuen Rechner kaufst, nimm einen mit 4 CPU Kernen(nicht 2 Kerne + Hyperthreading). Den Unterschied wirst du deutlich merken. Bei Pollin bekommst du gute Business Laptops in dieser Klasse gebraucht für ca. 500€. Kann ich nur empfehlen, wir haben diese Modelle in der Firma, sind alle Top!
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.