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.
Danke dir Macload! Wenn du zum CCstudio noch einen preiswerten Debugger/Programmer empfehlen könntest.....
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?
@ Dummschwätzer Preiswert= Entwicklungsumgebung (Compiler kostenlos), Debugger/Programmer < 50 €, bin halz Atmel ICE verwöhnt, wobei NXpresso < 20 € kostet....
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€).
:
Bearbeitet durch User
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 ;-)
Danke Christopher! kann man bei den Nukleo Boards den Debugger auch für externe uCs verwenden wie von Peter beschrieben? Gruß Uwe
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
Chruistoper, was konkret gefällt dir an der Doku nicht, Beispiele? 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 ;-)
nachtrag: für arduino fans, die meisten TI launchpads sind auch mit Energia zu nutzen, der MSP432/CC3200 sogar mit darunter liegendem TI-RTOS.
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.
Uwe H. schrieb: > bin halz Atmel ICE verwöhnt Na ja, dann kommst du jetzt mit TI oder STM in den rosa Woklen Himmel.
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
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.