Guten Abend Elektronikfreunde!
Da mein SAMD10 Projekt sich so langsam dem Ende neigt, halte ich schon
mal Ausschau nach leistungsstärkeren uCs. Die Hardware des SAM D10
gefällt mir schon, aber die Dokumentation ist miserabel im ARM Cortex
Bereich. In amerikanischen Foren liest man daher immer wieder den Satz
"technical documentation sucks". Den TCC Treiber habe ich nur zum laufen
bekommen, indem ich mir ein ASF Beispiel runtergeladen hatte und mir
dann die Registerinhalte angeschaut hatte, reverse engineering.
Ansonsten habe ich mir den Codedschungel ASF nicht angetan.
Über die Qualität der Dokus bei NXP und STM liest man nichts Schlechtes.
Wie ist es aber bei TI, denn was man über den MSP432 liest, ein M4F mit
dem power consumption eines M0+, das haut einem um! Ok, 48 MHz sind
sicherlich nicht rekordverdächtig, aber egal. Und wie seht Ihr die
Lebenserwartung der Freescale (nun NXP) Kinetis Serie, die auch sehr
schöne uCs beinhaltet?
Gruß
Uwe
Für den MSP432 kann ich nichts sagen, aber deren TM4C sind sehr gut
dokumentiert.
Das gilt ebenfalls für die meisten derer analogen Chips (der BQ25xxx ist
da eine Ausnahme, mein Kollege hatte enorm viele Probleme mit dessen
Dokumentation).
Hinzu ist das CCStudio ein ganz tolles Programm und es gibt viele
Beispiele direkt herunterzuladen.
Also ich hab nur gutes von TI zu berichten, aber wie gesagt, die MSP432
Varianten habe ich noch nicht versucht.
Der STM32L4xx dürfte ähnlich im Stromverbrauch sein. Vor allem mit
externem DCDC Wandler (Schaltregler statt Linearregler 43 μA/MHz). Geht
bis max. 120MHz bei einem M4F. Das ist schon recht ordentlich.
Doku recht gut. Entwicklungsumgebung brauchbar.
Arbeite mit Freescale Bare metal - Doku reicht und hat unterschiedliche
Qualität, mal sind die Funktionsbeschreibungen super, dann wieder nur
mit Hilfe vergleichbarer Datenblätter zu verstehen.
Prinzipiell werden sehr viele Textbausteine benützt, aber leider ist die
Nomenklatur nicht durchgängig, was eben zu einiger Verwirrung führen
kann,
vorallem wenn z.B. Register erwähnt werden die nicht vorhanden sind.
Sepp schrieb:> Arbeite mit Freescale Bare metal - Doku reicht und hat unterschiedliche> Qualität, mal sind die Funktionsbeschreibungen super, dann wieder nur> mit Hilfe vergleichbarer Datenblätter zu verstehen.>> Prinzipiell werden sehr viele Textbausteine benützt, aber leider ist die> Nomenklatur nicht durchgängig, was eben zu einiger Verwirrung führen> kann,> vorallem wenn z.B. Register erwähnt werden die nicht vorhanden sind.
Danke Sepp! Auf gut Deutsch: Durchwachsen! Was du als viele
Textbausteine bezeichnest, kenne ich bei Atmel als Copy & Paste
Technologie, die sogar bei völlig konträren Register eingesetzt wird
(xbclr/xbset), so daß diese sich dann scheinbar nicht mehr konträr
verhalten. :-)
Danke dir Schorch! Den STM32L4xx schaue ich mir gerade an, klingt gut
und preiswert. Ob die Zahl 431 eine Anspielung auf die 16 Bit low power
uCs von TI sind, die in Sachen Power legendär sind? Egal. Kannst du mir
dazu noch eine kostenlose Entwicklungsumgebung und einen günstigen
Debugger/Programmer empfehlen?
Hallo Schorch!
"84 µA/MHz run mode", wow, das sind ja M0+ Werte, TI like, bin schon
wieder am sabbern vor lauter Staunen! :-) In Sachen Taktfrequenz zeigt
er ja dem MSP432 die Rücklichter, knapp Faktor 2 (80 Mhz max.?), aber
egal!
Für STM32L4 gibt es Nucleo-Boards, die bereits einen Debugger mit drauf
haben. Das Nucleo-L432KC hat das Format eines Arduino-Nano und kostet
bei Mouser 10€ zzgl. Steuer. Das Nucleo-L433RC hat ebenfalls einen
Debugger mit an Board und kostet ebenfalls <15€. Als IDE gibt es von
Seiten von ST mittlerweile SW4STM, sowie Atollic True Studio jeweils für
lau. Die Doku von ST finde ich nicht so den Hit, ganz im Gegenteil.
Dafür sind die Controller Preis-Leistungs-mäßig sehr gut wie ich finde.
Edit: Nucleo L476RG vergessen. Gibt es auch bei Reichelt (~18€).
Hallo Christopher,
ich habe das MSP432 Launchpad, dass hat einen Debuger mit drauf.
Den man auch zum Debugen externer HW benutzen kann.
Kosten sind minimal, ca 13$.
Den MSP432 auf dem Launchpad kann man via Jumper abhängen vom Debugger.
https://store.ti.com/msp-exp432p401r.aspx
mfG
Peter ;-)
Hallo Peter!
Die Kosten sind ja der Hammer, auch die Ausstattung des Boards! Du wirsd
den Controller doch bestimmt auch schon mal programmiert haben, weshalb
du auch etwas zur Brauchbarkeit der Doku sagen kannst?
BG
Uwe
Uwe H. schrieb:> Wie ist es aber bei TI
Ich have einen Zeitlang mit C2000 von TI gearbeitet und kann mich nur
positiv äußern. Alles genauz beschrieben und sofort umsetzbar. Bei STM
muss ich erst fünfmal lesen bis das was zwischen den Zeilen erkennbar
ist.
Uwe H. schrieb:> Kannst du mir> dazu noch eine kostenlose Entwicklungsumgebung und einen günstigen> Debugger/Programmer empfehlen?
CCStudio 7 ist kostenfrei (Eclipse-Basiert).
Debugger xds100 ist ähnlich dem STLink auf vielen Board mit drauf.
rgds
Hallo Christopher,
ich habe mit der Docu keine Probleme gehabt.
am besten ist CCS7, keine beschränkung, alles frei.
im CSS7 -> resource explorer -> Board wählen, oder Software.
Da gibt Beispiele ohne ende, per klick importiert.
Und jeweils die manuals als pdf zum anklicken.
Das macht es sehr einfach Doku zu lesen die zur MCU passt und die
beispiele sind immer am besten.
ps: ich benutze aber auch den CC3200 (launchpad), der ist mit Wifi und 2
Arm Cpu's.
natürlich ist da auch der HW debuger mit drauf.
mfG
Peter ;-)
Also, für die TM4C Familie benutze ich ein Launchpad und meine eigenen
Platinen debugge ich auch mit dem Debugger vom Launchpad (da ist ein
Stecker drauf mit dem man mit Jumperwires alle JTAG Signale nehmen kann
(oder SWD)).
Ich habe auch schonmal meinen Raspberry Pi als OpenOCD Debugger laufen
lassen, und so kann man die TM4Cs auch debuggen, aber nachdem ich's
geschafft hatte, fand ich die Variante mit dem Launchpad onboard
Debugger viel einfacher.
Uwe schrieb:> Danke Christopher! kann man bei den Nukleo Boards den Debugger auch für> externe uCs verwenden wie von Peter beschrieben?> Gruß>> Uwe
Ja, das geht. Auf den Nucleo-Boards sind ST-Link V2 drauf. Mit OpenOCD
kann man damit sogar andere Cortex-M debuggen. In Kombination mit einem
NRF51822 hatte ich das auch schonmal gemacht. Funktioniert einwandfrei.
Uwe schrieb:> Chruistoper, was konkret gefällt dir an der Doku nicht, Beispiele?
Ich finde sie einfach nicht sehr einsteigerfreundlich. Es ist halt ganz
typisch für - zumindest in Teilen - autogenerierte Doku. Jeder Teil für
sich ist Dokumentiert aber die Zusammenhänge sind es nicht. Beispiel
Timer: STM32 haben im Groben drei verschiedene Timer-Typen. Es gibt
Basic-Timer, General-Purpose-Timer und Advanced-Timer. Im Prinzip kann
man die folgendermaßen zusammenfassen: Basic-Timer sind nur für eine
Zeitbasis gut, können aber weder Input-Capture noch Output-Compare.
General-Purpose-Timer können hingegen IC und OC und natürlich alles
andere, was ein Basic-Timer auch kann. Advanced-Timer können wiederum
alles was ein GP-Timer kann und haben zusätzlich noch Dead-Time- und
Break-Features. Für mich ist eine solche Zusammenfassung elementar aber
man findet sie im Reference-Manual nicht. Da muss man dann schon in
irgendwelche Appnotes schauen. Selbst innerhalb der General-Purpose
Timer gibt es unnötige Wiederholungen. Beispiel: Timer2, Timer15 und
Timer16 sind General-Purpose-Timer und im Refman des L432 auf zwei
Kapitel verteilt, obwohl der Unterschied zwischen Timer2 und Timer15/16
lediglich die Anzahl der Ein- bzw. Ausgänge ist und das Timer2 32bit
hat, während Timer15/16 lediglich 16bit haben. Im RM0394 hat man dann
viele male die gleiche Abbildung zur grundlegenden Beschreibung der
Timer-Funktion. Folgende Abbildungen sind zum Beispiel identisch: Fig.
164 auf S. 622, Fig. 224 auf S.719, Fig. 274 auf S.791 und Fig. 305 auf
S.867.
Ein weiterer Kritikpunkt und das finde ich eigentlich noch viel
schlimmer, ist der Mangel an ordentlichen Codebeispielen und da zähle
ich CubeMX/HAL persönlich einfach nicht mit dazu, weil das für mich
persönlich zu abstrakt ist um dadurch die Hardware wirklich
kennenzulernen bzw. zu verstehen. Die SPL war da noch deutlich besser
aber wird eben nicht mehr weiterentwickelt und kann man von daher quasi
als tot betrachten. Für die F0 und L0-Serie gibt es allerdings
sogenannte "Snippets", wo direkt über die Register die Hardware
angesprochen wird.
Danke dir Christopher für die sehr ausführliche Antwort!
Tja, wir sind in Sachen Codebeispiele vom AVR verwöhnt. Da die Dinger
sehr einfach waren, konnte man die Dokumentation sich bei einer Flasche
Rotwein bequem reinziehen. Mittlerweile sind aber die uCs zumindest von
Arm-Cortex so kompliziert geworden, daß Codebeispiele in Romane ausarten
würden. Um so einen einfachen Timer zu starten, muss man im Grunde
genommen erst einmal vormachen, wie man eine Clock source zum Laufen
bekommt, mit einem generic clock generator verbindet, das ganze dann
weiter routet zur Peripherie, im Power Manager aber vorher noch den Takt
freischaltet. Da kommen schnell paar Seiten zusammen. Die Dinger sind so
etwas von komplex, daß ich manchmal den Eindruck habe, die Autoren der
Doku steigen da selber nicht immer ganz durch. Ich glaube, wir müssen
aufgrund der Kompliziertheit dieser uCs Abschied nehmen von einfachen
Dokumentationen, die sich wie ein Playboy Magazin lesen lassen. In
wieweit andere 32 Bit Nicht-Arm Controller (PIC32, AVR32 ) genauso
kompliziert sind, kann ich nicht beurteilen, wäre aber interessant zu
wissen,obwohl, Arm-Cortex regiert den 32 Bit uC Markt, Fremdgehen ist da
kaum möglich. Andererseits immer wieder aufregend und total
faszinierend, wenn du so einen kleinen SAMD10 Käfer hast für einen Euro,
der selbst einen 386er Prozessor locker abhängt, und das bei etwa 8 mA
Strom aus einer Li- Knopfzelle. Und beim hier besprochenen M4F für etwa
4 € das Stück versenkt man mühelos jeden 486er, ebenfalls bei etwa 8 mA,
wo man sich früher beim 486er ohne Lüfter die Hände verbrannt hätte beim
Anfassen.
Hallo Christopher!
Ich habe mich jetzt eingeschossen auf NUCLEO L476RG als
Debugger/Programmer (11,96€ netto bei Mouser), der den STM32L476RGT6
evaluiert, also drauf hat. Für mein eigenes Board nehme ich den viel
kleineren STM32L431CB6. Kann ich den ST-Link V2 direkt nutzen für mein
externes Board zum Flashen und Debuggen, oder muss ich da schon OpenOCD
verwenden? Wie ist das bei STM, verwenden die ihre Peripherie auch in
den anderen Familien, so wie es NXP oft tut?
BG
Uwe
PS: So etwas Ähnliches gibt es auch von NXP, bei 100 MHz laufend und mit
zusätzlichem M0+ Coprozessor, auch mit 100 MHz getrieben. Aber das finde
ich schon dekadent :-)
https://www.nxp.com/docs/en/data-sheet/LPC5410X.pdf
Hallo Christopher!
Hatte Deinen Nucleo-L432KC übersehen, der nur 8,80 € netto bei Mouser
kostet, Hammerpreis, wobei die Frage bleibt, ob ich den ST-Link V2
direkt nutzen kann für mein externes Board zum Flashen und Debuggen,
oder muss ich da schon OpenOCD verwenden? Im Datasheet ist nämlich
nirgedwo dies erwähnt. Welches Kabel brauche ich noch für den Anschluss
an ein externes Board zum debuggen?
https://www.mouser.com/ds/2/389/nucleo-f031k6-973846.pdf
Uwe H. schrieb:> Kann ich den ST-Link V2 direkt nutzen für mein externes Board zum> Flashen und Debuggen, oder muss ich da schon OpenOCD verwenden?
Der ST-Link V2 ist ja nur der Debug-Adapter, also die Hardware. Damit
diese Hardware mit GDB kommunizieren kann benötigst du noch einen
GDB-Server. Das kann OpenOCD sein oder auch ein anderer, z.B. der von ST
selbst vertriebene, dessen genaue Bezeichnung ich gerade nicht im Kopf
habe. Mit dem GDB-Server von ST kannst du halt mit dem ST-Link keine
Cortex-M anderer Hersteller bespielen, was mit OpenOCD geht.
Beim großen Nucleo-L476 hat man Jumper, um den Debugger zwischen dem
L476 auf dem Board und einem externen Target umstellen zu können. Es
gibt eine Pfostenleiste mit den für SWD nötigen Pins. Beim kleineren
Nucleo-L432 weiß ich nicht ob man damit ohne weiteres ein externes
Target debuggen kann.
Uwe H. schrieb:> Welches Kabel brauche ich noch für den Anschluss an ein externes Board> zum debuggen?
Irgendein Kabel womit du die 0,1" Pfostenleiste mit deinem Target
verbinden kannst.
Danke dir Christopher!
Das heißt, wenn ich das große Nucleo-L476 Board verwende, kann ich
Sachen wie einen GDB-Server vergessen, das Board verhält sich dann nach
Umjumperung wie ein reiner Debugger/Programmer, also wie mein Atmel
ICE??
BG
Uwe
Ja, nach dem umjumpern kannst du damit ganz einfach ein externes Target
debuggen, als wäre es das Target auf dem Nucleo selbst. Einen GDB-Server
braucht man immer, weil GDB nicht direkt mit dem Debug-Adapter, sprich
in diesem Fall mit dem ST-Link, kommunizieren kann. Das gleiche gilt
aber genauso auch für den Atmel ICE. Wenn du eine IDE wie Atollic oder
SW4STM nutzt, dann musst du dich darum aber nicht kümmern. Die Details
werden vor dir versteckt.
Danke dir Christopher!
Dann nehme ich gemäß einem anderen Thread hier den GCC mit Eclipse
Entwicklungsumgebung, die bestimmt den GDB-Server integriert hat und den
externen Debugger/Programmer ST-LINK/V2 (4,01 € bei Amazon und portofrei
(:-), das scheint dann die unkomplizierteste Lösung zu sein, quasi
plug&play Technik ähnlich wie Atmel Studio 7 und deren ICE?
BG
Uwe
