Hallo zusammen
Ich habe mir wohl etwas voreilig das Teil aus dem Betreff beschafft:
http://www.mikroe.com/eng/products/view/869/mikromedia-for-stm32-m4/
Der Compiler kostet 299 Euro und die Libs für die Peripherie sind
Closed-Source. Hatte eigentlich damit gerechnet, dass ich im Web
mehr Infos dazu finde.
Frage: Hat schon jemand mit dem Teil und GNU-C für ARM exprimentiert und
kann davon berichten ?
Vorallem vor dem Display habe ich Respekt, da es nicht via SPI
angebunden ist, sondern im 8-bit Mode, und damit habe ich keine
Erfahrung.
Wollte mir aus dem Board und einem SHT25 Temp/Humy Sensor einen
Datenlogger mit grafischem Display bauen. Ich weiss, ist völliger
Underkill für so eine MCU, aber was soll's ;-) Geht auch darum,
mit dem STM32F4 Erfahrungen zu sammeln.
Danke und Gruss
Daniel
Daniel B. schrieb:> Der Compiler kostet 299 Euro und die Libs für die Peripherie sind> Closed-Source. Hatte eigentlich damit gerechnet, dass ich im Web> mehr Infos dazu finde.
Hättest du vorher hier gefragt, hätte ich geantwortet, dass
MikroElektronika dafür bekannt ist, möglichst geschlossene, proprietäre
Entwicklungssysteme anzubieten. Ebenso hätte ich gesagt, dass
MikroElektronika nicht für gute Compiler bekannt ist.
> Frage: Hat schon jemand mit dem Teil und GNU-C für ARM exprimentiert und> kann davon berichten ?>> Vorallem vor dem Display habe ich Respekt, da es nicht via SPI> angebunden ist, sondern im 8-bit Mode, und damit habe ich keine> Erfahrung.
Du bist gerade dabei, einen Mehrfrontenkrieg zu eröffnen. Unbekannter
Mikrocontroller, unbekannte Hardware, unbekannte Peripherie und
unbekannter Compiler. Nicht gut.
Eine mögliche Lösung wäre, mit einem Discovery-Board und einer
Demo-Version der offiziell unterstützten IDEs zu beginnen. Dann
Erfahrung mit dem STM32F4 sammeln. Dann eine Komponente, den Compiler,
tauchen. Dann das Board tauschen. Dann das Display angehen. Dann den
SHT25 angehen.
Das braucht Zeit und Geduld.
Danke für die Antwort, aber so schlimm ist es nicht, respektive der
Krieg hat nicht so viele Fronten ;-)
- Discovery-Board ist in Betrieb, eben leider ohne Display,
darum dieses Board
- Codesourcery_arm-2011.09 unter Linux mit Segger JLink-EDU funktioniert
soweit gut.
- Die SHT Sensoren habe ich schon in diversen Projekten verwendet.
Leider habe ich nicht gesehen, dass nirgends der Kontroller des
Displays steht, und dass das Ding im 8-Bit Mode angebunden ist.
Na bravo, jetzt habe ich wohl auch noch mein Board geschrottet.
Nach verschiedenen Versuchen mit dem JLink EDU und dem ST-Link v2
Adapter geht gar nichts mehr.
- Der TFT wird nur noch weiss
- Das Originalprogram läuft nicht mehr
- Der Bootloader reagiert nicht mehr
Flashen mit dem JLink EDU ging gar nie. Irgendwie wird zwar die CPU
erkannt, aber mehr geht nicht.
Da ich den JLink-EDU nur zum flashen brauche, bin ich mit den Meldungen
etwas überfordert ;-)
Hat jemand von Euch eine Ahnung, was da falsch läuft, oder mir
eventuell einen JLink Befehl, mit dem ich die CPU testen kann ?
Keine Ahung, ob ich durch die diversen Verkabelungsversuche etwas
zerstört habe, oder einfach (was ich hoffe), etwas noch nicht
begriffen habe.
Ok, gelöst
Auf dem STM32F407VGT6 war in den sogenannten "Option Bytes" die
"Read Out Protection" auf Level 1 gesetzt.
Diese Bytes werden aktuell vom JLinkExe, nicht unterstützt.
Macht ja eigentlich auch keinen Sinn, da jeder, der ein
eigenes Board entwickelt, diese natürlich nicht setzt.
Laut Alex von Segger, werden die "Option Bytes" in einer der nächsten
Versionen unterstützt (überprüfen und wenn möglich setzen).
Ich habe jetzt halt noch einen ST-LINK/V2 Adapter in meiner Sammlung,
man hat ja nie genügend Programmieradapter....
Daniel
