Hallo Forum, leider habe ich noch nicht den idealen Einstieg in die STM32 Entwicklung gefunden. Hat jemand einen Tipp für Anfänger mit ein wenig Erfahrung in AVR Assembler und C/C++ Grundkenntnissen? Irgendwann wäre es schön, wenn ich dieses Board nutzen könnte: STM32F7 DISCOVERY STM32F746 TFT LCD STM32 ARM Cortex-M7 Development Board Nur welches Board nehme ich für den Anfang? Da brauche ich auch was gedruckte oder druckbares. Ich lese meistens noch auf Papier. Danke
Reinhard J. schrieb: > Nur welches Board nehme ich für den Anfang? Warum nicht direkt das STM32F7 Discovery? Die "komplizierten" Dinge wie Ethernet, Display, SDRAM musst du ja nicht sofort benutzen. Du kannst damit anfangen, LED's blinken zu lassen oder aufsteckbare Arduino-Shields anzusteuern. Mithilfe von Libraries ist auch die Ansteuerung der o.g. Komponenten keine Zauberei. Im Artikel STM32 sind diverse Tutorials verlinkt. Viele davon beziehen sich zwar nicht direkt auf den STM32F7, aber du kannst das meiste 1:1 übernehmen. Gedrucktes Material gibt es nicht viel, da könntest du den "The Definitive Guide to the ARM Cortex-M3" lesen, der Cortex-M7 unterscheidet sich aus Programmierersicht kaum (hauptsächlich dass er schneller ist).
Danke, das war mir nicht klar, dass ich mit dem STM32F7 auch den Code älterer STM32 weitestgehend laufenlassen kann. Gibt es da auch eine Library zur Erstellung einer GUI oder muss man sich um jeden Pixel selbst kümmern?
:
Bearbeitet durch User
Dr. Sommer schrieb: > Warum nicht direkt das STM32F7 Discovery? Ist das ein Scherz. Reinhard J. schrieb: > mit ein wenig Erfahrung in > AVR Assembler und C/C++ Grundkenntnissen? Hi ich bin gerade auch "gezwungen" das F7 Discovery zu benutzen. Ich habe in letzter Zeit sher intensif mit STM32 gearbeitet, aber auch nicht so lange, dass ich mich nicht mehr an den Einstieg errinern könnte. Mein Tipp an dich: Nö, nein, Nein! einfach nein!! Mit einem F7 machst du ehrlich einfach unglücklich. Mal einen Blick ins Reference Manual geschaut. Der STM32F74/5 ist ein Biest. Mit einem neuen Cortex M7 bist du hier definitv im High-End-Bereich angekommen und ganz falsch als Anfänger. Wieso? -Wie gesagt, wirf mal nen Blick ins Manual, oder schau dir die Clock-Config im Cube an. -Er hat tausende Features die du sicher nicht brauchst und das ganze unnötig kompliziert machen. -Nicht zuletzt hat ST den Standard Peripheral Library Support eingestellt. Meiner Meinung nach eine absolute Schande. Der Ersatz, die HAL-Library, mag vielleicht in Kombination mit Betriebssystemen sehr nützlich sein, und auch der Ansatz mit den Callbacks etc. ist eigentlich geil, ABER für Einsteiger, sowie für Leute die keine High-End-Applikation machen (und damit eigentlich falsch beim F7 sind) ist HAL die Hölle. -Mein Tipp an dich: Fang mit einem F1 an. Als Einsteiger wird das dich genug fordern. Und wenn dich ein F1 krass unterfordert, die Nucleo kosten nur 10 Euronen. Dr. Sommer schrieb: > aber du kannst das meiste 1:1 übernehmen Geeenau, die benutzen ja auch noch die gleichen Treiber wie ältere STM32 Register sind ja auch so auch ähnlich.. Reinhard J. schrieb: > Gibt es da auch eine Library zur Erstellung einer GUI oder muss man sich > um jeden Pixel selbst kümmern? Ich kann dir uGFX empfehlen.
:
Bearbeitet durch User
Hallo Felix, da prallen ja zwei Meinungen aufeinander. Ich bin froh, dass es eine GUI-library gibt. Aufm PC kenne ich wxWidgets und ein wenig auch QT. Betreffen Deine Bedenken auc das STM32F429 DISCO. Da hat man gleich ein Display mit drauf. Man kann es ja erst mal ignorieren. Wenn ich mir damit aber Kummer bei den ersten Schritten einhandele würde ich ein Nucleo nehmen oder was ich hier empfohlen kriege. Danke für die ausführlichen Antworten. Gruß Reinhard
Reinhard J. schrieb: > Nur welches Board nehme ich für den Anfang? Da brauche ich auch was > gedruckte oder druckbares. Ich lese meistens noch auf Papier. Das Board ist aber etwas komplex. Ich habe mit STM32F407 und 429 angefangen und war 6 Wochen später dann "gut drin". Vergiss das mit dem Papier! Das Reference Manual und Dats Sheet sind über 2000 Seiten. Das brauchst du auch nicht um das zu lernen, sondern viele Beispielcodes und zb fertige Libs wie die von Tilen Majerle oder Uwe Becker. Das Display auf ddem 429 kriegst du ohne Libs eh nicht zum Laufen, das ist LTDC mit DMA. Grundsätzlich: Der STM32 wird mit vielen Librarys (StdPeriphLibs oder CubeMX) benutzt, oft sogar mit OS wie ChiBios oder anderen. Alles andere macht keinen Sinn, es sind viele zu viele Register und Bits da drin, das haben andere schon erkundet und abstahiert.
Felix C. schrieb: > Ich kann dir uGFX empfehlen. Nee! Viel zu kompliziert für Einsteiger und auf EmBitz nie zum Laufen gekriegt, weil die mit cmake arbeiten, Sub-Makesfiles. Nach einem Tag habe ich das Zeug frusrtiert wieder gelöscht. Die meisten arbeiten aber mit einer IDE. Hier ist ein guter Display Treiber, eine Datei und fertig. http://stm32f4-discovery.com/2014/06/library-18-ili9341-ltdc-stm32f429-discovery/
Hallo Reinhard, ein heißer Tip für Dich (und andere) ist die folgende Adresse: http://mikrocontroller.bplaced.net/wordpress/?page_id=5241 Hier wird Schritt für Schritt erklärt, wie man die IDE (Eclipse plus OpenSTM32) aufsetzt. Außerdem gibt es hier für STM32F4 Disco sowie F7 Disco umfangreiche Libraries. Übrigens verfügt der F7 Disco über einen noch größeren Touch- Screen (4,3 Zoll) und über Ethernet, Audio- Controller USB Full- und Highspeed usw. Ich wünsche Dir viel Erfolg und Durchhaltevermögen! Wolfgang
Danke für die Beiträge. Während Dr.Sommer den F7 nehmen würde, warnt Felix ausdrücklich vor diesem. Zum Einstieg kann ich ja auch auf den F7 verzichten. Da ich aber in Zukunft auch was ausgeben möchte, wenn es geht ohne ein OS zu nutzen, ware ein board mit Display gut. Um die passende GUI Library kümmere ich mich dann spatter. Nur gut zu wissen, dass es da was gibt. Christian J. findet das STM32F429 DISCO ganz ok und ich denke das könnte es werden. Kann es dennoch sein, dass der Einstieg mit einem Leonardo einfacher ist? Sollte ich besser erst ein einfaches board erwerben und dann schrittweise komplexere kaufen? Was ist didaktisch am sinnvollsten. Zu meinem Kenntnissen sei nochmals gesagt: AVR Assembler, C, C++ und auch Python sind mir nicht ganz fremd. Meines Erachtens ist das passende board für den Einstieg wichtig. Hat man ein board, das auch viele andere nutzen, so kriegt man in den Foren den meisten Support.
Reinhard J. schrieb: > Meines Erachtens ist das passende board für den Einstieg wichtig. Nö! Es kommt auf die CPU an. Und da gibt es nicht so viele Varianten, nur F0, F1, F2, F3 und F4. Und die sind sich alle ähnlich. Mit C ist es doch sowieso egal, welche CPU drunter ist, Du benutzt sowieso nur Libraries, siehst die Hardware drunter kaum mehr.
Angehängte Dateien:
-
CAM01066.jpg
230 KB
Das Ding ist inzwischen schon viel größer geworden,2 Displays, LEDs usw. aber ist mein Einsteigerprojekt. Display hier nur mit 20 Mhz SPI, ohne LTDC. Das hat der 429 Disco mit dabei aber nur wenige I/O Pins sind da noch frei, 13 Stück genau. Beim 407 sind fast alle frei, wenn Du die Chips ablötest, die du nicht brauchst, wie Audio DAC, Gyrosensor usw. Dann ist das ganze Board mehr oder weniger nur ein Breadboard, was die Pins rausführt.
Christian J. schrieb > Nö! Es kommt auf die CPU an. Und da gibt es nicht so > viele Varianten, nur F0, F1, F2, F3 und F4. Und die > sind sich alle ähnlich. Mit C ist es doch sowieso > egal, welche CPU drunter ist, Du benutzt sowieso nur > Libraries, siehst die Hardware drunter kaum mehr. Da Du den F7 nicht aufführst, gehe ich davon aus, dass Du Felix C. im vierten Beitrag implizit beipflichtest. Felix meint ja Finger weg vom F7. Was mich nur wundert, ist, dass die C Libraries zwischen F4 und F7 nicht kompatibel sind. Mit C Libraries sollte man schon ein Stück von der Hardware weg sein, auch wenn man die Hardware mit C direkt ansprechen kann. Eigentlich schade bei dem F7 board gibt es ein großes Display.
Hallo Erstmal, ich bin ein Fan der Standard Peripheral Library, dass solltest du meinen Argumenten bedenken ;) Reinhard J. schrieb: > Betreffen Deine Bedenken auch das STM32F429 DISCO Christian J. schrieb: > Nö! Es kommt auf die CPU an. Und da gibt es nicht so viele Varianten, > nur F0, F1, F2, F3 und F4. Und die sind sich alle ähnlich. Mit C ist es > doch sowieso egal, welche CPU drunter ist, Du benutzt sowieso nur > Libraries, siehst die Hardware drunter kaum mehr. CPU ist bei allen innerhalb einer Produktfamilie gleich F1 zB Cortex-M3. Es kommt auf die Produktfamilie an , wie Christian richtig festgestellt hat. Diese haben das gleiche Reference Manual und die gleiche Library. Das ist wichtig, da bei diesen die Register der Peripherien meist an den gleichen Adressen sind -> gleiche Funktionen der Standardbiblios bei allen Chips. Also hilft dir auch Code von einem f107 wenn du einen f103 verwendest etc. Dem mit den Librarys kann ich auch nicht ganz zustimmen. Selbstverständlich wirst du nicht nur mit Adressen arbeiten, jedoch wird auch das an keinem vorbeigehen. Gerade bei Debuggen braucht man ein Grundverständnis, womit man gerade eigentlich arbeitet. Christian J. schrieb: > Nee! Viel zu kompliziert für Einsteiger und auf EmBitz nie zum Laufen > gekriegt, weil die mit cmake arbeiten, Sub-Makesfiles. Nach einem Tag > habe ich das Zeug frusrtiert wieder gelöscht. Die meisten arbeiten aber > mit einer IDE. Das tut mir leid, hatte eigentlich recht gute Erfahrungen gemacht. Habe mit Keil gearbeitet. Reinhard J. schrieb: > Felix meint ja Finger weg vom > F7. Ich denke einfach, dass ein F7, wenn man das erste Mal mit STM32 arbeitet etwas heftig ist.
:
Bearbeitet durch User
Ich denke ich folge Eurem Rat und fange mit dem STM32F429 DISCO an. Christian J. hat ja gute Erfahrungen damit. µGFX kann man doch bestimmt in eine IDE integrieren. Aber das ist Schnee von übermorgen und ich sollte erst mal eine LED an und aus kriegen. Dann ein Lauflicht usw.. Herzlichen Dank an alle! Gruß Reinhard
Felix C. schrieb: > Ich denke einfach, dass ein F7, wenn man das erste Mal mit STM32 > arbeitet etwas heftig ist. Aber was genau ist an dem heftig? Die Clock Initialisierung im RCC ist gleich zum F4, die GPIO Ansteuerung ist gleich, die Timer sind gleich... Wenn man sich nicht direkt seinen eigenen Startupcode/Linkerscript/Systeminitialisierung basteln will, merkt man von der komplexeren Bus/System-Architektur gar nix - aber auch das ist nicht besonders kompliziert, alles mehr oder weniger Schema F. Die SDIO-Peripherie wurde nach SDMMC umbemannt und ein paar Silicon Bugs behoben, die im F1/F4 völlig vermurkste I²C Peripherie wurde durch die auch schon im F3 genutzte neue viel einfacher zu nutzende Variante ausgetauscht - das sind für mich klare Vorteile! Ein Nachteil des STM32F7 Discovery Boards ist, dass man an die JTAG/SWD Pins nicht so leicht drankommt, und man das integrierte ST-Link benutzen muss, was bei mir nur nach viel bitten funktioniert und auch dann nur langsam. Um einen "richtigen" Debug-Adapter wie JLink mit dem Board nutzen zu können, muss man darauf rumlöten...
Dr. Sommer schrieb: > die im F1/F4 völlig vermurkste I²C Peripherie wurde durch die > auch schon im F3 genutzte neue viel einfacher zu nutzende Variante > ausgetauscht Was ist denn da vermurkst dran? Die funktioniert doch. Habe grad erst dafrü E2PROM Routinen geschrieben. Und an die SWD Schnittistelle kommt man schon dran mit diesen billigen ebay USB St-Link2 Sticks. Einfach draufstecken auf die Pins oben und die interne SWD deaktivieren. Funzt prima. Aber die eingebaute SWD hat ja alles, debuggen im Debug und Release Mode, Life Anzeige, Source Level debggugging, alles da! Und uGFX kann man nur verwenden, da es auf ChBios basiert, wenn die IDE cmake Files unterstützt. Für ein paar Kreise und Dreiecke völlig überzogen, das ist mehr wie Windows. EmBitz kann das soweit ich sehe nicht, das Makefile wird selbst erzeugt. Kann aber auch sein dass das unter den vielen Experteneinstellungen drunter ist. Ich weiss nicht wie es geht. StemWin geht da einfacher. Und der F7 ist eher ein Smartphone Prozessor, getrimmt auf Multimedia, vollgeblasen mit Hardware für Musik, Grafik und externen Speicher, sowie Display.
Reinhard J. schrieb: > Ich denke ich folge Eurem Rat und fange mit dem STM32F429 DISCO an. Ich habe da noch ein unbenutztes von übrig, für 25 Taler + 2.90 Versand ist es dein. Falls du eines kaufst löte bitte die Diode am Backlight des Display ab und überbrücke sie. Sonst hat das Display kaum Leuchtkraft und sieht echt mies aus. 2,7V sind zu wenig, das braucht 3.3V auf der Lampe.
Christian J. schrieb: > Was ist denn da vermurkst dran? Die funktioniert doch. Ja, funktioniert schon. Ist aber sehr lästig zu programmieren, erst auf das Start Bit Interrupt zu reagieren, dann auf den Address Interrupt, dann auf den 1. Byte interrupt, etc. Das ganze ist auch noch zeitkritisch, denn wenn man zu spät reagiert ist die Kommunikation kaputt. Dann gibts auch noch ein paar gemeine Sonderfälle, dass man das Transfer-Ende-Bit vor dem Senden des letzten Bytes setzen muss und so. Außerdem verschluckt sich die Peripherie gerne mal und muss dann zurückgesetzt werden. Die neue I²C-Hardware kann einen kompletten Transfer automatisch per DMA abwickeln, ohne dass man zwischendurch was tun müsste. Christian J. schrieb: > Einfach draufstecken auf die Pins oben und die > interne SWD deaktivieren. Wo denn draufstecken?! Das STM32F7 Discovery hat die SWD Pins auf keine Stecker gelegt, sondern nur 0402 Lötbrücken! Christian J. schrieb: > Aber die eingebaute SWD hat ja > alles, debuggen im Debug und Release Mode, Life Anzeige, Source Level > debggugging, alles da! Wenns dann mal funktioniert und nicht einfach nur "Load Error" oder sonstige skurrile Meldungen anzeigt, und lahm ists auch noch... Da hat man dann die Wahl Kein µVision o.ä. zu kaufen ($$$$) um den ST-Link (lahm) vernünftig nutzen zu können, oder den JLink (schnell) zu kaufen ($$) der außerdem noch unter Linux geht...
Kennt jemand dazu eine Übersicht, welche Peripherie (oder Peripherieversionen) in welchen Serien drinstecken? Ich habe dazu bereits auf st.com gesucht, aber nichts dazu gefunden. https://en.wikipedia.org/wiki/STM32#Part_number_decoding Hier wird leider genau auf die für mich interessanten beiden Nummern verzichtet.
Dr. Sommer schrieb: > Christian J. schrieb: >> Was ist denn da vermurkst dran? Die funktioniert doch. > Ja, funktioniert schon. Ist aber sehr lästig zu programmieren, erst auf > das Start Bit Interrupt zu reagieren, dann auf den Address Interrupt, > dann auf den 1. Byte interrupt, etc. Das ganze ist auch noch > zeitkritisch, denn wenn man zu spät reagiert ist die Kommunikation > kaputt. Dann gibts auch noch ein paar gemeine Sonderfälle, dass man das > Transfer-Ende-Bit vor dem Senden des letzten Bytes setzen muss und so. Na klar. Während das letzte Byte gelesen wird geht ja nicht. Du fütterst nur ne Statemachine und die spult das alles ab. Gebe aber zu, dass der ganze Event Kram unnötig ist, der nach jedem Befehl abgefragt werden muss. Braucht kein Mensch. Die standen wohl unter Zwang irgendwas neues erfinden zu müssen, was eben weisser wäscht als weiss. Langsam... Du musst ja auch nicht auf F10 rumhämmern zum steppen. Tip....tip...tip... und nicht ratatadadadadadada.... :-)
Christian J. schrieb: > Du fütterst > nur ne Statemachine und die spult das alles ab. Beim F3,F7 ja. Beim F1,F4 nicht, da muss man die ja selber implementieren. Von alleine kommt die Peripherie nicht darauf, dass nach dem Start Bit die Adresse gesendet werden muss. Christian J. schrieb: > dass der > ganze Event Kram unnötig ist, der nach jedem Befehl abgefragt werden > muss. Braucht kein Mensch. Äh... und wie soll man im I²C-Interrupt herausfinden was gerade passiert ist?
Dr. Sommer schrieb: > Äh... und wie soll man im I²C-Interrupt herausfinden was gerade passiert > ist? Wir kommen zwar grad vom Thema weg aber wo ist das Problem jetzt? Bisschen aufgeblasen das Ganze aber es funzt... http://www.mikrocontroller.net/attachment/highlight/282161
Christian J. schrieb: > Wir kommen zwar grad vom Thema weg aber wo ist das Problem jetzt? Aah, das ist ja synchron mit Warteschleifen. Dann ist das einfach. Bei richtigen™ Anwendungen möchte man aber nicht tausende Takte Prozessorleistung in Funktionen wie I2C_WaitForEvent verschwenden, sondern asynchron arbeiten, und das ist bei der I²C-Peripherie vom F4 enorm lästig - benötigt hunderte Zeilen Code. Das geht beim F3,F7 viel einfacher. ./. schrieb: > Die Silabs 8051 haben fuer jeden I2C-Zustand einen Interrupt. > > Damit ist das ein Kinderspiel. Tja, bessere I²C-Peripherie als die STM32F4 haben sogar die AVR. Die ist bloß langsam :D
Dieser Kommentar im eeprom Source ist noch etwas verwirrend:
1 | // ---------------------------------------------------------------
|
2 | // Mehrere Bytes aus E2PROM lesen
|
3 | // FIXMEEE !!! Läuft nicht !
|
4 | // ---------------------------------------------------------------
|
> Betreffen Deine Bedenken auch das STM32F429 DISCO
Das Ding ist ziemlich verbaut. SDRAM und Display lassen
kaum noch Periphery frei. Ob das was für Anfänger ist?
Vieleicht doch besser ein einfaches STM32F4Discovery
und dann ein SPI Display dran.
Jojo S. schrieb: > Dieser Kommentar im eeprom Source ist noch etwas verwirrend: Was ist daran verwirrend. Eine Markierung für etwas was noch nicht läuft. Pagwrite eben. Kommt später dran.....
Als Author der µGFX Bibliothek möchte ich darauf Hinweisen, dass die Angaben von Christian J. (hobel) nicht korrekt sind. 1) uGFX verwendet nicht cmake. 2) uGFX basiert nicht auf ChibiOS. Es gibt lediglich einen Port um uGFX direkt out-of-the-box auf ChibiOS zu verwenden. Analog dazu gibt es Ports für FreeRTOS und andere Betriebssysteme. Die Bibliothek kann auf sämtlichen Platformen und auch Bare-Metal (ohne OS) verwendet werden. Es gibt keinen anderen Bezug zu ChibiOS. 3) uGFX kann ohne probleme mit IDEs verwendet werden welche nicht (c)make unterstützen. Dies ist sogar sehr einfach und es müssen nur ein paar wenige Dateien in ein bestehendes Projekt hinzugefügt werden. Entsprechende Dokumentation so wie Beispielprojekte für unterschiedliche IDEs und Platformen stehen zur Verfügung. Fragen & Probleme zum Integrationsprozess werden in unserem Forum gerne beantwortet. Bisher gab es noch keine Platform oder IDE welche mit welcher uGFX nicht verwendet werden konnte.
Joel B. schrieb: > Dies ist sogar sehr einfach und es müssen nur ein > paar wenige Dateien in ein bestehendes Projekt hinzugefügt werden. Ich habe das damals schlichtweg aufgegeben, da es keine Beispiele gab, wie es zb in Embitz zu importieren ist, was keine eigenen Make Files erlaubt und auch nicht zum Betrieb benötigt. Viele Source Libs im Netz kann man einfach als Baumstruktur mit einhängen, bindet die .h ein, legt Pfade drauf und die API steht dann zur Verfügung.
Ready-to-run Demo Projekte sind zugegebenermassen aktuell die Schwachstelle der µGFX Bibliothek. Wir arbeiten daran die "Example Projects" Download-Sektion weiter auszubauen. Du kannst eine einzige Datei in deiner IDE hinzufügen (ohne makefiles!) und die komplette µGFX bibliothek wird dir zur Verfügung stehen. Das ist die Interationsmethode welche wir "Single File Inclusion" nennen und ist hier [1] beschrieben. Eine mit Screenshots bebilderte Schritt-für-Schritt Anleitung steht auch zur Verfügung [2]. Diese ist zwar für Keil µVision aber der Prozess ist der selbe. Mithilfe dieser Anleitung gelang es unseren Users & Kunden auch mit anderen IDEs (IAR, EmBlocks, CrossWorks, Eclipse, ...) zu arbeiten. EmBlocks/EmBitz verwenden wir intern selber zur Entwicklung und haben bisher keine Probleme festgestellt. Ich werde dafür Sorgen, dass ein paar EmBlocks/EmBitz basierte Beispielprojekte zur Verfügung stehen werden. Wir sind auf jeden Fall offen für sämtliche Kritik. [1] http://wiki.ugfx.org/index.php/Getting_Started#Single_File_Inclusion [2] http://wiki.ugfx.org/index.php/Using_Keil_%C2%B5Vision_5_MDK-ARM
Joel B. schrieb: > Du kannst eine einzige Datei in deiner IDE hinzufügen (ohne makefiles!) > und die komplette µGFX bibliothek wird dir zur Verfügung stehen. Das ist > die Interationsmethode welche wir "Single File Inclusion" nennen und ist > hier [1] beschrieben. Ok, werde ich mich im Winter wieder mit befassen, im Sommer ist durchgehend "technikfrei" , da wird dann was anderes gemacht :-) https://www.youtube.com/watch?v=MRVrdOzC5Kk
Christian J. schrieb: > Ok, werde ich mich im Winter wieder mit befassen, im Sommer ist > durchgehend "technikfrei" , da wird dann was anderes gemacht :-) Okay, viel Erfolg! Bei Fragen stehen wir wie gesagt jederzeit gerne zur Verfügung.
>Ready-to-run Demo Projekte sind zugegebenermassen aktuell die >Schwachstelle der µGFX Bibliothek. Wir arbeiten daran die "Example >Projects" Download-Sektion weiter auszubauen. Es ist aber entscheidend für die Benutzung von Libraries, dass sie ohne Probleme "out of the box" funktionieren. Wenn Ihr eurem Geschäftserfolg etwas gutes tun wollt, dann macht ein paar Demo-Projekte für das STM32F7, die man herunterladen kann, compile-Knopf drücken, läuft. Ansonsten verhindert das die Verbreitung und es erfolgt eine Reaktion wie oben: Probiert, geht nicht, weg. Es nützt nichts zu sagen: Ja, da gibt es eine Anleitung, ganz einfach, muss man nur lesen. Wie geht nicht? Ach so ja, selbstverständlich muss man an der Stelle XY das Flag Z in der IDE setzen und darf nicht vergessen die Datei K an die Stelle W zu kopieren. Wie geht nicht? Steht doch in der Anleitung. Natürlich darf man nicht die IDE in der Version V im Zusammenhang mit der Bibliotheksversion W benutzen, wenn gleichzeitig die DMA an der Stelle t eingeschaltet ist. Wie geht immer noch nicht? Ach so das ist ja klar, mit der Beschränkung des Compilers C auf 32Kbyte kann natürlich nur das Blinky compiliert werden.
chris_ schrieb: > Wenn Ihr eurem Geschäftserfolg > etwas gutes tun wollt, dann macht ein paar Demo-Projekte für das > STM32F7, die man herunterladen kann, compile-Knopf drücken, läuft. Das wäre unser Wunsch. Das Problem fängt an mit: Welchen Compile-Knopf denn? Der von Keil? Eclipse? EmBitz? Ah, CrossWorks wär auch noch cool und wenn man schon dabei ist am besten auch noch für IAR und ein makefile-only. Damit hat man dann für ein Board sechs verschiedene Demo-Projekte (mit der selben Demo!). Dann bräuchte man die selbe Demo einmal BareMetal, dann mit ChibiOS, FreeRTOS, Keil RTX, eCos, ... Unser Problem ist, dass wir schlichtweg die Man-Power dazu nicht haben. Des Weiteren sollten ready-to-run Demos alles beinhalten - Sprich: die eigentliche Bibliothek ist Teil des Downloads. Wenn diese geupdated wird müssen all diese Demos wieder neu gepackt werden. Da ist schnell mal ein Tag dahin. Im Idealfall sollte man so einen Prozess also automatisieren. Kennt sich jemand mit der Materie etwas aus? Wir wären wirklich für jede Hilfe dankbar. Falls sich Jemand für eine solche Arbeit interessiert, bitte melden! Die Hauptproblematik bei uns ist, dass die Bibliothek wirklich komplett portabel ist. Die läuft auf jedem System, jeder Platform, mit jedem Compiler und jeder IDE.
Die Hauptproblematik bei uns ist, dass die Bibliothek wirklich komplett portabel ist. Die läuft auf jedem System, jeder Platform, mit jedem Compiler und jeder IDE. ------ Ja, bestimmt.Aber bei solche komplexen Dingen ist man einfach froh, wenn man einen Startpunkt auf einem bekannten Demo Board hat. Und sich von dort aus immer weiter einarbeitet. Ging mir genauso, inzwischen habe ich etliche Grafikdinge selbst entwickelt als universelle Funktionen, nur für mich eben. Das wissen inzwischen auch die Hersteller von Software und Hardware, dass es jeden abschreckt, wenn erst tausend Schrauben gedreht werden müssen, bevor irgendwo mal was blinkt.
Eine weitere, hier noch nicht erwähnte, Einstiegsmöglichkeit ist mbed. Einfach bei mbed.org anmelden, Board auswählen und eins der Beispielprojekte importieren, alles in der Online IDE. Es ist für die ersten Schritte keine weitere Software zu installieren. Und wenn man nicht online arbeiten möchte, gibt es auch eine Offline Toolchain - da ist dann aber ein wenig SW Installation notwendig. Die Einschränkung bei der Online IDE ist, das das Board mbed kompatibel sein sollte (z.B. alle STM Nucleo Boards - aber auch etliche andere sind verwendbar). In der Offline Toolchain ist die mbed Kompatibilität nicht so wichtig, es gibt auch etliche zusätzliche Boards, die in der Online IDE nicht verfügbar sind z.B. das Discovery F407. Zusätzlich kann man z.B. bei den STM Boards auch die STM32Cubexx HAL verwenden. Darauf baut nämlich mbed auf.
Joel hat es gerade nicht angesprochen, aber ein fertiges Demo Projekt für das F7-Discovery Board mit µGFX steht auf seiner Seite zum Download bereit: https://community.ugfx.org/files Man braucht nur den passenden Compiler.
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.