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
hi das schreit doch nach Atmega und da dann ev. nach Arduino? Rainer
Was du dir leisten, bzw. ausgeben willst, hast du vergessen. Ansonsten brauchst du keine Hilfe, wie mir scheint.
Hallo, bis um die 100,-€ exclusiv Erweiterungen wie Breadbord etc. wäre OK. Danke Chris
X-Nucleo würde ich dir empfehlen. Zb. so etwas: (XNUCLEO-F411RE Development Board STM32 Nucleo Sensors) http://www.ebay.com/itm/XNUCLEO-F411RE-Development-Board-STM32-Nucleo-Sensors-For-Arduino-/172379724175 Dazu gibt es zig schöne Erweiterungen. Es gehen auch alle 3,3V Arduino Shields.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
> 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.
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.