MSPM0L-Familie als Nachfolger von MSP430

Beat B. schrieb:

Die neuen MSPM0L MCU's sind mit 1 Euro/Stück etwas günstiger als die Atmega328P (1.40 Euro/Stück) und können auch einzel direkt bei TI bestellt werden.

Viele Bastler hängen am DIP-Gehäuse und an der 5V-Fähigkeit der AVRs. Dagegen können auch andere ARMe nicht anstinken. (Immerhin hat das Ding hier 5V-tolerante I/Os, aber das ist immer noch was anderes als echter 5V-Betrieb).

TI hat schon vor Jahren versucht, die MSP430-Gemeinde zum Umzug auf einen ARM zu bewegen, indem sie anfingen, zur MSP430-Peripherie kompatible oder zumindest hinreichend ähnliche Peripherie mit einem Cortex-Kern zu verknüpfen, aber viel Begeisterung konnten die damit wohl nicht hervorrufen. Das Angebot an MSP432-Controllern ist jedenfalls überschaubar.

Ob das mit dieser Serie hier anders ablaufen wird? Ich bin etwas skeptisch.

Die Marketingwerte von Ti sind schlechter als die Merketingwerte von STM fuer die STM32U0 Serie. M.e.a. hat(te?) TI auch eine sehr erratische Politik mit den Cortex-M. Und dazu lange Zeit eine unmoegliche Lizenzpolitik fuer die Device Header Files...

Haben die Cortexe immer noch so wahnsinnig aufgeblasene IDEs und Betriebssysteme nötig? Ich hab mal irgendwann ein NXP-Testset geschenkt bekommen, bei dem der Flash des Demoboards mit dem Blinky-Code ausgelastet war. Erst knapp ein Gigabyte an Software installieren, dann die ultrakomplexe Runtime kompilieren, plus "while(1), pin high, delay, pin low, delay, do" und das Ding sagt locker "98% flash used". 2 LEDs abwechselnd blinken lassen ging nicht mehr weil Flash voll. Gut, waren nur wenige kB in nem 8pinner aber trotzdem. Das war keine gute Demo und ist daher sofort im Schrott gelandet...

Effektiv schreibt man auf solch leistungsfähigen Maschinen dann Code, der auf "ich hab Arduino für mich entdeckt"-Maker-Level leistet, weil man einen riesigen Wasserkopp mit sich rumschleppen muss, denn für direkten Zugriff ohne Api gibt's keine Doku.

Beat B. schrieb:

Ultra Low Power MCU's der neuesten Generation.

Die neuen MSPM0L MCU's sind mit 1 Euro/Stück etwas günstiger als die Atmega328P (1.40 Euro/Stück) und können auch einzel direkt bei TI bestellt werden.

Etwas komplexere Exemplare werden wohl auch teurer sein. Oder womoeglich gar nicht verfuegbar? Bei den MSP430 war das ja auch nicht anders, wenn ich z.B. an die MSP430FG4616/17/18 etc. denke. Aber mancher ist vielleicht mit den MSP430 einfach zufrieden.

Jens M. schrieb:

Haben die Cortexe immer noch so wahnsinnig aufgeblasene IDEs und Betriebssysteme nötig?

Ei sicher. Das stoert mich aber weniger. Weil es "setup.exe" gibt.

Ich hab mal irgendwann ein NXP-Testset geschenkt bekommen, bei dem der Flash des Demoboards mit dem Blinky-Code ausgelastet war. Erst knapp ein Gigabyte an Software installieren, dann die ultrakomplexe Runtime kompilieren, plus "while(1), pin high, delay, pin low, delay, do" und das Ding sagt locker "98% flash used". 2 LEDs abwechselnd blinken lassen ging nicht mehr weil Flash voll.

Auch legendaer: Der unter das Volk geworfende 16 Pin BGA ARM. Natuerlich nur der Chip, mit nichts drunter. :)

Nur Infineon konnte es bei den ARMs noch schlimmer. "Betreutes Programmieren" faellt einem da nur ein.

Uwe B. schrieb:

Die Marketingwerte von Ti sind schlechter als die Merketingwerte von STM fuer die STM32U0 Serie. M.e.a. hat(te?) TI auch eine sehr erratische Politik mit den Cortex-M. Und dazu lange Zeit eine unmoegliche Lizenzpolitik fuer die Device Header Files...

Meinst du die Stellaris? Das war sicher ein Fehler, die so "hart" abzukuendigen.

Motopick schrieb:

Etwas komplexere Exemplare werden wohl auch teurer sein. Oder womoeglich gar nicht verfuegbar? Bei den MSP430 war das ja auch nicht anders, wenn ich z.B. an die MSP430FG4616/17/18 etc. denke. Aber mancher ist vielleicht mit den MSP430 einfach zufrieden.

Nun, ich möchte keine Werbung machen, die gesamte MSPM0 - Familie ist bewusst auf Low-Cost getrimmt. So kostet auch die derzeit üppigste 80MHZ-Ausführung mit 60 5V toleranten GPIO's, 4 UARTS 2 I2C und 2 SPI's (https://www.ti.com/product/de-de/MSPM0G3507) gerade mal 1.6 Euro und wird innert 3 Arbeitstagen mit DHL geliefert.

Jens M. schrieb:

Haben die Cortexe immer noch so wahnsinnig aufgeblasene IDEs und Betriebssysteme nötig? Ich hab mal irgendwann ein NXP-Testset geschenkt bekommen, bei dem der Flash des Demoboards mit dem Blinky-Code ausgelastet war. Erst knapp ein Gigabyte an Software installieren, dann die ultrakomplexe Runtime kompilieren, plus "while(1), pin high, delay, pin low, delay, do" und das Ding sagt locker "98% flash used". 2 LEDs abwechselnd blinken lassen ging nicht mehr weil Flash voll. Gut, waren nur wenige kB in nem 8pinner aber trotzdem. Das war keine gute Demo und ist daher sofort im Schrott gelandet...

Das komplette Blink-Demo-Image für MSPM0L1306 ist so 1.2 KB und lässt sich wahlweise auch direkt über UART aufspielen. Die 'fette' IDE braucht es ja nur um den C/C++ Code in ein effizientes Binary zu kompilieren. Man kann das auch mit einem HEX-Editor schreiben und dann über UART aufspielen... - Die IDE (CCS) bietet aber nebst dem CLANG - Compiler auch eine Konfiguration der MCU (Sysconfig) und Realtime-Debugging.

Für mein einfaches kleines Projekt, eine RFM95-LORA-Node, die alle paar Sekunden einige Bytes versendet, suchte ich nach einem einfachen MC der mindestens ein SPI, einen UART und 2 GPIO's bietet, dafür aber extrem sparsam ist, da die Node autark 3 Monate mit einer LR1632 senden muss. Das Ganze dann auch noch möglichst klein da die Endgrösse der Node inkl. Gehäuse, Sender und Batterie 15x20x10mm nicht übersteigen darf. RFM95 ist bereits 15x15, da bleiben noch 5mm ...

Nach einiger Suche, ausgehend von den Atmel's war meine Präferenz dann der MSP430FR2422. Aber der ist leider etwas gross und auch nicht so sparsam. TI bietet mittlerweile auch gute Unterstützung, detaillierte Dokumentationen der MC's (1780 Seiten...) und ein paar interessante Lernvideos.

Damit dies nun nicht in einer Werbeveranstaltung endet ;-) gibt es aber auch ein paar Probleme. Mit den LaunchPad's geht ja alles flott und auch die Beispiele aus der SDK sind als Basis gut zu verwenden. Aber: Fertigen Code, der wie bei den Arduino's ab der Stange mal schnell installiert werden kann, ist noch Mangelware. Dies ist bei allen MC's dasselbe. Obschon der MSP430 mittlerweile über 30 Jahre alt ist und auch bei einigen Ausbildungen Verwendung fand, so gibt es doch nur einen Bruchteil der Literatur und Programmbeispiele wie für die Atmega's.

Und dann hat Harald natürlich recht:

Harald K. schrieb:

Viele Bastler hängen am DIP-Gehäuse und an der 5V-Fähigkeit der AVRs. Dagegen können auch andere ARMe nicht anstinken.

Um nicht immer die Launchpad's zu verwenden, muss man zum Lötkolben greifen um die Dinger irgendwie Breadboard-tauglich zu machen. Zuvor braucht es aber ein Breakout-Board auf das die MC's gelötet werden können. Da die SOT23-THN MC's recht neu sind, gibt es nichts anderes, als KiCad zu lernen und sich selbst ein GERBR-File zu erstellen. - Die Platine selber lässt man sich dann besser extern bei einer PCB-Schmide herstellen (SOT-23-THN hat 0.5mm Pinabstand)

Nicht jeder hat einen Reflow-Ofen unterm Schreibtisch. Ich auch nicht. Und so habe ich meine ersten MSPM0L'er beim Löten verheizt oder das Flussmittel war leider nicht NoClean und so gab es Probleme mit Kurzschlüssen. Als ich die Boards brav mit Alkohol reinigte, erzeugte das offenbar eine statische Aufladung... was wiederum zum Ausfall führte - Reflow in der Bratpfanne :-) habe ich ebenfalls probiert und das scheint mit Lötpaste nun zu klappen.

Hier wären findige Köpfe gefragt, die fertig verlötete Breakout-Boards in China herstellen und hier in der Bastlerszene günstig anbieten.

Die MSPM0L-Familie wird bei TI nicht so schnell verschwinden. Da die MC's klein und sparsam sind und (in grossen Mengen) günstig zu erhalten sind, werden sie auch in der Industrie öfter verbaut werden. Es wäre also schön, hier mehr über die MSPM0-er und die Erfahrungen damit zu lesen.

Harald K. schrieb:

(Immerhin hat das Ding hier 5V-tolerante I/Os, aber das ist immer noch was anderes als echter 5V-Betrieb).

Naja, nach einem ersten Blick in die Datenblätter musste ich schon herzhaft lachen:

"Flexible I/O features – Up to 60 GPIOs • Two 5-V tolerant IOs ..."

In Worten: Zwei (2!!!) Pins sind 5V-tolerant. Wenn man 5V-tolerante Pins wirklich braucht, ist man mit zwei (2!!!) Stück aber schon etwas arm dran. Auf den ersten Blick dachte ich, etwas mißverstanden zu haben, aber nein, auch der gründlichere Blick ins Datenblatt bestätigt genau das ... Und auch bei Verwendung als Eingänge wirklich nur die zwei.

Was durchaus nicht heißt, dass die nicht interessant scheinen. Aber die zwei Pins so herauszukehren, ist doch nun wirklich ein schlechter Scherz.

Andreas B. schrieb:

Zwei (2!!!) Pins sind 5V-tolerant. Wenn man 5V-tolerante Pins wirklich braucht, ist man mit zwei (2!!!) Stück aber schon etwas arm dran.

Diese beiden Pins sind immer Open Drain; für alle Pins würde man das nicht haben wollen. Und das sind die einzigen Pins, bei denen I²C mit 1 Mbps läuft. Naja, eine offensichtliche Anwendung ist besser als gar keine.

Dieses ganze Gehampel einen ARM32 für die Aufgaben eines 8- oder 16-Bitters anzupreisen ist lächerlich.

Die 8Bitter brauchen beim rechnen weniger Strom als der ARM beim schlafen. Und wenn die bisher gereicht haben, tun sie das heute auch noch. Für den 16-Bitter sieht es evtl etwas differenzierter aus, aber warum soll man da einen (potentiellen) Stromfresser einbauen, wenn es der MSP430 bisher auch getan hat.

Bei dem Beitrag geht es um den Ersatz der MSP430er gegen einen ARM32. Da auf einer 5V-Kopatibilität eines Atmels rumzureiten ist witzlos. Die MSP430 waren schon immer 3,3V. Bei den MSP430-DIPs haben einige den Vorteil, dass sie mit einer R3/R6/R14/R20 Rundzelle funktionieren, ohne eine interne Ladungspumpe zu haben/brauchen. Das kann wimre weder Atmel noch ARM...

Letztlich entscheidet der Markt, was er will. Die hersteller haben da nur sehr begrenzt Steuermöglichkeiten, zumindest so lange es noch Alternativen gibt. Gut, der Z80 ist jetzt doch Geschichte, aber dessen Derivate werden noch produziert.

Clemens L. schrieb:

Andreas B. schrieb:

Zwei (2!!!) Pins sind 5V-tolerant. Wenn man 5V-tolerante Pins wirklich braucht, ist man mit zwei (2!!!) Stück aber schon etwas arm dran.

Diese beiden Pins sind immer Open Drain; für alle Pins würde man das nicht haben wollen. Und das sind die einzigen Pins, bei denen I²C mit 1 Mbps läuft. Naja, eine offensichtliche Anwendung ist besser als gar keine.

Klar, wenn als Ausgang, muss natürlich der "obere" FET stillgelegt werden. Aber das kann ja durchaus auch konfigurierbar sein, und insbesondere könnten Eingänge sehr wohl 5V-tolerant sein. Bei den STM32 ist das ja auch wirklich bei den meisten Pins so (dass da das "5V-tolerant" nicht so ganz wörtlich zu nehmen ist und tatsächlich ja nur ein "VDD+4V-tolerant" ist, bleibe mal dahingestellt).