Hallo uC.net, hoffen wir mal, dass dieses Thema nicht in einer Art Glaubenskrieg endet. Ich möchte mich gern mit einer neuen Mikrocontroller-Familie beschäftigen. Bislang habe ich am meisten Erfahrungen mit 8-Bit AVRs und habe die PIC-Welt ein wenig kennen gelernt. ESP8266 oder -32 sind mir auch nicht ganz fremd. An der AVR-Plattform schätze ich: - Open source tooling mit avr-gcc - Unterstützung für C++ und Arduino Framework - Unterstützung durch Platformio/vscode - Niedrige Einstiegsschwelle bei Programmier-Adaptern Meine Wunschliste für eine uC Familie: - Integration in vscode unter Linux - Platformio wäre ein Plus, aber nicht zwingend notwendig - Ganz toll wäre, wenn on-target Debugging funktioniert - C++ compiler; Arduino optional aber kein Muss - Singlecore! IMO sind die meisten multicore-uC-Anwendungen besser auf einem eLinux wie yocto aufgehoben. Gedanken zu diversen Plattformen: - AVR8: leider kein echtes Debugging unter Linux möglich, erst recht nicht bei den ATtiny Chips. Und schade, dass es (AFAIK) keine Controller in kleinen Formfaktoren mit über 2k SRAM gibt. - PIC: Eigentlich stört mich nur der Lock-In auf das mplabx ... - ESP: Cool! Aber oft eher Overkill. Ich brauche nicht immer WiFi und BT usw. an Bord. - STM32: Vielleicht fehlt mir nur der richtige Einstieg, aber selbst eine LED blinken zu lassen hatte so viel nicht-intuitiven boilerplate Code, das hat mich bislang abgeschreckt. Zudem bin ich nicht sicher, wie das mit dem Debugging aussieht. - CH32V: sehr interessant, gerade bei dem Preis für die Einstiegs-Kits, für den man sonst kaum einen Programmer bekommt. Boilerplate auch etwas unübersichtlich, aber bei den Controllerpreisen, verfügbarem open-source-tooling und aktiver Entwicklung der platformio-Integration schaue ich darüber gern hinweg. (Ich vermisse irgendwie das on-chip EEPROM. Kann man hier den Flash-Speicher für persistente variable Daten nutzen?) … das sind natürlich meine persönlichen Ideen und Wünsche zu verschiedenen Plattformen, ich erhebe keinen Anspruch auf Objektivität. Was denkt ihr, welche µCs sollte ich mir mal genauer angucken? Viele Grüße! ~jmm
J-M M. schrieb: > hoffen wir mal, dass dieses Thema nicht in einer Art Glaubenskrieg > endet. Wird es aber. ;-) LPC mit MCUxpresso (Eclipse basierend, frei bei NXP). Debugging easy. Programmer auch guenstig (entweder BMP oder den originalen MCU-link) Oder old school mit beliebigen Editor und GEDE als debugplatform. Mit vcode schraenkst Du Dich schon gewaltig ein.
Andreas B. schrieb: > Mit vcode schraenkst Du Dich schon gewaltig ein. ?????? vcode ????? Mit VSCode geht alles. STM32 über PlatformIO, da gibt es die Möglichkeit ein CubeMX Projekt per Script in ein pio Projekt zu konvertieren. Oder über eine Extension auch ohne pio zu nutzen. Mit pio kann man so gut wie alle Boards und Frameworks nutzen. Man kann libopencm3 mit make Projekten in VSC nutzen. Mbed 5/6/CE funktioniert bestens mit VSC. Alles mögliche bare bone über die MSC Extension geht. Vielleicht erst mal damit beschäftigen bevor man sowas behauptet.
Mag ja sein, dass man mit vscode alles moegliche laufen lassen kann. Aber auch mit den Debugmoeglichkeiten einer IDE, die fuer die entsprechende CPU Familie entwickelt wurde? Ich rede hier von Register- und Memoryauszuegen, setzen von breakpoints auf Variablenaenderungen und dergleichen. Ich habe mir vscode nicht allzulange angeschaut und programmiere nur manchmal die ESPs damit, aber es kommt mir alles sehr frickelig vor.
J-M M. schrieb: > Gedanken zu diversen Plattformen: > - AVR8: leider kein echtes Debugging unter Linux möglich, erst recht > nicht bei den ATtiny Chips. MPLABX plus SNAP oder PICKIT4 kann das auch unter Linux, wenn der Chip das kann. Über ISP gehts natürlich nicht, weil das nur eine Programmierschnittstelle ist, aber UPDI oder dW sollte kein Problem sein. fchk
Da der TO keinerlei Hardware-anforderungen hat sondern nur Reqs bezüglich des Programmierens aufstellt, soll es sich einen RasPi mit IO-breakout besorgen. https://rasp.io/breakout/ Da hat er auch On core debugging mit gleichzeitig Browser laufen um mit dummen Fragen Foren zu fluten.
J-M M. schrieb: > - AVR8: leider kein echtes Debugging unter Linux möglich, erst recht > nicht bei den ATtiny Chips. Und schade, dass es (AFAIK) keine Controller > in kleinen Formfaktoren mit über 2k SRAM gibt. 16KB SRAM im 5x5mm VQFN: https://www.microchip.com/en-us/product/AVR128DB48
J-M M. schrieb: > AVR8: leider kein echtes Debugging unter Linux möglich, erst recht > nicht bei den ATtiny Chips. Sicher: UPDI
J-M M. schrieb: > AVR8: leider kein echtes Debugging unter Linux möglich Theoretisch müsste das inzwischen mit der MPLABX IDE gehen. Ich habe es aber nicht ausprobiert, weil ich keinen Debugger habe. Habe mich inzwischen an printf() gewöhnt. > STM32: Vielleicht fehlt mir nur der richtige Einstieg Da kann ich gut mit dir mitfühlen. Ich habe da mal während eines Urlaubes reingefuchst. Mein Hauptproblem war die um Faktor 10 umfangreichere Doku, und dass die Mehrheit der Anleitungen im Internet (bezüglich IDE und Framework) schon veraltet war. Das ist aber inzwischen viel besser geworden. Ich habe meine Erkenntnisse dort aufgeschrieben, könnte dir helfen: http://stefanfrings.de/stm32/index.html Ich finde den STM32L072 als nächste höhere Stufe nach AVR attraktiv. Frage: Gibt es eigentlich Cortex M basierte Mikrocontroller, die ohne Spannungsregler mit 3-6 Volt laufen können? Ich meine, wo deren I/O Pins dann auch diese Spannung haben? Das wäre mal was feines.
:
Bearbeitet durch User
Ausprobieren kostet doch nur mehr ein paar Euro. Kauf dir doch einfach ein paar Platinen mit USB-Stecker und probiere die unterschiedlichen Familien aus. PIC wird halt etwas teurer, seit die Chinesen für einen Pickit Clone den selben Preis wie das Original haben wollen.
Steve van de Grens schrieb: > Frage: > Gibt es eigentlich Cortex M basierte Mikrocontroller, die ohne > Spannungsregler mit 3-6 Volt laufen können? Ich meine, wo deren I/O Pins > dann auch diese Spannung haben? Das wäre mal was feines. Das sind Sachen, wo ich dann gerne dsPIC33EV... einsetze. 16 Bit, 70 MHz, 256k Flash und 16k RAM, bis 64 Pins, und das alles bei 5V Vcc und 5V I/O, damit kann man schon einiges machen. Und das ist alles problemlos kaufbar. Nuvoton und Toshiba haben 5V ARMs, aber gängig sind die nicht. fchk
J-M M. schrieb: > An der AVR-Plattform schätze ich: > - Open source tooling mit avr-gcc Den gcc gibt es praktisch für alle uC-Familien, der Unterschied ist nur, in welcher Verpackung du ihn bekommst. Wenn du sowieso Linux benutzt, kannst du gcc und binutils auch selbst aus den Original-Quellen bauen. > - Niedrige Einstiegsschwelle bei Programmier-Adaptern Das ist relativ, STM32, LPC und Renesas RX brauchen garkeinen Adapter, nur eine serielle Schnittstelle. Für die PIC32M braucht man einen und vor allem das passende PC-Programm, also MPLAB. > - Ganz toll wäre, wenn on-target Debugging funktioniert Dann nimm einen STM32, da funktioniert das am besten, z.B. mit Black Magic Probe und gdb. Und der Debugger beeinflusst dein Programm praktisch garnicht. Bei den PIC32 lädt er ein Hilfsprogramm ins Flash, überschreibt RAM und ändert SFR. Hardware-Breakpoints haben eigentlich alle 32-Bit Chips, aber die ARM-Kerne bieten deutlich mehr Komfort. > - PIC: Eigentlich stört mich nur der Lock-In auf das mplabx ... Ist das so schlimm? Du bekommst mplabx ohne Registrierung (das ist ziemlich einmalig) und musst es nur auspacken, nicht benutzen :) In dem Paket gibt es z.B. ein Flash-Programm für die Kommandozeile und im MPLAB XC32 steckt ein (etwas älterer) gcc. > - STM32: Vielleicht fehlt mir nur der richtige Einstieg, aber selbst > eine LED blinken zu lassen hatte so viel nicht-intuitiven boilerplate > Code, das hat mich bislang abgeschreckt. Zudem bin ich nicht sicher, wie > das mit dem Debugging aussieht. Den Code musst du ja nicht benutzen. Für die STM32 gibt es einen sehr guten gcc: https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads und die Chip-spezifischen Header holt man am besten hier: https://github.com/STMicroelectronics z.B. für die STM32L4-Familie: https://github.com/STMicroelectronics/STM32CubeL4/tree/master/Drivers/CMSIS/Device/ST/STM32L4xx/Include mehr braucht man eigentlich nicht. Die Cortex-M sind (in C) wirklich einfach zu programmieren. > Zudem bin ich nicht sicher, wie das [beim STM32] mit dem > Debugging aussieht. Optimal, 2 Klassen besser als beim PIC32M oder RX.
>Frage: Gibt es eigentlich Cortex M basierte Mikrocontroller, die ohne
Spannungsregler mit 3-6 Volt laufen können? Ich meine, wo deren I/O Pins dann auch
diese Spannung haben? Das wäre mal was feines.
Renesas hat da auch was, die RA2L1 und RA4M1 Familien hab ich z.B. auf
die Schnelle gefunden.
Mit Cortex-M wärst auf jeden Fall gut gerüstet! STM hat auf den Boards immer einen von fast jeder IDE unterstützten Debugger STLink mit drauf. Ja, die Cortex-M sind etwas schwiriger für den Einstieg, und auch die STM HAL macht das nicht besser. Dennoch gibt es vor allem für STM32 überall im Netz Beispiele, und man hat schnell raus, wo man bei main() ansetzen muss. Drumherum gibt es einiges an Middleware, ab einer gewissen Komplexität (bereits ab zwei parallelen Programmteilen ausserhalb einer ISR) empfehle ich ein RTOS (z.B. CMSIS-RTOS), um seine Programmteile zu entzerren. Das angesprochene C++ auf MCUs ist mit Vorsicht zu genießen (vor allem, wenn STL ins Spiel kommt, es gibt spezielle MCU Varianten), da die Heap Verwaltung eher schwierig wird, wenn dynamisch. Hier muss man wissen (bzw. herausfinden), was man tut. Falls Interesse: Ich habe eine CMSIS-RTOS Erweiterung geschrieben, welche eine Klasseninstanz um genau einen Thread erweitert, das Stack-Management kapselt und ein paar Helferlein bietet. Der mMn. einzige Knackpunkt für den Einstieg in Cortex-M basierte MCUs ist, dass zu Beginn alle Peripherals ausgeschaltet (keine clock) sind. Da fällt man leicht drauf rein. Ab da sind die programmierbar wie jede andere MCU auch. Entweder mit HAL oder Datenblatt (vgl. RCC->APB2ENR). In beiden Fällen empfehle ich CMSIS HAL, in diesem Format kommen neben dem MCU peripherals Headerfile noch ein Cortex-M core headerfile und ein paar nützliche Funktionen für den NVIC Interrupt Controller hinzu. Und wem selbst die STM Headerfiles / Struktur zu viel sind, der nimmt das passende STM32 SVD file und generiert daraus mittels SVDConv (--generate=header) ein CMSIS "all-one" Headerfile :-)
:
Bearbeitet durch User
Steve van de Grens schrieb: > Gibt es eigentlich Cortex M basierte Mikrocontroller, die ohne > Spannungsregler mit 3-6 Volt laufen können? Frank K. schrieb: > Nuvoton und Toshiba haben 5V ARMs, aber gängig sind die nicht. Freescale@NXP KEA128, z.B.S9KEA128P80M48SF0: Cortex-M0+, 2.7 - 5.5V, LQFP-64 oder -80, 16K RAM, 128K Flash (15 Jahre bei 85°C nach 10000 Zyklen). Ausgewählte Familienmitglieder gibt's bei Digikey und Mouser ab Lager. Von STM gibt es keine (laut CubeMX-Daten).
:
Bearbeitet durch User
5,5 Volt reicht mir nicht, weil ich dabei Betrieb an 4 AA Zellen im Sinn habe. Dafür brauche ich 6 Volt. (ja ich weiß, bin ein Träumer).
:
Bearbeitet durch User
Steve van de Grens schrieb: > 5,5 Volt reicht mir nicht, weil ich dabei Betrieb an 4 AA Zellen im Sinn > habe. Dafür brauche ich 6 Volt. > (ja ich weiß, bin ein Träumer). Noch nie was von Spannungswandler gehört? Step-Down ist zu simpel oder wie?
Steve van de Grens schrieb: > 5,5 Volt reicht mir nicht, weil ich dabei Betrieb an 4 AA Zellen im Sinn > habe. Dafür brauche ich 6 Volt. Auch 6V reichen nicht. Manche AA-Zellen haben neu 1.9 oder mindestens 1.6V. Schau mal, ob du noch einen IM6100A (den mit 'A') findest, der ist bis 10V spezifiziert. RAM und ROM sind extern. Als RAM bieten sich 3 Stück CDP1822D an, das ergibt 256 12-Bit-Worte. Ein 10V-EPROM fällt mir gerade nicht ein, traditionell nimmt man Maskenprogrammierte, z.B. CDP1834(E). Vorsicht: Wenn bei einem EPROM 12V dran steht, ist das nur die Programmierspannung. Weil das Teil sowieso aus der Batterie läuft, würde ich auch das Programm ins RAM laden. Steve van de Grens schrieb: > (ja ich weiß, bin ein Träumer) herzlichen Glückwunsch!
Steve van de Grens schrieb: > Frage: > Gibt es eigentlich Cortex M basierte Mikrocontroller, die ohne > Spannungsregler mit 3-6 Volt laufen können? Ich meine, wo deren I/O Pins > dann auch diese Spannung haben? Das wäre mal was feines. Ja gibt es. Die Cortex M von WCH können an 5V laufen. Ob das auf alle zutrifft, kann ich nicht sagen der Ch32f103 kann auf jeden Fall an 5V betrieben werden.
M. K. schrieb: > Noch nie was von Spannungswandler gehört? Step-Down ist zu simpel oder > wie? Passt nicht so gut zu Langzeitbetrieb mit wenigen µA Stromaufnahme. Ich weiß, es gibt sparsame lineare Regler. Die nutze ich ja auch zur Zeit.
Bauform B. schrieb: > Manche AA-Zellen haben neu 1.9 oder mindestens > 1.6V. Oh, das wusste ich nicht. Echt so viel?
Bauform B. schrieb: > Manche AA-Zellen haben neu 1.9 oder mindestens 1.6V. Wage ich zu bezweifeln. Dass es eine fertigungsbedingte Streuung gibt ist unstrittig, in dieser Größenordnung aber sehr unwahrscheinlich bis exotisch selten. In jedem Falle aber kein belastbarer Parameter mit dem Steve Van der Grens oder der TO etwas anfangen könnte. Im besten Falle reden wir hier über die Leerlaufspannung einer fabrikfrischen Zelle die unter Belastung ohnehin sofort einknickt. Gruß, DerSchmied
Danke für die vielen Antworten schon mal! Ein paar Sachen dabei, die ich bislang noch so gar nicht auf dem Plan habe - darauf hatte ich auch gehofft. Aber es scheinen sich mehrere Leute darauf einigen zu können, dass die Entwicklung mit/für STM32, und insbesondere die Auffindbarkeit von gutem Beispielcode (mittlerweile) ganz angenehm sei. Also werde ich wohl mal neu evaluieren, was ich mir da eh vor einiger Zeit besorgt hatte. Weiß selbst nicht mehr genau, was ich da habe, aber es ist wohl irgendein STM32 :D Da hier beide angesprochen wurden, und der WCH-Chip für mich zuerst mal aussieht wie ein direkter Klon: In wie weit sind eigentlich STM32F und CH32F miteinander kompatibel? ~jmm
Blöd ist nur, dass die STM32 Chips immer noch nur eingeschränkt und teuer verfügbar sind. Zum Beispiel: Der STM32L072RBT6 kostet derzeit etwa 6 Euro. Vor Corona lag er bei 1,50 Euro, falls ich mich recht erinnere.
:
Bearbeitet durch User
C. D. schrieb: > Bauform B. schrieb: >> Manche AA-Zellen haben neu 1.9 oder mindestens 1.6V. > Wage ich zu bezweifeln. Das Problem ist, es gibt Zellen mit AA-Abmessungen und 1.5V Nennspannung, aber ganz anderer Chemie; siehe oben. Und wer vor allem auf die mAh schaut, nimmt natürlich solche. > Im besten Falle reden wir hier über die Leerlaufspannung einer > fabrikfrischen Zelle die unter Belastung ohnehin sofort einknickt. ok, aber auch "ausreichend sofort" für Chips, die 6V gerade noch überleben würden? Es gibt auch noch die absoluten Mörderzellen mit bis zu 3.7V, aber da steht wenigstens Nennspannung 3.0V oder 3.6V drauf. https://www.reichelt.de/lithium-batterien-c1028.html?ACTION=2&GROUPID=1028&START=0&OFFSET=16&nbc=1&SID=95ddc1cc003054834ada39717e00c7ac729cc2a86771e25579c40
Bauform B. schrieb: > Das Problem ist, es gibt Zellen mit AA-Abmessungen und 1.5V > Nennspannung, aber ganz anderer Chemie; siehe oben. Und wer vor allem > auf die mAh schaut, nimmt natürlich solche. Touche...! Ist schon wahr, kein Mensch außer der Chinese selbst weiß was in China gebraut wird... Die Regelspannung für nichtwiederauflaufbare Zellen der /A...A/ -Reihe liegt dennoch bei 1,5 Volt, und das ist dann ja schließlich die einzige Rechengröße die man verläßlich heranziehen kann. Wenn einzelne Serien Ausreißer nach oben sind wird das sicher nicht immer deklariert sein, also auch nicht verläßlich. Und eigens für das Hobby-Gerät solche Typen mit einzuplanen Stelle ich mir schwierig vor - eben weil sie ja nicht handelsüblich sind. Und auf gut Glück zu hoffen wäre mir zu hoch gepokert... Eine andere angegebene Spannung als die der 1,5V ist mir bei Standard-Zellen noch nicht ins Auge gestochen, daher mein Einwand. Skurriler Weise ist auf Akkus der gleichen Bauform stets eine mehr oder minder korrekt angegebene Kapazität vermerkt, bei den /nicht/wiederaufladbaren Zellen ist mir das noch NIE untergekommen. Würde den direkten Vergleich beim Kauf vereinfachen, aber die Hersteller sähen in der Folge wohl eher einen Einbruch des Umsatzes. Gruß, DerSchmied
J-M M. schrieb: > Da hier beide angesprochen wurden, und der WCH-Chip für mich zuerst mal > aussieht wie ein direkter Klon: In wie weit sind eigentlich STM32F und > CH32F miteinander kompatibel? Möchte nicht, dass diese Frage untergeht (die vllt. mehr mit dem eigentlichen Thema zu tun hat als die Beobachtung verschiedener Batteriespannungen) ~jmm
:
Bearbeitet durch User
J-M M. schrieb: > Möchte nicht, dass diese Frage untergeht da es ja nicht direkt mit der Eingangsfrage zu tun hat sollte dafür eher ein eigener Thread aufgemacht werden. Die CH32 sind nicht 100 % kompatibel, da muss man sich schon durch die Datenblätter des Herstellers wühlen und auch seine Software benutzen. Sich darauf zu verlassen das die STM HAL schon funktionieren wird ist mutig. Da doch schon einige STM32 wieder zu bekommen sind würde ich eher ein Nucleo Board zum Starten nehmen.
Steve van de Grens schrieb: > Ich habe meine Erkenntnisse dort aufgeschrieben, könnte dir helfen: > http://stefanfrings.de/stm32/index.html Stefan, ist "Steve van de Grens" dein alter Ego? Sachen gibts... Zum Thema: Ich finde, dass die STM32Fx "nur" mit CMSIS programmiert, eine gute Alternative sind. Und hier finde ich die Anleitung von Stefan Frings (Link siehe oben) für Einsteiger durchaus brauchbar, gerade wenn man schon etwas Erfahrung mit den AVRs gesammelt hat. STM32F3x gibts bei Mouser in Einzellstückzahlen ab 4 €. Programmierung und debugging geht mit vscode ganz gut. Das Nucelo F303K8 ist vorrätig bei Mouser (über 900 Stück) und kostet 10,33 € (Link: https://www.mouser.de/ProductDetail/STMicroelectronics/NUCLEO-F303K8?qs=kWQV1gtkNndPxYr6NNfTBw%3D%3D)
J. S. schrieb: > Die CH32 sind nicht 100 % kompatibel, da muss man sich schon durch die > Datenblätter des Herstellers wühlen Die WCH Chips sind (zumindest die CH32F103) sind pin und registerkompatibel zu den STM Parts. Es gibt aber nur 64k Flash. Die Teile haben aber zusätzliche Funktionen. (2.UsbSchnittstelle auch im Hostmode, Touchkey Funktion, DA Wandler). Datenblätter gibts inzwischen auf Englisch, viele andere Dokumentation nur auf Chinesisch. Das Flashen mit einem ST-Link ist furchtbar langsam. Mit dem WCH_Link und deren Flashersoftware aber ok. Da die WCH Chips eigene Kennungen haben, muss ST Software nicht zwangsläufig funktionieren.
Klaus R. schrieb: > Steve van de Grens schrieb: >> Ich habe meine Erkenntnisse dort aufgeschrieben, könnte dir helfen: >> http://stefanfrings.de/stm32/index.html > > Stefan, ist "Steve van de Grens" dein alter Ego? Sachen gibts... Wie viele andere, schreibt auch er unter verschiedenen Nicks.
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.