Hallo,
ich möchte gerne die Beschäftigung mit Mikrocontrollern wiederbeleben.
Bisher hatte ich eher mit kleinern Basteleien mit ATMega & M16C zu tun,
aber auch das ist schon wieder ein paar Tage her.
Was ich Suche:
Vor Allem modern und universell einsetzbar sollte die
Mikrocontroller-Familie sein. D.h. Eignung sollte vom ganz einfachen,
batteriebetriebenen Sensor bis hin zu mittleren Anwendungen gehen.
Bei Bedarf umfangreiche Peripherieoptionen zu aber ingesamt günstigen
Preisen, falls ich dochmal was in Stückzahl basteln will (z.B.
CAN/Hausbus) wäre mir noch ein Anliegen.
Bekanntsheitgrad und somit Forensupport sowie eine kostenlose, gute IDE
sind natürlich auch von Bedeutung ...
Alles in Allem komme ich meiner Einschätzung nach da bei STM32 raus.
Würdet ihr mir bestätigen, dass das die richtige Wahl ist?
Gibt es auch eine aktuelle Empfehlung für ein bestimmtes DEV-Board für
die ersten Schritten, vielleicht auch mit Taster & Leds/Display,
vielleicht CAN Transceiver und natürlich alle Anschlüsse nach aussen
geführt.
Falls zusätzlich (auch für debugging) benötigt welcher Programmer?
Das ganze im Komplettset mit ein bisschen Breadboard und
Breadboard-Jumpern wäre auch OK.
Danke
Chris
Chris schrieb:> Alles in Allem komme ich meiner Einschätzung nach da bei STM32 raus.> Würdet ihr mir bestätigen, dass das die richtige Wahl ist?
Wir können doch nicht wissen, worauf Deine Einschätzung beruht.
Wenn Du eine Bestätigung willst, mußt Du uns schon die Gründe nennen.
Wir ahnen, irgendwas scheint Dir an den AVRs nicht zu gefallen und daher
willst Du wechseln.
Peter D. schrieb:> Wir können doch nicht wissen, worauf Deine Einschätzung beruht.> Wenn Du eine Bestätigung willst, mußt Du uns schon die Gründe nennen.> Wir ahnen, irgendwas scheint Dir an den AVRs nicht zu gefallen und daher> willst Du wechseln.AVR gegen STM32 ...
Der einzige Grund für AVR wäre die 5V Technik und DIL Gehäuse, wenn man
es denn braucht.
STM32 Boards sind so billig und leistungsfähig, und in einer Vielzahl an
Varianten erhältich, dass AVR kein Thema mehr sein sollte.
Ja bei STM32 bist du richtig da der ST-Link Debugger auch sehr günstig
ist. Statt dem Nucleo würde ich dir aber die Discovery Boards empfehlen.
Vorteil gegenüber AVR ist das du mittels Jtag/SWD debuggen kannst, mal
abgesehen von den viel leistungsfähigeren MCUs.
Thomas W. schrieb:> STM32 Boards sind so billig und leistungsfähig, und in einer Vielzahl an> Varianten erhältich, dass AVR kein Thema mehr sein sollte.
Das kann man so pauschal nicht sagen.
Als Frontend sind STM32 bestimmt besser geeignet, aber um bestimmte
Sensoren, Zeitkritische Abfragen und Steuerungen zu realisieren,
sind AVRs um ein vielfaches einfacher, genauer und somit für so etwas
besser geeignet.
Niemand tut sich Assembler beim STM32 an, deswegen wird alles,
was eine Präzision in ns Bereich erfordert, mit AVRs realisiert.
STM32 übernimmt dann die Rolle des Gehirns und Koordinators.
Gilt für Industriesteuerungen, aber auch für Smarthome etc.
Ansonsten sind STM32 weit überlegen, gar keine Frage.
Marc V. schrieb:> Das kann man so pauschal nicht sagen.> Als Frontend sind STM32 bestimmt besser geeignet, aber um bestimmte> Sensoren, Zeitkritische Abfragen und Steuerungen zu realisieren,> sind AVRs um ein vielfaches einfacher, genauer und somit für so etwas> besser geeignet.> Niemand tut sich Assembler beim STM32 an, deswegen wird alles,> was eine Präzision in ns Bereich erfordert, mit AVRs realisiert.> STM32 übernimmt dann die Rolle des Gehirns und Koordinators.> Gilt für Industriesteuerungen, aber auch für Smarthome etc.
<Kopfschuettel>
STM32 hat ein vielfaches an maechtigeren Timer. Damit realisiert man
Präzision!
Marc V. schrieb:> Als Frontend sind STM32 bestimmt besser geeignet, aber um bestimmte> Sensoren, Zeitkritische Abfragen und Steuerungen zu realisieren,> sind AVRs um ein vielfaches einfacher, genauer und somit für so etwas> besser geeignet.
Alle meine wirklich zeitkritischen Aktionen auf dem STM32 benötigen
keine CPU-Intervention, sondern laufen mit Timern und DMA ab. U.a.
paralleles Sampling von 2 AD-Kanälen im 2,7Mhz-Takt, dazu exakt
synchrone Pattern auf mehreren Digital-Pins.
Auf einem AVR wäre nichts davon zu realisieren gewesen, geschweige denn
die anfallenden Daten auch noch zu verarbeiten.
Gruß, Stefan
Praktisch jeder Hersteller hat sogenannte Evaluation Boards.
Die beinhalten den vorzustellenden Mikrokontroller und meist noch ein
paar LEDs und Taster für erste Versuche.
Sehr oft haben diese einen USB-Anschluss über den einige Versuche
abgewickelt werden können und meist auch eine (Um-)Programmierung
möglich ist.
Im Großen und Ganzen bleibt dann nur noch die Frage: 8-, 16- oder
32-Bit.
Welchen: Frag 100 Leute und Du bekommst 102 verschiedene Antworten, oder
mehr.
Heutzutage wird diese Frage auch oft mit der Gegenfrage: "Was brauchst
Du denn beantwortet". Aber schon die Liste eines Herstellers, mit
Angaben zur Leistungsfähigkeit (meist in MHz), zur der Anzahl an
Anschlüssen, zur integrierten Peripherie, zum verfügbaren FLASH und RAM,
ist nur sehr schwer zu verdauen. Und das gilt nur für einen Hersteller.
Ich würde auch zu STM32 raten. Habe vor Jahren (2008+) viel mit F103 und
F407 gemacht. Was mir aber an vielen Eval Boards nicht sehr gefällt ist
die Wahl der Gehäuse. Viele dieser Boards haben nur 64-pinnige uC drauf
und relativ kleinen FLASH Speicherplatz. Da gibt es oft Konflikte mit
alternative Peripheralfunktionen. Bei der 100-Pin Ausführung hat man
schon etwas mehr Ellenbogenfreiheit. Sonst würde ich zu 144/176
Versionen raten.
Die Discovery Bords haben so viel Peripherie drauf, daß man oft nicht
mehr genug ungebrochene IO ports für pin hungrige Peripherie hat.
Wer höher auflösende TFT LCD betreiben will ist mit den Typen mit
eingebauten Graphic Controller (F429) auch besser bedient.
Auch würde ich raten, keine Typen mit unter 512kB FLASH zu wählen. Es
ist für Entwicklungszwecke angenehmer eher mehr FLASH Speicherplatz zu
haben als zu wenig.
Sonst finde ich die STM32s recht praktisch. Machte damals meine ersten
Erfahrungen mit der freien Version von Atollic und älteren Versionen von
CooCox.
Marc V. schrieb:> Das kann man so pauschal nicht sagen.> Als Frontend sind STM32 bestimmt besser geeignet, aber um bestimmte> Sensoren, Zeitkritische Abfragen und Steuerungen zu realisieren,> sind AVRs um ein vielfaches einfacher, genauer und somit für so etwas> besser geeignet.> Niemand tut sich Assembler beim STM32 an, deswegen wird alles,> was eine Präzision in ns Bereich erfordert, mit AVRs realisiert.> STM32 übernimmt dann die Rolle des Gehirns und Koordinators.> Gilt für Industriesteuerungen, aber auch für Smarthome etc.>> Ansonsten sind STM32 weit überlegen, gar keine Frage.
Was für ein Bockmist. Nehmen wir mal den Arduino AVR - den Atmega 328P.
Einen maximalen Takt von 25 MHz -> minimale Periodendauer von 40ns. Wie
willst du da eine Präzision im ns Bereich erreichen? Das ist
allerbestens im 10er ns Bereich, und alleine bis du im Interrupt bist,
sind schon 100ns vergangen. Also hör auf zu quatschen.
Zur Frage:
AVR werden gerne zum Einstieg genommen, weil: leicht, einfach. Das hat
aber auch den Nachteil, dass die Dinger (zumindest die 0815 wie die
Arduinos) doch begrenzt in Ihrer Peripherie sind. Vor allem wenn man die
ganze Welt der heutigen µC Peripherie und Entwicklung (DMA, HW CRC
Calculator etc.) nutzen möchte, haben die STMs (oder NXPs) einen
gewaltigen Vorsprung (ist ja klar, sind einfacher aus neuerem Datum).
Meine Empfehlung (bin aber weder ein AVR Basher noch ein ARM Liebhaber,
haben beide Vor- und Nachteile):
- Kauf dir ein billiges mbed Kompatibles Board (z.B. irgendein Nucleo
oder Discovery Board)
- Spiel erstmal mit mbed rum (sowas wie Arduino, nur im Browser und für
ARMs), das hat ungefähr den gleichen Abstraktionsgrad wie die Arduino
IDE.
- Stück für Stück kannst du dich dann auch in anspruchsvollere Gewässer
vortrauen und irgendwann mal eine offline IDE nutzen. Da kann man dann
atollic, eclipse + gnuarm oder sonst was nutzen.
- Dann kann man sich auch mit der wirklich interessanten Peripherie
auseinandersetzen und kriegt so ein Gefühl für HW Programmierung und für
gewisse Peripherie im allgemeinen.
Ich würde da PICs vom Microchip empfehlen. Für die AVRs und ARMs gibt es
hier kaum Support im Forum.
Ich gehe jetzt in den Garten um mir ein tiefes Loch zu graben um den nun
folgenden Proteststurm zu überstehen. :)
Auf eine bestimme Reihe oder Hersteller würde ich mich nicht unbedingt
festlegen. Das würde ich je nach Anforderung entscheiden.
Uwe B. schrieb:> <Kopfschuettel>> STM32 hat ein vielfaches an maechtigeren Timer. Damit realisiert man> Präzision!Stefan K. schrieb:> Alle meine wirklich zeitkritischen Aktionen auf dem STM32 benötigen> keine CPU-Intervention, sondern laufen mit Timern und DMA ab.
Ich sprach von Industriesteuerungen und ns, da ist mit C und Timers
nicht mehr viel von der Präzision übrig, es sei denn, es handelt sich
um höchstens 1-2 Aktoren/Sensoren und die jeweiligen INT-Routinen
unterbrechen sich nicht gegenseitig.
> paralleles Sampling von 2 AD-Kanälen im 2,7Mhz-Takt, dazu exakt> synchrone Pattern auf mehreren Digital-Pins.
Ich nenne das "fire and forget" und es ist eine gute Sache.
So etwas macht man mit DMA, das kann ein STM32 bestimmt besser als
AVR, aber davon sprach ich nicht.
ui schrieb:> Einen maximalen Takt von 25 MHz -> minimale Periodendauer von 40ns. Wie> willst du da eine Präzision im ns Bereich erreichen? Das ist> allerbestens im 10er ns Bereich, und alleine bis du im Interrupt bist,> sind schon 100ns vergangen. Also hör auf zu quatschen.
Genau, man soll nicht über Dinge reden, von denen man keine Ahnung hat.
Also hör du auf zu quatschen.
Erstens sind es max. 20Mhz aber diese 20MHz sind voll da, es wird nur
diese eine einzige Aufgabe ausgeführt.
Und man weiss genau, dass immer nach 250ns (als Beispiel) Interrupt
Routine angesprungen und ausgeführt wird. Diese Routine wird aber
auch nicht unterbrochen und auch das ist das wesentliche bei
Industriesteuerungen - eine feste Verzögerung kann man immer
kompensieren, es ist überhaupt kein Nachteil in dem Sinne.
Wichtig ist nur, dass diese Verzögerung immer gleich bleibt.
Und genau diese Anforderung kann ein STM32 der noch dazu in C oder C++
programmiert wird, niemals erfüllen - es sei denn, es wird nur diese
eine Aufgabe abgearbeitet - das kann aber ein AVR wahrscheinlich
genauso gut machen.
Dafür kann der STM32 aber Daten von mehreren AVRs quasi in Echtzeit
bearbeiten und Entscheidungen treffen, ohne sich überhaupt gross
anzustrengen.
Und deswegen sprach ich von Frontend und Aktionen im Hintergrund.
Dass man heutzutage bei den Preisen genausogut einen STM32 anstatt
einen AVR benutzen kann, steht ausser Frage.
Jürgen D. schrieb:> Ich gehe jetzt in den Garten um mir ein tiefes Loch zu graben um den nun> folgenden Proteststurm zu überstehen. :)
"Jedem Tierchen sein Pläsierchen!"
Es gibt doch für jeden uC eine zweckmäßige Wahl. In meinem Universum
leben PICs, AVR, Z8, 8051, und ARM friedlich nebeneinander. Manche
unterhalten sich auch miteinander ohne Sprachschwierigkeiten;-)
Freu dich auf Bugs ... schwer zu findende Bugs :-)
BBT: es scheint für die ARM muss man erst mehrere Bücher lesen, von der
ARM-Historie über Architektur bis zum Befehlssatz usw.
> vom ganz einfachen...bis hin zu mittleren Anwendungen gehen.
Was sind denn für Dich mittlere Anwednungen?
Für mich sind mittlere Anwendungen z.B. Lichtschalter mit Webserver.
Dazu reichen die ATmegas so gerade eben aus, mit einem STM32 Controller
hätte ich es hier sicher leichter. Ich bleibe trotzdem möglichst bei
AVR's, denn mit denen bin ich vertraut und für die habe ich sowohl die
nötige Hardware als auch die nötige Software stabil am Laufen.
Für mich zählt weniger die universelle Eignung. Ich nehme das, womit ich
bereits klar komme. Irgendwann werde ich wohl mal was größere brauchen,
doch wann das sein wird, steht seit 10 Jahren in den Sternen. Länger,
als ich dachte.
Chris schrieb:> ich möchte gerne die Beschäftigung mit Mikrocontrollern wiederbeleben.Chris schrieb:> Alles in Allem komme ich meiner Einschätzung nach da bei STM32 raus.> Würdet ihr mir bestätigen, dass das die richtige Wahl ist?
Ah ja.. was du haben willst, ist ein Butler, der dir die Bastel-Arbeit
macht. Aber was willst du eigentlich erreichen? Pure Beschäftigung? Dann
kümmere dich lieber um deine Familie. Den Kindern was vorlesen z.B.
Ansonsten können hier so ziemlich alle Anwesenden bestätigen, was auch
immer du hier bestätigt haben willst.
Und eine "kostenlose, gute IDE" findest du auch, gar kein Problem.
Also wenn du eine IDE haben willst und dazu ein fertiges Brettl mit nem
µC drauf, wo du dich mit beschäftigen kannst, dann bist du bei STM32
ganz sicher richtig.
Sicherlich wärest du auch mit anderen IDE's und anderen µC auf anderen
Boards "richtig", aber da du nun mal STM32 anzielst, dann nimm halt die.
Schönen Freitag.
W.S.
Marc V. schrieb:> Ich sprach von Industriesteuerungen und ns, da ist mit C und Timers> nicht mehr viel von der Präzision übrig, es sei denn, es handelt sich> um höchstens 1-2 Aktoren/Sensoren und die jeweiligen INT-Routinen> unterbrechen sich nicht gegenseitig.
Unter "Timers" verstehst Du aber schon die Hardware-Timer eines
Microcontrollers? Alle zeitkritischen Hardware-Aktionen sollten mit
Hardware-Timern und ihren Capture/Compare Registern bearbeitet werden,
egal ob es sich um ATmega oder ein ARM-Derivat handelt.
Marc V. schrieb:> Erstens sind es max. 20Mhz aber diese 20MHz sind voll da, es wird nur> diese eine einzige Aufgabe ausgeführt.> Und man weiss genau, dass immer nach 250ns (als Beispiel) Interrupt> Routine angesprungen und ausgeführt wird.
Ein Atmega-Befehl braucht zwischen 1 und 4 Takten. Dadurch hat ein
Interrupt-Einsprung immer einen Jitter von 3 Takten, was bei 20Mhz 150ns
entspricht.
Das setzt aber voraus, daß im System NUR dieser eine Interrupt aktiv
ist, da beim ATmega ein Interrupt default nicht unterbrechbar ist. Ein
System mit nur einem erlaubten Interrupt halte ich aber auch bei sehr
kleinen Anwendungen für unüblich.
Wenn man wirklich ein ns-genaues Timing benötigt, dann führt auch beim
ATmega kein Weg an der Verwendung der Hardware-Timer vorbei.
Gruß, Stefan
Chris schrieb:> Alles in Allem komme ich meiner Einschätzung nach da bei STM32 raus.> Würdet ihr mir bestätigen, dass das die richtige Wahl ist?
Kommt auf dich an.
Vorteile von STM32:
Billiger Debugger + Entwicklungsboards verfügbar (Discovery)
Freie Entwicklungsumgebung verfügbar.
Modern.
Verbreitet.
Aber:
Ich habe es damit versucht, und bin damit leider nicht warmgeworden. Bei
mir lag das nicht an den µC (die sind wirklich solide), sondern am
Aufbau von CubeMX und der Peripheral Lib, und der freien Version von
IAR.
Schlussendlich bin ich bei PIC24 + MPLABX gelandet, mit denen ich sehr
zufrieden bin. Mir gefällt, wie die Header (vordefinierte Strukturen)
und die Datenblätter schön zusammenpassen. Mehr als eine persönliche
Vorliebe ist das aber nicht.
Daher:
Probiers aus.
Meiner Meinung nach sind die technischen Daten der µC fast irrelevant,
kannst eh fast mit allem alles lösen. Das ist Hobby, das muss Spass
machen. Was bringt dir der beste µC, wenn das Arbeiten damit keinen
Spass bringt.
> Für mich sind mittlere Anwendungen z.B. Lichtschalter mit Webserver.
Wie geistesgestört sind wir eigentlich schon. ein Lichtschalter mit
einen Webserver der dann anzeigt die GPS Positionsdaten, wann
eingeschaltet wurde, wann spätestens ausgeschaltet wird, wie viel Watt
verheizt wurden ?
Bei jeder Lampe einen Webserver, was willste da noch sagen.
Balkenbeigen schrieb:> Bei jeder Lampe einen Webserver, was willste da noch sagen.
Es fehlt ein Fingerabdruckscanner, um die Kosten verursachergerecht zu
verteilen ;-)
Also ich habe die letzten 5-6 Jahre auf den LPC1xxx von NXP gebastelt.
Zuerst die LPC11xx, dann die LPC15xx. M0 zu M3 und letzterer mit der
Pin-Switch-Matrix eine feine Sache. Mit LPCXpresso als Hardware mit
inkludiertem Programmer und Debugger und Eclipse-basierter IDE schon
fein. Die LPCOpen-Libs sind auch gar nicht so schlecht. Mir gefiel
damals das durchdachtere Design besser (machte irgendwie einen echten 32
Bit-Ansatz neu entwickelter Chips und kein aufgebohrtes 16 Bit Design
bei den ersten STM32).
Aktuell arbeite ich mich gerade in die steinalten STM32F103C8T6 ein.
Warum? Der Chinamann steckt sie mir für 1,85 € in den Briefkasten. Und
sie passen so schön in 9 V Batteriefächer meiner neuen Rauchmelder rein.
Einfach nur noch einen anderen LDO rauf und das ganze ist fertig. Keine
Platine zusätzlich. Für das Geld bekomme ich nicht mal die nackten
Chips; und LPC1xxx sind auch nicht ganz so gängig.
Den guten alten J-Link EDU wieder entstaubt und Eclipse eingerichtet.
Ist Arbeit; klar. Mit GNU ARM Eclipse plugin, J-Link plugin usw. Aber
jetzt weiß ich wieder ein bischen mehr und könnte vermutlich beim
nächsten Familienwechsel irgendwas nehmen: Die Basis bleibt!
Was ich eigentlich sagen will: Man sucht sich das aus, was man gerade
braucht und gut verfügbar ist (sowohl Hard- und Software als auch
"Support" in Foren wie diesem. In die einzelnen Chips muß man sich
sowieso reinarbeiten.
Ich werfe mal den ESP8266 in den Ring. Günstig und mit LUA Firmware hat
man auch schnelle Erfolgserlebnisse.
Finde ich genau richtig, wenn man etwas mit Internet-Anbindung machen
will.
Jawohl! Endlich wieder weltfremde Vergleiche zwischen 8bittern und
32bittern.
Wenn dus einfach haben magst, nimm AVRs. Die hast du mit deinem
Kenntnisstand in zwei Tagen komplett durchschaut und du wirst keine
Überraschungen erleben.
Wenn du mehr Leistung brauchst, nimm STM. Stell dich dann aber auch
darauf ein, manche Dinge garnicht mehr nachzuvollziehen und z.B.
fertigen Startup oder (mitunter nicht unbedingt intuitive) Bibliotheken
für die Peripherie zu benutzen.
Es ist etwas umständlicher, einen STM auf die Beine zu stellen, wenn man
nicht auf fertigen Boilerplate zurückgreifen möchte - der hat nunmal
mehrere Taktsysteme und so weiter, die initialisiert werden wollen.
Wenn du leiden magst, dann nimm einen kleinen PIC, am besten mit
Memory-Banking und beknackster 12bit Befehlsbreite, Hardware-Stack und
mindestens fünf Seiten Silicon Erratum.
Pete K. schrieb:> Ich werfe mal den ESP8266 in den Ring. Günstig und mit LUA Firmware hat> man auch schnelle Erfolgserlebnisse.> Finde ich genau richtig, wenn man etwas mit Internet-Anbindung machen> will.
Nur leider ohne Debugmöglichkeit. Debuggen ist schon was Feines.
Chris schrieb:> Bei Bedarf umfangreiche Peripherieoptionen zu aber ingesamt günstigen> Preisen, falls ich dochmal was in Stückzahl basteln will (z.B.> CAN/Hausbus) wäre mir noch ein Anliegen.> Bekanntsheitgrad und somit Forensupport sowie eine kostenlose, gute IDE> sind natürlich auch von Bedeutung ...>> Alles in Allem komme ich meiner Einschätzung nach da bei STM32 raus.> Würdet ihr mir bestätigen, dass das die richtige Wahl ist?>> Gibt es auch eine aktuelle Empfehlung für ein bestimmtes DEV-Board für> die ersten Schritten, vielleicht auch mit Taster & Leds/Display,> vielleicht CAN Transceiver und natürlich alle Anschlüsse nach aussen> geführt.
Angesichts der absurd niedrigen Preise kann man mit STM32 nicht wirklich
viel falsch machen. Ein "Blue-Pill"-Board (STM32F103C8T6) nebst ST-Link
V2 Clone gibt's beim Chinamann für insgesamt unter 5€. Das lässt sich
auch mit mbed nutzen (als Nucleo F103RB). Die Nucleos selbst sind aber
auch nicht teuer (ca. 10€) und gerade für den Einstieg etwas
komfortabler. Mit mbed bist du in der ARM-Welt erstmal nicht schlecht
aufgehoben und kannst relativ einfach den Controller wechseln, falls du
etwa meinst etwas mit Bluetooth machen zu wollen gibt es z.B. die NRF51
oder NRF52. Direkter Registerzugriff ist über CMSIS-Header problemlos
möglich falls man z.B. Peripherie nutzen will, die von mbed nicht (oder
nicht in vollem Umfang) unterstützt wird, wie etwa Timer. Für sehr viele
Sachen ist jedoch eine Unterstützung vorhanden. So gibt es
beispielsweise (rudimentäre) Unterstützung für digitale IO, ADC und DAC,
sowie einen BLE-, TCP/IP- und auch CAN-Stack quasi für lau.
