Hallo, ich möchte mich etwas mit Mikrocontrollern befassen ( reines Hobby - paar LEDs zum blinken bringen, paar analogwerte loggen usw. - also reine Spielerei. Programmieren möchte ich in C - vielleicht auch n bisschen Assembler. Ich möchte ausschließlich prozedural programmieren - für objektorientiertes Zeug bin ich zu dumm;-) Gigantische IDEs will ich auch nicht lernen - Editor: ein vim oder fork, vor make würde ich auch nicht weglaufen. OS zum entwickeln MacOS oder halt n virtuelles Linux oder BSD unter Parallels auf dem Mac. Was würdet ihr mir empfehlen ? STM32 / PIC ???
Dann empfehle ich dir AVR Mikrocontroller http://stefanfrings.de/mikrocontroller_buch/index.html Wenn es unbedingt 32 Bit sein soll, dann fange mit einem STM32L0 an. Die "Gigantische IDE" ist da allerdings Standard. http://stefanfrings.de/mikrocontroller_buch2/index.html
Kauf dir einfach ein paar 3€ Platinen, die du über USB brennen und debuggen kannst. Kannst doch beides ausprobieren. IDE, die alles automatisch macht und makefile für standalone Brenner schreiben. Kostet doch beides nur einen Tag und kein Geld. Dann siehst du selbst am besten, was dir liegt. (War mal von PIC Assemblerprogrammierung begeistert. Fand es auch mal toll, dass man bei vim und make noch alles verstehen kann. Heute bin ich der Ansicht, lohnt sich nicht. Einfach mit Arduino Libs ein ESP32 Programm zusammen klicken).
Wladimir schrieb: > Gigantische IDEs will ich auch nicht lernen - Was darf es denn sein? Der billigst mögliche, der der am besten durch die Comunity unterstützt ist, der leistungsfähigste, ein oller 8bitter den man noch ohne mächtige Tools beackern kann der brandneue RiscV der erst noch wachsen muss oder der Raspi Pico mit ganz außergewöhnlichen Hardwarefähigkeiten oder, oder, oder... Gründe den einen zu nehmen und den anderen zu hassen sind so zahlreich wie es MCU Familien gibt.
STM32 / PIC ??? Kannst du es dir nicht leisten selbst beide auszuprobieren? Ich koennte dir auch gerne noch ein Dutzend weiterer interessanter Controllerfamilien aufzaehlen.
Wladimir schrieb: > Gigantische IDEs will ich auch nicht lernen musst du auch nicht: Compiler, Assembler, Linker gibt es auch einzeln, auch hübsch verpackt für den Mac, eins von diesen beiden für kleine und große Cortex-M, z.B. STM32: arm-gnu-toolchain-13.2.rel1-darwin-x86_64-arm-none-eabi.pkg arm-gnu-toolchain-13.2.rel1-darwin-arm64-arm-none-eabi.pkg https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads 32-Bit PIC gibt es ja wahlweise als PIC32M bzw. PIC32C mit MIPS- oder ARM-Kern, dieser Compiler kann beides (anscheinend für Apple- und Intel-Mac in einem Paket): https://www.microchip.com/en-us/tools-resources/develop/mplab-xc-compilers/xc32 Für kleinere PIC gibt es eigene Compiler https://www.microchip.com/en-us/tools-resources/develop/mplab-xc-compilers/xc16 https://www.microchip.com/en-us/tools-resources/develop/mplab-xc-compilers/xc8 Soweit steht es also 1:1 für STM32 und PIC32. Beim Flashen ist PIC klar im Nachteil, man braucht ein PICkit5 (ja, -3 oder -4 geht auch). Die STM32 haben alle ab Werk einen UART-Bootloader, zum Flashen reicht also jeder PC mit serieller Schnittstelle. STM32 haben den großen Nachteil, dass alle Leute HAL benutzen. Manche PIC sind bei den Abblock-Cs ziemlich anspruchsvoll, im Datenblatt sind genau 2 aktuelle Typen gelistet. Da gibt es noch ein paar Argumente: https://forum.microchip.com/s/topic/a5C3l000000MbjeEAC/t375114?page=1
Bauform B. schrieb: > Wladimir schrieb: >> Gigantische IDEs will ich auch nicht lernen > > musst du auch nicht: Compiler, Assembler, Linker gibt es auch einzeln, > auch hübsch verpackt für den Mac, eins von diesen beiden für kleine und > große Cortex-M, z.B. STM32: > arm-gnu-toolchain-13.2.rel1-darwin-x86_64-arm-none-eabi.pkg > arm-gnu-toolchain-13.2.rel1-darwin-arm64-arm-none-eabi.pkg > Oh Danke! Das war jetzt sehr ausführlich zu STM32 und PIC - das werde ich mal ausprobieren … und nochmals vielen Dank für das ausführliche posting mit den komfortablen Links Grüße
Wladimir schrieb: > und nochmals vielen Dank für das ausführliche posting mit den > komfortablen Links Alles viel zu aufwändig! Wenn du WIRKLICH minimalistisch einsteigen willst, nimm einen Arduino Nano oder Raspberry PI Pico. Beide sind sehr einfach mit der sehr einfachen, anfängerfreundlichen Arduino-IDE programmierbar. https://www.arduino.cc/en/software Für viele einfache und weitergehende Spielereien reicht der Nano von der Leistung her. Der Pico hat, entgegen dem Namen, nochmal DEUTLICH mehr Dampf und Speicher und kostet deutlich WENIGER! Muss man nicht verstehen! https://store.arduino.cc/products/arduino-nano 8 Bit, 16MHz, 32kB Flash, 2kB RAM, 21 Euro https://www.raspberrypi.com/products/raspberry-pi-pico/ 32 Bit, 133MHz, 2MB Flash, 260k RAM, 4,5 Euro
Wladimir schrieb: > ich möchte mich etwas mit Mikrocontrollern befassen ( reines Hobby - > paar LEDs zum blinken bringen, paar analogwerte loggen usw. - also reine > Spielerei. Du möchtest die Arduino IDE verwenden. Glaube es, oder auch nicht...... Wladimir schrieb: > bin ich zu dumm;-) Könnte auch sein.....
Wladimir schrieb: > Was würdet ihr mir empfehlen Du bist der Kunde für Arduinos. Es gibt dort auch ST uC, aber die meisten sind Atmel uC von Microchip wie ATmega328. Reicht für blinkende LED und Analogwertverarbeitung locker aus. Und das, was dort von objektorientiertem C++ genutzt wird, wird dir gefallen.
Falk B. schrieb im Beitrag > https://www.raspberrypi.com/products/raspberry-pi-pico/ > 32 Bit, 133MHz, 2MB Flash, 260k RAM, 4,5 Euro Oh … der pi pico! Den hatte ich noch gar nicht auf dem Schirm. Damit ist C kein Problem - der Mac nebst nvim ist auch kein Problem - das Teil ist spottbillig … und für schnelle dirty-Sachen wäre noch Python ideal😉 Es hat sich auf jeden Fall gelohnt / hier im Forum mal so ne Fragestellung reinzuhauen Danke Euch!
Motopick schrieb: > STM32 / PIC ??? Wenn PIC dann welcher PIC? Es gibt da unzählige Familien mit unzähligen Möglichkeiten, Spezialhardware etc.pp. Den alten Kampf AVR gegen PIC hat längst der STM32 für sich entschieden, der aber angesichts der zahlreichen spottbilligen und extrem leistungsfähigen Rechenknechte auch bereits von allen Seiten bedrängt wird. Wer tatsächlich auf der bare metal ebene anfangen will wo er noch jedes Register kennt, der muß etwas altes in 8bit nehmen das für die Leistung viel zu teuer ist. Dann lieber AVR als PIC, weil jeder PIC anders ist. Wer den ganzen geilen Spielkram will, greift zum ESP32, Pico etc. Wer besonders billig will, greift zu den hier fast völlig unbekannten Chinesischen Firmen mit per Google übersetzten DBs. Oder was ganz neuen als Risc-V oder was besonders stromsparendes als MSP430 oder die absonderlichsten SoCs mit untrennbarer HW, SW, IDE in halb grafischer Programmierung, die PSocs die nunmehr zu Infineon gehören. Die Frage 'was ist der beste' ist so einfach nicht zu beantworten. Preis, Leistung, Spaßfaktor würde ich ESP32 oder Pico sagen. Langzeitverfügbarkeit, Support, Qualität der Tools, Variantenvielfalt, potentielle Lieferkettenprobleme, da würde ich klar zum STM32 tendieren. Wenn es um den einfachsten mit der stärksten Community und einer IDE für schnelle und motivierende Erfolge geht, dann muß es wohl Arduino mit AVR sein.
> Den alten Kampf AVR gegen PIC hat längst der STM32 für sich entschieden, Das ist doch herbeigeredeter Unsinn. Ich kann die Vorzuege jeder dieser und noch einiger anderer Familien nutzen. Wenn du nur noch STM32 kennst/kannst, ist das nur dein Problem und kein allgemeines Auswahlkriterium. Mit programmierbarer Logik kannst du wahrscheinlich auch nicht umgehen. Ich muss auch keine 21 Euronen in so etwas versenken: > 8 Bit, 16MHz, 32kB Flash, 2kB RAM, 21 Euro Ich weiss naemlich noch wo der Kaefer seine Beine hat...
Motopick schrieb: > Ich weiss naemlich noch wo der Kaefer seine Beine hat... So wie jeder Anfänger? Schön für dich. Als Anfänger möchte man vielleicht möglichst schnell Erfolgserlebnisse haben. Eine (integrierte) LED blinken zu lassen, geht da ziemlich fix (auch, weil entsprechende Beispiele der IDE "beiliegen").
> So wie jeder Anfänger? Auch fuer den Z80 gab es eine gedruckte Pinbelegung. Und Mann war gut beraten, den Unterschied zwischen "GND" und "+5 V" zu kennen. Ich hatte zuvor zugegebenermassen einiges an TTL, pMOS und OPVs auf Leiterkarten versenkt. Sind die Menschen seit damals denn duemmer geworden? Oder koennen sie auf Papier gedrucktes nicht mehr lesen? > möglichst schnell Erfolgserlebnisse Ja damit lockt man sie an. Nur lernen sie dabei (fast) nichts. Und aus dem Buddelkasten finden sie auch selten wieder raus. Weil das Gelernte nur fuer die Verwendung im Buddelkasten war, und anderenorts wenig bis keine Bedeutung hat. Wo der Loetkolben das heisse Ende hat, muss man ihnen erst zeigen. > Eine (integrierte) LED blinken zu lassen Du bist aber billig abzuspeisen.
Motopick schrieb: >> möglichst schnell Erfolgserlebnisse > Ja damit lockt man sie an. Nur lernen sie dabei (fast) nichts. Bei einem Hobby geht es erst mal darum, heraus zu finden, was einem gefällt. Dafür eignet sich Arduino meiner Meinung nach sehr gut.
Motopick schrieb: > Wenn du nur noch STM32 kennst/kannst Wenn Du halb so gut sinnerfassend lesen könntest wie Du pöbeln kannst, könntest Du Dir das meiste Deiner Pöpeleien sparen. Du bist ja ein ganz toller Hecht, das Du mehr kennst als den STM32 und verschiedene MCUs mit ihren jeweiligen Stärken einsetzen kannst. Höre ich gern. Da sind wir ja schon zwei. Aber nun erkläre mir bitte, wie ein Anfänger mit allen MCUs zeitgleich anfangen soll die Du alle kennst. Erstmal muss er sich ja EINE aussuchen und die sollte ihm möglichst liegen und Spaß machen, sonst wird er Youtuber oder Popstar oder studiert lieber BWL.
Michael schrieb: > > Erstmal muss er sich ja EINE aussuchen und die sollte ihm möglichst > liegen und Spaß machen, sonst wird er Youtuber oder Popstar oder > studiert lieber BWL. … und wenn das alles nicht gelingt - ein Posten bei unseren Parteien winkt!
Motopick schrieb: > Ja damit lockt man sie an. Nur lernen sie dabei (fast) nichts. > Und aus dem Buddelkasten finden sie auch selten wieder raus. > Weil das Gelernte nur fuer die Verwendung im Buddelkasten war, > und anderenorts wenig bis keine Bedeutung hat. Leider wahr. Die Arduino IDE und die Spielereien darin haben für mich anfangs den Eindruck eines "guten einstieg" erweckt. Um Grundlagen zu erlernen die man später braucht, also die reinen basics, ist das auch ganz ok. Alles was aber den Einsatz einer lib erfordert (displays, eeprom usw..) bringt dir später allerdings nix. Du lernst ja nur deren bastelkasten besser zu nutzen.
PIC32 kann ich nicht empfehlen. Da ist nicht mal ein zusammenhaengendes, oder segmentiertes Datenblatt/-buch erhaeltlich.
Kilo S. schrieb: > Alles was aber den Einsatz einer lib erfordert (displays, eeprom usw..) > bringt dir später allerdings nix Niemand wird gezwungen Libs zu benutzen. Es ist eine individuelle Entscheidung. Zudem will ihm ja kein OOP verwenden, sondern C und ASM. Da ist die Lib Unterstützung in der Arduino Welt sowieso so dünn, dass man quasi alles selber bauen muss. Deine Argumentation geht also an den Bedürfnissen des TO vollkommen vorbei. Ist einfach nur blindes Arduino Bashing.
:
Bearbeitet durch User
Kilo S. schrieb: > Alles was aber den Einsatz einer lib erfordert (displays, eeprom usw..) > bringt dir später allerdings nix. > Du lernst ja nur deren bastelkasten besser zu nutzen. Jein. Für später muss man auch lernen fremder Leute Bastelkästen zu benutzen. Es ist einfach sinnlos komplexe Funktionen selber zu schreiben die es bereits zur freien Verwendung gibt.
Michael schrieb: > > Es ist einfach sinnlos komplexe Funktionen selber zu schreiben die es > bereits zur freien Verwendung gibt. Nur jemand, der die Defizite, Grenzen und Nachteile von Rädern kennenlernen durfte oder musste / konnte die Motivation haben, Panzerketten zu erfinden!
Falk B. schrieb: > Alles viel zu aufwändig! Wenn du WIRKLICH minimalistisch einsteigen > willst, nimm einen Arduino Nano oder Raspberry PI Pico. Beide sind sehr > einfach mit der sehr einfachen, anfängerfreundlichen Arduino-IDE > programmierbar. Ich habe in dieser Welt mit dem ESP32 angefangen. Inzwischen genügt ein D1Mini für meine aktuellen Anforderungen. Kennst Du diesen Link? https://randomnerdtutorials.com/ mfg Klaus
Arduino F. schrieb: > Ist einfach nur blindes Arduino Bashing. Nö, die IDE ist so lange wie man in deren Umfeld bleibt praktisch und schnell. Ich benutze sie auch, aber finde trotzdem das die libs es trotzdem manchmal "zu einfach" machen und so das eigentliche lernen nicht so ausgeprägt ist wie das "copy & paste" programmieren.
Angehängte Dateien:
-
PIC32RE.PNG
88 KB
Purzel H. schrieb: > PIC32 kann ich nicht empfehlen. Da ist nicht mal ein zusammenhaengendes, > oder segmentiertes Datenblatt/-buch erhaeltlich. Meinst du die "PIC32 Family Reference"?
Angehängte Dateien:
-
Pic32Family.png
38 KB
> Meinst du die "PIC32 Family Reference"?
Ja, genau, abgesehen davon, dass sie nicht vollstaendig ist.
Ja schein ja heute normal zu sein, einen 32 Bitter zu benötigen, natürlich mit Quarz und komplizierter Versorgung um eine LED zu dimmen, und das mit einer IR Fernbedinung. Ich bin eher stolz darauf das ohne gedöhns auf einem 8bit 8Pin Controller mit etwas Assembler zu schaffen. Das hat den Vorteil, das das Ding ohne Schalter und ohne WDT seit 12 Jahren 24/7 im Caravan einfach läuft. Wenn Du das auf einem 32 Bitter schaffst und dabei deutlich unter 1mA Ruhestrom bist, denke ich mal drüber nach, glaube aber nicht daran so alt zu werden. MfG Michael
Michael O. schrieb: > Wenn Du das auf einem 32 Bitter > schaffst und dabei deutlich unter 1mA Ruhestrom bist, denke ich mal > drüber nach, glaube aber nicht daran so alt zu werden. Dann solltest du deinen Lebensstil überdenken. Das ist nun wirklich kein Hexenwerk. So ein moderner STM32 braucht weniger als 100µA pro MHz im Betrieb (und noch viel weniger in einem der diversen Sleep-Modi) und lässt sich über eine PLL auch entsprechend niedrig takten. Dazu noch einen einfachen Spannungsregler für eine einzige 3,3V Versorgung und fertig ist die Laube. Nichts anderes braucht jeder AVR. Ich sehe nicht, was daran komplizierter ist als ein 8Bitter mit handgeklöppeltem ASM (was deutlich schlechter portierbar als sauberes C ist).
:
Bearbeitet durch User
Stefan S. schrieb: > und lässt sich über eine PLL auch entsprechend > niedrig takten. für so eine pillepalle Aufgabe schalte ich die PLL nichtmal ein und ein 32 Bitter schläft da die meiste Zeit unter 1 µA. Wie kommen die Leute immer auf das schmale Brett das 32 Bitter mehr Strom verbrauchen? Die meisten sind in moderneren Prozessen mit kleinen Strukturen gefertigt, das ist was für die Stromaufnahme zählt. Der 32 Bitter ermöglicht aber auch die Bedienung mit Smartphone an Webserver über WLAN. Oder Displays mit ansehnlicher Grafik. Oder Ethernet. Oder alles gleichzeitig. Ja, wenn einen das Dimmen einer LED glücklich macht dann kann man in seiner 8 Bit Welt bleiben.
J. S. schrieb: > Die meisten sind in moderneren Prozessen mit kleinen Strukturen > gefertigt, das ist was für die Stromaufnahme zählt. Ja, eben. Kleine Strukturen => hohe Leckströme. (>:-) Ja, ist wirklich so. Es gibt einen Grund, warum nicht alles irgendwie in 13 nm oder dergleichen dahin gedengelt wird. Entgegen landläufiger Behauptungen gibt es natürlich auch absolut gar keinen Grund, kleine MCUs in Assembler zu befüllen – genauso, wie es keinen Grund gibt, warum man einen ARM nicht auch in Assembler programmieren könnte. Obwohl es beim Cortex-M erklärtes Ziel war, dass der gar keinen Assemblercode mehr braucht, liefern viele Hersteller (aber nicht alle) beispielsweise den Startup-Code nach wie vor als Assembler-Gewusel.
:
Bearbeitet durch Moderator
In der Praxis haben die Cortex-M viel mehr Run und Sleep Modi sowie Takteinstellungen die dynamisch angepasst werden können. Ich bezweifle stark das ein 8 Bitter da Vorteile beim Stromverbrauch hat.
J. S. schrieb: > Ich bezweifle stark das ein 8 Bitter da Vorteile beim Stromverbrauch > hat. Hat er durchaus. Allerdings muss man auch erstmal mit dem restlichen Design bis dahin kommen, dass man das ausreizen kann. Der Aufwand, um insgesamt dauerhaft unter 1 µA zu kommen, steigt dann ziemlich stark an. Mein Temperatursensor läuft mit einem LR03-Batteriesatz viele Jahre (5+), dabei sendet er alle 5 Minuten per IEEE 802.15.4 seine Messdaten. Das Ganze aber auch im Außenbereich hinzubekommen, hatte viele vorangegangene Fehlversuche, vor allem wegen der Feuchtigkeit. Dort steckt dann der eigentliche Aufwand, nicht in der Wahl der MCU. Ansonsten: das Einzige, wo klassische AVRs in dieser Hinsicht etwas im Nachteil sind ist, dass man die Taktquelle nicht im Betrieb sondern nur per Fuse umschalten kann. Ausreichend herunter skalieren können die ihren Takt auch, wenn man das will.
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Dort steckt dann der eigentliche Aufwand, nicht in der Wahl der MCU. das sehe ich auch so, mein Funkthermometer mit LPC812 und RFM69 habe ich hier ja auch schon oft genug erwähnt. Da ist auch das Funkmodul das Limit, das möchte >= 2,7 Volt haben um zu funken. 2 AA Batterien sind da nach Jahren nicht leer und der µC wäre lange weiter zufrieden damit, nur der Funk setzt dann aus. Es wäre aber auch hier kein Vorteil einen AVR zu nehmen.
J. S. schrieb: > Da ist auch das Funkmodul das Limit, das möchte >= 2,7 Volt haben um zu > funken. Falsches Funkmodul :-) Bei mir macht das alles ein ATmega128RFA1 SoC, der geht bis 1,8 V herunter … :-) Allerdings habe ich auch den UHF-Teil selbst gebaut, fertige Funkmodule (wie ein Zigbit) waren auch schon nach kurzer Zeit vor sich hin korrodiert.
J. S. schrieb: > Da ist auch das Funkmodul das > Limit, das möchte >= 2,7 Volt haben um zu funken. 2 AA Batterien sind da > nach Jahren nicht leer und der µC wäre lange weiter zufrieden damit, nur > der Funk setzt dann aus. Wäre Li-Ion mit kleinem Solar keine Option?
Jörg W. schrieb: > Falsches Funkmodul :-) ja, wenn man Funktamateur ist und auch Messtechnisch ein paar Möglichkeiten mehr hat... Die RFM sind halt gut verfügbar, günstig und es gibt viel SW Support. Das RFM95 (LoRa) braucht auch nur 10 mA zum Senden und geht runter bis 1,8 V. Alles besser als die ESP die ein Kraftwerk brauchen. Georg M. schrieb: > Wäre Li-Ion mit kleinem Solar keine Option? für draußen sicher schon, aber ich habe die auch in der Wohnung liegen und bei einem kalten Winter (wenn es den mal wieder gäbe) halten so Akkus auch nicht gut. Ich hatte die auch lange Zeit zum Test zu schnell im 10 oder 20 s Intervall funken und war dann zu faul das umzustellen. Alle paar Minuten ist natürlich auch ausreichend und das stresst die Batterien viel weniger. Dann habe ich einen mit StepUp betrieben, höherer Ruhestrom aber die Batterie konnte bis zur totalen Erschöpfung verwendet werden. Das lief bei dem kurzen Intervall auch etwa 2 Jahre mit 2x AA. Den StepUp nur zum Funken einzuschalten wäre noch besser, aber einen Tick mehr Aufwand. Da kann man viel forschen und basteln, jetzt bin ich noch fauler und habe einige ZigBee Sensoren. Gerade Türkontakte sind da sehr billig, da stellt sich schon wieder die Frage nach dem Sinn des Lebens und ob der Selbstbau da noch lohnt. Gut, das selber machen ist lehrreich. Und es ist sinnvoll auch bei den 32 Bittern klein anzufangen, sofort alles in einem Projekt haben zu wollen führt definitiv zu viel Frust. An jeder kleinen Hürde kann man sich lange aufhalten. Deshalb würde ich wie vom TO abgelehnt doch eine IDE empfehlen und das einfache Debugging der Cortex-M nutzen. Zu sehen was wirklich im Code passiert und nicht was man hofft führt oft zu Überraschungen.
J. S. schrieb: > und das einfache Debugging der Cortex-M nutzen Braucht man aber auch nicht unbedingt eine IDE dafür. ;-) GDB funktioniert auch im normalen Textmodus (wenngleich selbst ich da die Integration in den Emacs bevorzuge :). Aber völlige Zustimmung, in-system-debugging ist ein nettes Feature.
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.