Liebe Foristen! Nachdem ich mich jetz durch eine erhebliche Anzahl an Threads gelesen habe um vielleicht doch keinen neuen "Welchen µC soll ich nehmen" Thread aufzumachen, muss ich mich gleich entschuldigen, da ich es jetzt dann doch gemacht habe. Ich hab mich vor ca 10 Jahren in meiner Ausbildungszeit mit µCs Typ PIC beschäftigen dürfen, hab dann lange nix gemacht und hab voriges jahr wieder mit der Elektronikbastelei angefangen. Zuerst "dumme" Schaltungen aus Hünerfutter mit NE555ern, Komparatoren, OPVs usw. Anschließend hab ich mir aus Fernost Arduinos (UNO und NANO) besorgt und damit ein paar kleinere Projekte gemacht (Steuerungen fürs Gewächshaus, Zimmerbeleuchungen, etc.) Jetzt möchte ich "die nächste Stufe erklimmen" und weg von den vorgefertigten Controllerschaltungen, hin zu kompletten Eigenbauten. Dabei stehe ich jetzt vor folgendem Problem. Auf welche Controllerfamilie soll ich mich hardwaremäßig ausrichten? Ich will mir ein Programmier und Debug Gerät kaufen, nicht sonderlich teuer sollte es sein, aber auf absehbare Zeit 5J+ alle µCs programmieren können. Ich habe mich jetzt auf AVR vs ARM eingeschossen. Gibt es Gründe (abseits von Glaubensfragen) um einem der beiden den Vorzug zu geben? Gibt es günstige P&D Geräte die beide können? So dass man für simpelste Geschichten die AVRs nimmt und für die anspruchsvolleren ARMs? Is das vertane Zeit? lieber alles auf ARM aufbauen? Ein guter Freund arbeitet bei Infineon und rät mir zu ARM, primär wegen der XMC Serie. Ich hab mich mal kurz und oberflächlich mit DAVE beschäftigt, aber leider kein Verständnis dafür entwickeln können. Prinzipiell würde mich die 32Bit Geschichte schon interessieren, ich befürchte nur dass ich sozusagen falsch oder schlecht angefangen habe und deswegen (damals auch aus Zeitgründen) sofort wieder aufgehört hab. Wie seht ihr das?
:
PIC ist hier ja nicht so verbreitet, aber wenn du schon Erfahrung damit hast warum nicht dabei bleiben? Die gibt es auch von Simpel bis hoch Komplex.
Markus B. schrieb: > Prinzipiell würde mich die 32Bit Geschichte schon interessieren, ich > befürchte nur dass ich sozusagen falsch oder schlecht angefangen habe > und deswegen (damals auch aus Zeitgründen) sofort wieder aufgehört hab. Dann kannst du ja PIC32 nehmen, wenn du PICs schon kennst. Das sind dann 32Bitter. MIPS. Hat zwar mit den 8-Bit-PICs nicht viel zu tun, aber wird dir viel Vertraut vorkommen. Weil Datenblätter, Programmierumgebung und Tools gleich aufgebaut sind. Probiers mit einem PIC32MX250, den gibts im DIL. Aber man muss schon sagen, ohne Grund tut man sich 32Bit nicht an. Du kannst dir mal PIC24 ansehen, das ist ein guter Kompromiss - einfach zu beherrschen, aber doch sehr viel Leistungsfähiger als 8-Bitter. Da wäre ein PIC24FV32KA301 ein Beispiel. Den gibts auch im DIL, und der ist schön einfach, kann aber trotzdem viel. Sonst kannst du dir halt die üblichen Verdächtigen ARMs ansehen, wie SAM3 (Atmel) oder LPCx oder Kinetis (NXP). Die STM32 bekommst du die nächsten Stunden eh von unseren STM32Hurra-Trollen bis zum Erbrechen aufgedrängt.
AVR (Attiny und ATmega, jedoch nicht Xmega) finde ich zum Basteln sehr attraktiv, allerdings wäre das im Vergleich zu deinen PIC kein großartiger Fortschritt. Zudem sind die Debugger für AVR recht teuer. Sehr günstig und leicht kommt man als Hobbyelektroniker an zahlreiche Boards mit STM32 Mikrocontrollern heran. Die sind zwar (nach dem was man hier lesen kann) nicht die besten Mikrocontroller, aber sie sind toll, das kann ich Dir auf eigener Erfahrung bestätigen. Vor allem haben einige STM32 Modelle sehr geringe Einstiegshürden. Man kann mit kostenloser Software (auch Arduino) arbeiten und bekommt ein Einstiegsboard + Programmieradapter bereits für 4€. Wobei der Programmieradapter wie von Dir gewünscht langlebig für alle STM32 Mikrocontroller verwendbar ist. Dazu empfehle ich Dir diese Webseite: http://stefanfrings.de/stm32/index.html Falls Dir STM32 nicht zusagen, werden hier häufig die ebenfalls auf ARM basierten SAM3 Controller von Microchip empfohlen. An die kommt man als Hobbybastler allerdings nicht so gut heran. Außerhalb der ARM Welt tut sich im 32bit Markt zur Zeit nicht sehr viel - vor allem nicht für Hobbybastler.
Markus B. schrieb: > Ich habe mich jetzt auf AVR vs ARM eingeschossen. Gibt es Gründe > (abseits von Glaubensfragen) um einem der beiden den Vorzug zu geben? Die anvisierten Anwendungen. Wenn der AVR reicht, ist der ARM nett, aber bisweilen Overkill und mehr (unnötige) Komplexität. > Gibt es günstige P&D Geräte die beide können? Nein. > So dass man für simpelste > Geschichten die AVRs nimmt und für die anspruchsvolleren ARMs? Is das > vertane Zeit? Geht, ist aber um einiges mehr an Lernaufwand, 2 Controllerfamilien zu beherrschen. Ich würde dir lieber zu einer Controllerfamilie raten. Sowohl AVR als auch ARM haben genug Bandbreite vom kleinsten bis zum größten Controller, um viele Anwendungen abzudecken. >lieber alles auf ARM aufbauen? Kann man machen. Hat halt mehr Reserven nach oben. > Prinzipiell würde mich die 32Bit Geschichte schon interessieren, Dann leg los! Ob nun STM32 oder was Anderes, nimm was dir gefällt und womit du gut klar kommst.
jemand schrieb: > Aber man muss schon sagen, ohne Grund tut man sich 32Bit nicht an. Ach, und wie begründest Du diese unsinnige Aussage? > Du kannst dir mal PIC24 ansehen, das ist ein guter Kompromiss - einfach > zu beherrschen, aber doch sehr viel Leistungsfähiger als 8-Bitter. Und diese? > Sonst kannst du dir halt die üblichen Verdächtigen ARMs ansehen, wie > SAM3 (Atmel) oder LPCx oder Kinetis (NXP). > Die STM32 bekommst du die nächsten Stunden eh von unseren > STM32Hurra-Trollen bis zum Erbrechen aufgedrängt. Nur PICHurra-Trolle schreiben so etwas. Für die STM32 spricht ja in der Tat einiges. Zum einen die mit grossem Abstand am weitesten verbreitete 32Bit-Architektur, die vielen kostenlosen und hervorragenden Tools, sowie das viele KnowHow hier im Forum, welches bei Problemen weiterhilft. Insbesondere letzteres sollte ein Umsteiger nicht unterschätzen. Bei STM32-Themen wird hier sofort geholfen. Das sieht schon bei SAM3 oder Kinetis anders aus, von PIC ganz zu schweigen.
Wenn Dir drei Leute vier verschiedene Mikrocontrollerfamilien nennen so
ist das normal bzw. alle haben recht.
Heutzutage wählt man die Teile nicht nach Geschmack oder Farbe aus,
sondern nach dem zu erwartendem Einsatzszenario.
Da in den meisten Fällen in C programmiert wird, ist der
darunterliegende Befehlssatz meist nur noch zweitrangig.
Für den "echten" Privatmann gilt:
In den meisten Fällen gibt es Compiler für lau - dank an gcc.
Eine regelrechte Programmierumgebung wird durch bootstap loader Konzepte
auch nicht unbedingt benötigt.
Einzig ein echter Debugger könnte ein Fragezeichen werden.
Sonst gilt: Wie viel Dampf brauchst Du? (MHz und Registerbreite)
Wie viele Anschlüsse brauchst Du (Fassung nicht verlieren)
Wie sieht die Versorgung aus (Spannung auch für die
Peripherie, eventuell Batteriebetrieb)
Hier können noch beliebig viele Kriterien aufgeführt
werden...
Wenn man mal etwas genauer hinsieht, sind sich die "kleinen"
Mikrocontroller erstaunlich ähnlich.
Ein Einheitskern, variable Anzahl an eingebauten Peripheriebausteinen,
ein paar Goodies und Timer und I/O-Pins nach Wahl.
:
Bearbeitet durch User
Es kann sein dass Stromsparmechanismen die Leistung so vermindern dass man ohne solche arbeiten muss. Dann eignen sich MSP430, die dann immer noch nur 1mA bei voller Leistung verbrauchen.
Doctor Snuggles schrieb: >> Aber man muss schon sagen, ohne Grund tut man sich 32Bit nicht an. > Ach, und wie begründest Du diese unsinnige Aussage? Du hast mich zwar nicht gefragt, aber ich möchte dazu trotzdem gerne antworten, weil ich der gleichen Meinung bin. Der Knackpunkt ist nicht die 32bit Eigenschaft an sich, sondern der erheblich größere Funktionsumfang, den die üblichen 32bit Controller mit sich bringen. Man muss einfach sehr viel mehr Lesen, verstehen und konfigurieren, um deren Schnittstellen zu nutzen. Jedes noch so kleine Programm ist auf diesen Controller erheblich umfangreicher, als auf den üblichen 8bit Modellen. Zwischen 8bit und 32bit sehe ich die AVR Xmega Reihe. Die haben nämlich beinahe ebenso komplexe Peripherie - allerdings mit dem altbekannten 8bit Kern kombiniert. Allerdings sehe ich auch ein, dass die zeit der 8bit Controller sich dem Ende zuneigt. Zudem möchte man immer komplexere Sachen bauen - mit einem simplen Blinklicht kann man heute nämlich niemanden mehr begeistern. Insofern kommt man am Thema 32bit langfristig kaum herum.
Danke schon mal für die schnellen Antworten! Ich habe mir jetzt ein Tut auf YT angesehen, dabei gehts um erste Schritte mit STM32-µCs. Verwendet wird EmBlitz usw. Ich denke, ich werd mich mal in die STM32 Familie einlesen, die µCs gibts bei Farnell um 1-3€ und offenbar sind die Programmer äusserst günstig. Da ich schon im vorhin genannten Tut gesehen habe dass die 32bit Geschichte einen relativ langen Anlauf braucht bis der Controller arbeitet, werd ich mir trotzdem auch einen AVR P&D holen. Man muss nicht unbedingt mit Kanonen auf Spatzen schießen. Gibt es definitive Kaufempfehlungen für beide P&D Geräte? Habt ihr vielleicht auch Softwarevorschläge, die das µC-programmieren nicht unnötig verkomplizieren, Grundschaltungen, etc? Links reichen völlig, einlesen muss ich mich so oder so.
Doctor Snuggles schrieb: > sowie das viele KnowHow hier im > Forum, welches bei Problemen weiterhilft. > Insbesondere letzteres sollte ein Umsteiger nicht unterschätzen. Du widersprichst dir selbst: Doctor Snuggles schrieb: > jemand schrieb: >> Aber man muss schon sagen, ohne Grund tut man sich 32Bit nicht an. > > Ach, und wie begründest Du diese unsinnige Aussage? Genau deshalb. Weil das Errata PDF eines 32 Bitters halb so dick sein kann wie das gesamte Datenblatt eines 8-Bitters. Also tut man sich einen 32 Bitter nicht an, wenn man nur eine kleine einfache Steuerung braucht.
Der ARM ist dann angesagt, wenn Du Rechenleistung verpulvern mußt, bis der Arzt kommt, also GLCD/GUI, Ethernet, USB-Host, SD-Card usw. Für Ablaufsteuerungen mit Text- oder 7S-Anzeige, PID-Regelungen usw. reicht der AVR dicke.
Für STM32 ist das leicht: Nucleo Board enthält alles Nötige, SW4STM32 ist die kostenlose Programmierumgebung und STM32CubeMX macht das Leben einfacher.
Markus B. schrieb: > Da ich schon im vorhin genannten Tut gesehen habe dass die 32bit > Geschichte einen relativ langen Anlauf braucht bis der Controller > arbeitet, werd ich mir trotzdem auch einen AVR P&D holen. Man muss nicht > unbedingt mit Kanonen auf Spatzen schießen. Sehe ich auch so. Ist ja Hobby, da kann man ja durchaus zweigleisig fahren. Man braucht aber für die einfachen 8 Bitter nicht unbedingt Debugger. Oft reicht auch eine Simulation oder man behilft sich mit ein paar Port pins an denen man Statusmeldungen im binärcode ausgibt, oder eine serialle Schnittstelle zum tracen.
Markus B. schrieb: > Gibt es definitive Kaufempfehlungen für beide P&D Geräte? Bei AVR hast du keine Wahl, es gibt nur einen: Den ATmel ICE. Den gibt es in drei Varianten: - Nur Platine - Platine mit Gehäuse - Platine mit Gehäuse und Kabelsatz Hobbyelektroniker kaufen aus Kostengründen oft nur die Platine und besorgen sich den Kabelsatz bei Aliexpress. Selber machen geht schlecht, weil die Stiftleisten spezielle Maße haben. Alternativ gibt es den alten Atmel Dragon, der unterstützt aber nicht alle aktuellen Modelle und debuggen kann er nur maximal 32kB soweit ich mich erinnere. Außerdem ist er empfindlich. Ich habe noch einen in der Bastelkiste, den verwende ich nicht mehr. Bei STM32 kann ich Dir ein beliebiges Nucleo-64 Board empfehlen, daran hängt ein ST-Link Adapter, den man auch für "Nackte" Chips verwenden kann oder für den Einbau in ein Gehäuse von dem Board abtrennen kann. Man kann den ST-Link für mehr Geld auch einzeln kaufen. Diese Geräte unterstützen dann zusätzlich auch JTAG Schnittstellen, welche für mich allerdings vollkommen uninteressant sind.
Markus B. schrieb: > Auf welche > Controllerfamilie soll ich mich hardwaremäßig ausrichten? Kommt auf die Schaltung an. Wenige Schaltausgänge, keine Sonderfunktionen -> PIC12Fxxx sollte genügen. Mehr Schaltausgänge, Hardware-PWM usw. -> PIC16xxx oder PIC18xxx wenn man keinen speziellen Anwendungszweck hat, finde ich 32bit imho etwas überdimensiert. Für übliche Sachen und darüber hinaus sollten die 12/16/18er mehr als genügen. Beim Einstieg muss man noch Datenblätter lesen, nach einer Weile hat man die Daten auswendig im Kopf und greift intuitiv zu. Auf der Microchip Website kann man irgendwo eine Excel Datei herunterladen, da stehen auf einen Blick alle PICs drin und welche Features sie haben. Markus B. schrieb: >Ich will mir > ein Programmier und Debug Gerät kaufen, nicht sonderlich teuer sollte es > sein, aber auf absehbare Zeit 5J+ alle µCs programmieren können. Programmerempfehlung gibt´s gratis - ist gut und günstig http://afug-info.de/Testberichte/MiniPro-TL866/ wenn du low voltage Programmierung brauchst, den TL866II ins Auge fassen. 73 de Norbert
Ich muss was loswerden: Bis jetzt verläuft die Diskussion erstaunlich vernünftig - geradezu losgelöst von jeder Art von Fanatismus. Das war in der Vergangenheit anders. Dafür gibt's von mir einen Daumen hoch.
Ja, läuft gut zur Zeit. Vor einiger Zeit gab es einen Beitrag wo jemand vergessen hatte den I2C Pin auf OD zu schalten und meine Antwort war: "Mit CubeMX wäre das nicht passiert" hätte ich auch erwartet, das erst ich und dann CubeMX zerlegt wird. Blieb aber beides aus.
Markus B. schrieb: > Ich will mir > ein Programmier und Debug Gerät kaufen, nicht sonderlich teuer sollte es > sein, aber auf absehbare Zeit 5J+ alle µCs programmieren können. Bei den Nucleo Boards von STM ist der Debugger&Programmer mit drauf und kann auch für eigene Boards verwendet werden. Das Teil kann auf JLINK umprogrammiert werden (klappt nicht mit stm32x7 Teilen, soweit ich weiß). Damit kann man schnell und einfach loslegen für <10€. Sowas ähnliches gibt es wohl auch von Infineon, aber nicht ganz soviele verschiedene Typen.
Nach AVR bin ich auf STM32 gewechselt, wuerde ich im Nachhinein nicht mehr machen, sondern eine andere ARM-Familie waehlen. Die Peripheriekonfiguration ist teilweise echt verzwackt. Falsche Reihenfolge und es funktioniert garnichts. Drei Tage in den Sand gesetzt, bis das I2C-Interface endlich gelaufen ist. Bin halt tatsaechlich nur Bastler. Gleiches Spiel beim ADC. Solange das Stamdardbeispiel reicht ist alles gut. Zwei ADC gleichzeitig auslesen, da gabs schon Probleme... Ewiges gefummel bis es geklappt hat. Ich denke die Verbreitung unter Bastlern haben sie nur weil sie so billig sind. Ob man aber bei Stueckzahl eins 2EUR oder 4EUR fuer so einen Controller hinlegt ist eigentlich wurst.
> werd ich mir trotzdem auch einen AVR P&D holen
Beim Atmel ICE hast du eigentlich die Gewissheit, dass dieser ohne
Murren unter AtmelStudio läuft. Kostet halt als nackte Platine ungefähr
60€.
Alternativ habe ich schon mit dem Snap XTinys/ATmega328 debuggt. 10€ als
öfters mal offeriertes Angebot sind auch nicht so weit weg von 0.
Dann an dieser Stelle mal Dank an Taylor Killian und lujji. Alle lieben
deren Ergüsse.
An den Topicstarter: Wenn du dir schon ein STM32-Board holst, dann kannst du für den 8-Bit-Bereich auch Boards mit STM8 drauf anschauen. Diese MC-Familie ist zwar den Atmegas leicht in der puren Rechenleistung unterlegen, hat aber einen niedrigeren Preis, bessere (für mich auch bequemere) Peripherie mit schönen Sachen wie NVIC und ist auch günstiger (und deswegen beliebt bei Chinesen). Ein Minuspunkt ist die aufwendig zu erstellende Toolchain, aber beim Konfigurieren lernt man viel gründlicher, was genau zwischen dem Text auf dem Bildschirm und dem Flash-Speicher des MC passiert. Und programmieren lassen die sich über den auf dem Nucleo-Board befindlichen ST-Link. Falls das interessant klingt, hier ist was zum Nachlesen: https://jaycarlson.net/microcontrollers/ - Vergleich verschiedener MC-Familien https://blog.mark-stevens.co.uk/category/stm8/ - sehr informationsreicher Blog über STM8 und STM32 MfG, Coldlogic
Viktor B. schrieb: > Wenn du dir schon ein STM32-Board holst, dann kannst du für den > 8-Bit-Bereich auch Boards mit STM8 drauf anschauen. Nachteil: Kennt hier keiner, viel Support durchs hiesige Forum ist nicht zu erwarten. Wahrscheinlich muss man zudem Distris bemühen, um an die Chips ran zu kommen.
:
Bearbeitet durch User
Markus B. schrieb: > Ich habe mich jetzt auf AVR vs ARM eingeschossen. Gefühlt ist AVR im Hobbybereich (ohne Wertung) verbreiteter und ARM verbreiteter in der Industrie. Die Wahl des Kerns ist: a) Eine Wahl des Instruktionssatzes. Typische Fragen sind: - Benötige ich Hardware Floating Point (mit FPU) - Benötige ich spezielle Instruktionen * Hardware Divide * Multiply and Akkumulate * SIMD - Welche "Codedichte" erreiche ich. 16 kB Flash sind nicht immer gleich 16 kB Flash. Was damit möglich ist hängt davon ab, wie effektiv der Instruktionssatz ist. Etwas salopp: Wieviel Problemlösung erreiche ich je Byte. b) Eine Wahl der Leistungsklasse, v.a. in Bezug auf Geschwindigkeit. - Sind rechenintensive zyklische Berechnungen notwendig? Nach der Klärung dieser Punkte ist das Auswahlkriterium meist die Peripherie (Was wird benötigt und in welcher Anzahl?) sowie der Preis (wieviel kann/will ich ausgeben?). Persönlich würde ich zu ARM tendieren, ehrlicherweise, da ich damit die meiste Erfahrung habe sowie der Software (Compiler) und Hardware-Verfügbarkeit (Debugger) mein Gefallen findet. Etwas objektiver ist die Skalierbarkeit: Allein Cortex-M0 bis Cortex-M4 deckt eine große Spanne Anwendungen ab. Cortex-M4F ist DSP Klasse, Cortex-M0+ absolute Low Level, Low Power Klasse. Andere Cortex Familien existieren für High Level Anwendungen (z. B. Smartphone-Prozessor).
Mach schrieb: > Nach AVR bin ich auf STM32 gewechselt, Bin ich auch. > wuerde ich im Nachhinein nicht > mehr machen, sondern eine andere ARM-Familie waehlen. Die > Peripheriekonfiguration ist teilweise echt verzwackt. Das sehe ich ganz anders. Hatte vorher hier im Forum auch dauernd gelesen, wie kompliziert doch die Taktkonfiguration sein sollte. Dann Reference Manual gelesen und nicht mal 15 Zeilen Code geschrieben. Lief auf Anhieb. SPI: Das Gleiche. Keine 10 Zeilen Code für Init. Super simpel. Interrupt dazu: 5 Zeilen Code mehr. DMA: Ebenfalls kein Problem. Das gilt auch für die restliche Peripherie. Richtig ist, dass die Peripherie zum Teil sehr komplexe Konfigurationen ermöglicht. Wenn man aber nur die größere Rechenleistung nutzen möchte, die Peripherie aber nur auf "AVR-Niveau", dann ist das so gut wie gar nicht komplexer als beim AVR. Der einzige signifikante Unterschied ist, dass man im Gegensatz zum AVR ein paar Hundert Seiten zuvor lesen (und natürlich auch verstehen) muss. Das schöne ist, dass man, wenn man es mal braucht, dann die umfangreichen Möglichkeiten hat. Was meiner Meinung nach fatal ist: Viele Umsteiger denken, wenn sie mit ein bisschen Klicki-Bunti-Gefrickel ala CubeMX irgendwas - ohne zu verstehen, was das genau bedeutet - zurecht klicken, dann kommt schon was Funktionierendes bei rum. Geht dann halt oft schief. Ich empfehle daher jedem, erstmal das Data Sheet und zumindest die grundlegenden Kapitel des Reference Manual (Memory and Buscontroller, Reset and Clock Control, GPIO) gründlich durchzulesen. Wenn man vom Cortex zuvor noch nichts gehört hat, dann ein Grundlagenbuch dazu, z.B. The Definitive Guide to ARM® Cortex®-M3 and Cortex®-M4. Dann gibt es zum Einstieg auch keine größeren Schwierigkeiten. > Ich denke die Verbreitung unter Bastlern haben sie nur weil sie so > billig sind. Nö, weil sie so ein gutes Preis-Leistungsverhältnis haben.
>> Ich denke die Verbreitung unter Bastlern haben sie nur weil sie so >> billig sind. John Doe schrieb: > Nö, weil sie so ein gutes Preis-Leistungsverhältnis haben. Ist das in diesem Fall nicht das selbe? Jedenfalls habe ich Hemmungen, mir ein 100€ teures Evaluation Kit zu kaufen um damit womöglich festzustellen, dass ich den falschen Chip gewählt habe. Da hole ich mir lieber ein Nucleo mit den gut abgehangenen STM32F103 für 16€, von dem mir im Zweifelsfall wenigstens der daran hängende Programmieradapter als langfristig brauchbares Werkzeug übrig bleibt. Außerdem versorgen uns inzwischen nicht nur die Chinesen sondern auch die üblichen Einzelhändler (Conrad, Reichelt) mit diesen Chips und Boards in unterschiedlichen Größen. Wenn mir irgend jemand erzählt, dass mein heiß geliebter ATtiny13 alt und teuer sei, dann kann ich da auch gelassen drüber hinweg schauen. Denn mir bietet er die Möglichkeit, Schaltungen viel schneller und billiger zusammen zu Lochrastern, als vor 30 Jahren. Das macht mir Spaß, und das ist gut. Ich bin auch mit meinem Auto sehr zufrieden obwohl es in jeder Hinsicht nicht das Beste ist. Dennoch ist das Gesamtpaket für mich genau richtig - sonst würde ich das Auto nicht seit 14 Jahren pflegen. Privat hat man andere Maßstäbe, als in der Industrie oder in der Massenproduktion.
Sebastian S. schrieb: > Heutzutage wählt man die Teile nicht nach Geschmack oder Farbe aus, > sondern nach dem zu erwartendem Einsatzszenario. Naja, aber die Familie wählt man heute schon nach Geschmack aus, die Konkurrenten tun sich nämlich unterm Strich nicht viel. Das zeigt ja schon der Glaubenskrieg: PIC oder AVR. Den kann seit Jahren keiner eindeutig für sich entscheiden.
M. K. schrieb: > PIC oder AVR. Den kann seit Jahren keiner > eindeutig für sich entscheiden. Das ist wie Citroen Berlingo versus Peugeot Partner
Markus B. schrieb: > Gibt es definitive Kaufempfehlungen für beide P&D Geräte? Also für das eine solltest du einen Blick auf den MPLAB SNAP werfen. Der ist sehr günstig, kann AVR, ATSAM (ARM) und auch noch PIC. (allerdings keine älteren Typen) ATSAM werden zwar auf der MPLAB SNAP Seite nicht erwähnt, aber dafür im Device Support File von MPLAB X. Da kann man für jeden uC sehen welcher P/D unterstützt wird. Etwas teurer, aber meiner Meinung nach immer noch recht günstig ist das PICkit4.
:
Bearbeitet durch User
Beim Programmieradapter/Debugger MPLAB Snap empfehle ich, die Softwarekompatibilität vor dem Kauf zu klären.
Stefanus F. schrieb: > M. K. schrieb: >> PIC oder AVR. Den kann seit Jahren keiner >> eindeutig für sich entscheiden. > > Das ist wie Citroen Berlingo versus Peugeot Partner Ich habe mittlerweile ein paar Controllertypen durch. Mir fällt der Wechsel jedesmal schwer. Bei Projekten bei denen ich bei der Controller-Wahl mitreden kann, tendiere ich mittlerweile zu 8051ern bei kleineren Aufgaben und Arm-Controllern, wenn es 32bit und Speicher braucht. Von beidem gibt es viele Hersteller. Da ist dann bei Umstellung auf einen anderen Hersteller der Aufwand geringer.
Wenn du die PICs schon mal benutzt hast und evtl. sogar noch einen PICKit rumliegen hast, spricht nichts dagegen, die weiter zu nehmen, zumal sich in den letzten Jahren die Familie mit PIC12/PIC16 und PIC18 erheblich erweitert hat. Ich beschäftige mich sowohl mit AVR als auch mit PIC, ohne da einen Glaubenskrieg zu entfesseln. Die grosse Verlockung für STM32 waren mich die Discovery Boards, da man da ne Menge Hardware für wenig Mäuse bekommt und auch der Programmer gleich an Bord ist, was einem die Entwicklung erleichtert. Aber wer eine Lüftersteuerung baut oder ein paar LED blinken lässt, der braucht das nicht. Andererseits würde ich den Putzrobotor oder ein Handheld Oszi nicht auf Deibel komm raus mit einem 8-Bitter bauen.
:
Bearbeitet durch User
Stefanus F. schrieb: > Beim Programmieradapter/Debugger MPLAB Snap empfehle ich, die > Softwarekompatibilität vor dem Kauf zu klären. Auf jeden Fall! Aber das gilt ja bei allen ;-) Controller<->Programmer/Debugger und Compiler in der MPLABX IDE https://www.microchip.com/mymicrochip/filehandler.aspx?ddocname=en600333 <edit>Die unterstützten Controller werden bei jeder neuen IDE Version mehr.
:
Bearbeitet durch User
Beitrag #5773955 wurde von einem Moderator gelöscht.
Wenn du einen P/D für die STM32 suchst, und dir kein Nucleo zulegen willst, bzw. einen einzelnen P/D suchst, kann ich dir die ST Link v2 clone empfehlen, finden sich auf Aliexpress: https://www.aliexpress.com/wholesale?catId=0&initiative_id=SB_20190317014917&SearchText=st+link+v2 Suchst du einen schnelleren Debugger, dann empfehle ich dir den (einen) Segger jlink: https://www.segger.com/products/debug-probes/j-link/models/model-overview/ Diese haben eine kompatibilität mit allen ARM-Prozessoren, und noch einigen anderen, also ziemlich universell einsetzbar: https://www.segger.com/products/debug-probes/j-link/technology/cpus-and-devices/overview-of-supported-cpus-and-devices/
Moin, A propos Qual bei der Wahl: Kanns ernsthaft sein, dass ST keinen vernuenftigen Online Productselector fuer ihre STM32 anbietet? Ich find' so'n Quatsch hier: https://www.st.com/en/development-tools/st-mcu-finder.html Also irgendeine schwindelige Software, die ich mir runterladen und aufm Rechner (nachdem ich natuerlich auf eines der unterstuetzten Betriebssysteme gewechselt habe) installieren soll? Ich haett' gerne so 'ne Webpage vom Hersteller mit einer Tabelle mit allen droelfzehntausend STM32, die's aktuell gibt; aus der ich dann gezielt Einzelne raussuchen kann, indem ich z.b. nur Typen im 144 TQFP mit 3 UARTs, 2 DMA Controllern, 3..5 ADCs, in Eiche rustikal, mit >1200 U/min beim Schleudern etc. angezeigt bekomme. Bin ich da zu bloed, das zu finden? Oder ist ST zu unfaehig das anzubieten? Das war bei TI doch auch schon so ein kranker shice, dass ich eine Windows-Software brauch', um mir irgendwelche Kombinationen aus "GPIO/DedicatedFunction/IO-Voltage" fuer Sitatas und andere ARM/DSP/whatever Kombis "berechnen" zu lassen... Gruss WK
Dergute W. schrieb: > Kanns ernsthaft sein, dass ST keinen > vernuenftigen Online Productselector fuer ihre STM32 anbietet? Kann gut sein, ich habe jedenfalls noch keinen gesehen. Online läuft es bei denen anders: Dort sind die Familien in ihrer maximalen Ausbaustufe beschrieben. Dann kannst du eine Familie aussuchen und anklicken. Dann sind die Serien der Familie wieder mit ihrer maximalen Ausbaustufe beschrieben. Suche Dir eine Familie aus, dann erscheint eine übersichtliche Darstellung der Modelle innerhalb der Serie. Ich finde das auch nicht optimal.
Stefanus F. schrieb: > Das ist wie Citroen Berlingo versus Peugeot Partner Vergleiche mit Äpfel und Birnen haben den klaren Vorteil, dass jeder Äpfel und Birnen kennt. ;-)
> und kostenlosen Assembler
1 | SDCC : mcs51/z80/z180/r2k/r3ka/gbz80/tlcs90/ez80_z80/ds390/pic16/pic14/TININative/ds400/hc08/s08/stm8/pdk14/pdk15 3.8.7 #11088 (Linux) |
2 | published under GNU General Public License (GPL) |
3 ct ist geizgeil, aber OTP nicht jedermanns sache bei den Padauks.
A. K. schrieb: > Stefanus F. schrieb: >> Das ist wie Citroen Berlingo versus Peugeot Partner > > Vergleiche mit Äpfel und Birnen haben den klaren Vorteil, dass jeder > Äpfel und Birnen kennt. ;-) Naja, aber das ist ein Vergleich von Äpfeln des einen Baums mit Äpfeln des anderen Baums ;)
Stefanus F. schrieb: > Falls Dir STM32 nicht zusagen, werden hier häufig die ebenfalls auf ARM > basierten SAM3 Controller von Microchip empfohlen. An die kommt man als > Hobbybastler allerdings nicht so gut heran. sag Bescheid, welchen Du brauchst und ich seh mal zu, ob ich Dir welche beschaffen kann. Eigentlich komm ich da gut ran.
:
Bearbeitet durch User
> Stefanus F. schrieb: > Das ist wie Citroen Berlingo versus Peugeot Partner A. K. schrieb: > das ist ein Vergleich von Äpfeln des einen Baums mit Äpfeln > des anderen Baums ;) Und beide Bäume stehen im selben Garten. Günter M. schrieb: > sag Bescheid, welchen Du brauchst Danke für das Angebot. Bislang genügen mir die STM32F103.
Markus B. schrieb: > Ein guter Freund arbeitet > bei Infineon und rät mir zu ARM, primär wegen der XMC Serie. Tja, der gute Freund.... Diese XMC sind doch die Chips, wo ab 0 echtes ROM vorhanden ist und dieses nicht mal offengelegt ist - wo man also keine Chance hat, eine eigene Firmware draufzuprogrammieren, ohne selbige mit diesem DAVE entwerfen zu lassen. Nee, Freund hin oder her, von diesen Dingern würde ich dir dringendst abraten. Markus B. schrieb: > Ich habe mich jetzt auf AVR vs ARM eingeschossen. Peng..tot! Nee, so militant mag ich es nicht. Ansonsten sei dir geraten, zunächst mal bei den kleinen PIC's (16F.. usw.) zu bleiben. Die kennst du ja schon ein wenig und das hilft. W.S.
Markus B. schrieb: > So dass man für simpelste Geschichten die AVRs nimmt und für die > anspruchsvolleren ARMs? Is das vertane Zeit? lieber alles auf ARM > aufbauen? Der einzige Grund noch irgendwas auf AVR-Basis zu machen ist - meiner Meinung nach - entweder die Erfahrung die man mit den Dingern schon hat (inkl. eigener Codeschnipsel) oder der große Support, wie auch hier im Forum (inkl. fremder Codeschnipsel). Ansonsten gibt es Mikrocontroller mit ARM-Kern, wie z.B. STM32F030F4P6 für dermaßen kleines Geld (0,50€ für den nackten Chip, 1€ für ein bestücktes Board), dass man dafür nicht mal einen AVR oder PIC mit annähernd vergleichbarer Ausstattung von Flash und RAM bekommt. Ein solcher STM32F030F4P6 reicht schon für viele Aufgaben aus, obwohl es der kleinste und günstigste in der Familie ist (48 MHz, 16kB Flash und 4kB RAM). Der große Vorteil gegenüber AVR oder PIC ist, dass man nach oben hin innerhalb der Familie gewaltig viel Luft hat. 400MHz, 2MB Flash und 1MB RAM, kombiniert mit USB-Host, SDIO, CAN, parallelem LCD-Interface, externem SD-RAM, etc. Es gibt fast alles was das Herz begehrt. Ich hab selber vor ca. 10 Jahren mit den MSP430 angefangen und bin dann auf STM32 umgestiegen. Habe seitdem auch viel mit anderen ARM-Controllern gearbeitet, z.B. Kinetis, LPC oder EFM32. Alle haben ihre Vor- und Nachteile. Die LPCs haben meiner Meinung nach eine sauberere Peripherie als die STM32 und skalieren nach oben hin ähnlich gut, sind aber nicht so günstig für Privatanwender zu bekommen. Das gleiche gilt für Kinetis. EFM32 bestechen durch die Bluetooth-Schnittstelle und die frei konfigurierbaren Pinouts dank Bus-Matrix, skalieren aber nicht so gut nach oben. Wenn du einen STM32 in Betracht ziehen solltest, empfehle ich dir auf jeden Fall mit einem F0 anzufangen und den Controller samt Peripherie von der Pike auf zu verstehen. Für die F0-Serie gibt es von ST die sogenannten "STM32-Snippets". Das ist eine Code-Sammlung mit Beispielen, wo man alles über die Register konfiguriert. Der Code ist auch ordentlich kommentiert, so dass man sich mit dem entsprechenden Reference-Manual ordentlich zurecht finden sollte. CubeMX und HAL würde ich mir erst anschließend geben (wenn überhaupt). Es wird hier leider oft die Registerbreite des Controllers mit der Komplexität gleichgesetzt (8 Bit vs 32 Bit). Das halte ich ehrlich gesagt für ausgemachten Schwachsinn, da sich ein moderner C-Compiler ohnehin um alles kümmert, egal ob 8, 16 oder 32 Bit. Im Gegenteil sind 32 Bit Controller in der Peripherie oft einfacher zu handeln, weil man eben z.B. einen ADC-Wert auf einen Schlag auslesen kann und keine geteilten Register hat, die man in einer bestimmten Reihenfolge auslesen muss. Darüber hinaus wird schnell mal der Umfang des Datenblattes eines AVR mit dem eines STM32 verglichen. Das ist meiner Meinung nach aber nur die halbe Wahrheit und davon darf man sich nicht abschrecken lassen. Generell haben die ganzen Cortex-M Mikrocontroller deutlich mehr Peripherie als die AVR oder PIC aber nur weil sie diese Peripherie besitzen, muss man sie noch lange nicht nutzen. Ethernet, CAN oder USB sind natürlich erstmal komplexe Biester und dafür geht auch ordentlich Platz in der Doku drauf aber man ist nicht gezwungen sie zu benutzen. Es gibt ein paar Dinge die sind bei einem typischen Cortex-M wirklich ein bisschen komplizierter als bei einem AVR: 1. Die GPIO-Konfiguration, da muss man für jeden Pin einstellen was man denn möchte. Es reicht nicht, nur zu sagen Input oder Output, wenn man denn z.B. einen SPI-Bus konfigurieren möchte. 2. Die Taktkonfiguration, bzw. PLL-Konfiguration. Zum einen muss man für jedes Peripheriemodul einzeln den Takt einschalten, weil dies um Strom zu sparen per Default nicht der Fall ist (ist kein Aufwand aber ohne geht nix). Zum anderen hat im Prinzip jeder Cortex-M eine oder mehrere PLLs, die mehr oder weniger schwer zu konfigurieren sind. Theoretisch kann man diese PLL-Konfiguration auch weg lassen und den Controller mit dem internen RC-Oszillator laufen lassen. Ein STM32F0 mit 8MHz ist immer noch um ein vielfaches schneller als ein AVR mit 16MHz. Grundsätzlich ist diese PLL-Konfiguration aber auch kein Hexenwerk und ist in etwa mit den Fuses bei den AVR zu vergleichen. Bei einem typischen STM32F0 läuft nach erfolgreicher PLL-Konfiguration typischerweise der Core inkl. sämtlicher Peripherie mit 48MHz, was dann genauso einfach ist wie bei einem AVR oder PIC, nur eben schneller.
Christopher J. schrieb: > Der einzige Grund noch irgendwas auf AVR-Basis zu machen ist - meiner > Meinung nach - entweder die Erfahrung die man mit den Dingern schon hat > (inkl. eigener Codeschnipsel) oder der große Support, wie auch hier im > Forum (inkl. fremder Codeschnipsel). Ansonsten gibt es Mikrocontroller > mit ARM-Kern, wie z.B. STM32F030F4P6 für dermaßen kleines Geld (0,50€ > für den nackten Chip, 1€ für ein bestücktes Board), dass man dafür nicht > mal einen AVR oder PIC mit annähernd vergleichbarer Ausstattung von > Flash und RAM bekommt. Geld ist nicht alles. Auch die Größe kann entscheidend sein. So ein Attiny85 im SOIC-8 Gehäuse z.B. hat auch schon was...oder den Attiny10 im SOT-23 Gehäuse kann auch sexy sein ;)
Stefanus F. schrieb: > Danke für das Angebot. Bislang genügen mir die STM32F103. Warum, zum Teufel, nimmt man solche alten Gurken? Der STM32F103 ist der unrühmliche Anfang einer guten µC-Serie. Er ist 10 Jahre alt. Schau dir doch mal modernere F3 and (wie den F303ZE). Oder, falls dir der zu groß ist, den F072. Es gibt soviel schöne STM32, warum ausgerechnet die schlechtesten verwenden?
achje... schrieb: > Warum, zum Teufel, nimmt man solche alten Gurken? > Der STM32F103 ist der unrühmliche Anfang einer guten µC-Serie. Er ist 10 > Jahre alt. 1. 10 Jahre ist für einen uC nicht wirklich alt. 2. Weil man sie noch in der Schublade liegen hat. 3. Weil der Hersteller sie noch produziert/verkauft. Sind IMO 3 gute Gründe. Der Atmega328p wird ja auch noch regelmäßig verwendet und der ist ein/zwei Tage älter als so ein STM32F103 ;)
Christopher J. schrieb: > Die Taktkonfiguration, bzw. PLL-Konfiguration Wenn wir hier mal den STM32F103 oder 303 mit einem AVR Xmega vergleichen, sollte schnell auffallen, dass der AVR hier nicht wirklich einfacher ist. Die Xmega haben auch ihre Tücken bei der Taktkonfiguration: Wenn man bei einem Xmega die UART mit internem R/C Oszillator verwenden will, muss man diesen ungenauen Oszillator mit einem weiteren kalibrierten Oszillator synchronisieren. Da kommt man als Anfänger von alleine nicht so schnell drauf.
1 | // Set clock source to 32Mhz using the internal R/C Oscillator.
|
2 | OSC.CTRL|=OSC_RC32MEN_bm; |
3 | while (!(OSC.STATUS & OSC_RC32MRDY_bm)); |
4 | CCP=CCP_IOREG_gc; |
5 | CLK.CTRL=CLK_SCLKSEL_RC32M_gc; |
6 | |
7 | // Synchronize to the calibrated 32kHz oscillator (needed for the UART)
|
8 | OSC.CTRL&=(~OSC_RC2MEN_bm); |
9 | OSC.CTRL|= OSC_RC32KEN_bm; |
10 | while (!(OSC.STATUS & OSC_RC32KRDY_bm)); |
11 | OSC.DFLLCTRL &= ~OSC_RC32MCREF_bm; |
12 | DFLLRC32M.CTRL |= DFLL_ENABLE_bm; |
Ich habe gelesen, dass die neue ATtiny Modelle ein ähnlich komplexes Taktsystem haben. Irgendwie gleichen sich die 8 Bitter immer mehr an die 32 Bitter an - bis auf die Bits halt. Wenn das so weiter geht, sind sie bald schwieriger zu programmieren, als 32bit. Christopher hat ja schon ein schönes Beispiel (geteilte Register) genannt. > Ein STM32F0 mit 8MHz ist immer > noch um ein vielfaches schneller als ein AVR mit 16MHz. Das bezweifle ich allerdings. Er mag schneller rechnen können, aber das wär's dann auch schon.
achje... schrieb: > Warum, zum Teufel, nimmt man solche alten Gurken? Schon wieder. Hatten wir das nicht gerade erst? Falls du dich nicht erinnerst, suche mal gezielt danach. Es wurden viele Gründe genannt, welche die "alte" Serie noch attraktiv machen. Zu den oben genannten möchte ich ergänzen: 4. Mehr Doku und Beispiele online verfügbar, insbesondere was die Programmierung ohne Cube HAL angeht. 5. Mehr Boards verfügbar, die man als Endkunde kaufen kann. > Schau dir doch mal modernere F3 an Du meckerst, bevor du mich kennst. Schau mal auf meine Homepage und verfolge meine Fragen, dann siehst du, dass ich mich durchaus ersthaft mit der F3 Serie befasse. Ich habe zwei Boards auf dem Tisch liegen! http://stefanfrings.de/stm32/index.html
Beitrag #5775431 wurde von einem Moderator gelöscht.
Beitrag #5775882 wurde von einem Moderator gelöscht.
M. K. schrieb: > Geld ist nicht alles. Auch die Größe kann entscheidend sein. So ein > Attiny85 im SOIC-8 Gehäuse z.B. hat auch schon was...oder den Attiny10 > im SOT-23 Gehäuse kann auch sexy sein ;) Da hast du einen guten Punkt angesprochen. Ja, ich finde es durchaus Schade, dass ST diese "Nische" (stückzahlentechnisch ist es das wohl, leider) nicht bedient. Bei anderen Herstellern gibt es die kleinen Cortex-M0(+) noch zusätzlich in den lötkolbenfreundlichen SOIC-Gehäusen (Atmel, Infineon und NXP sollten das auf jeden Fall haben). Ich denke aber mit etwas Übung bekommt man LQFP32 oder TSSOP noch gut in den Griff und selbst die 0,5mm Pin-Pitch bei LQFP48 aufwärts sind gerade mit Heißluft und Lötpaste gut machbar. Dafür reicht einem Bastler auch durchaus eine China-Heißluftstation für 30€. Die Ergebnisse sind trotzdem top. Wenn man darauf keine Lust hat und keine extrem kompakte Bauform benötigt, dann kann man ja immer noch auf die Blue-Pill Boards oder eines der vielen Nucleo-32 zurückgreifen, die von der Bauform und vom Pinout wie ein Arduino-Nano sind. A propos Blue-Pill und Nucleo: An den Nucleo-Boards sieht man einen großen Vor- und auch gleichzeitig Nachteil der STM32. Der Nachteil ist, dass sie ein ziemlich wirres Pinout haben. Der große Vorteil ist, dass dieses wirre Pinout familienübergreifend standardisiert ist. So schafft es ST bei den Nucleo-Boards mit einer einzigen Platine verschiedenste Controller unterzubringen, nämlich alles von F0 bis L4 bei den Nucleo-32. Man kann z.B. auch den (definitiv etwas betagten) F103C8T6 von einem Blue-Pill auslöten und einen (deutlich moderneren und besseren) F303CBT6 oder F303CCT6 einlöten.
Stefanus F. schrieb: > Ich habe gelesen, dass die neue ATtiny Modelle ein ähnlich komplexes > Taktsystem haben. Sind die neuen Tinys nicht sogar unter der Haube XMegas? Also auch vom Instruction-Set? Stefanus F. schrieb: >> Ein STM32F0 mit 8MHz ist immer noch um ein vielfaches schneller als ein >> AVR mit 16MHz. > > Das bezweifle ich allerdings. Er mag schneller rechnen können, aber das > wär's dann auch schon. Naja, rechnen auf jeden Fall aber auch sonst sollte man in gleicher Zeit mehr damit bewerkstelligen können. Dafür sorgen alleine schon DMA und NVIC. Natürlich kann ein 16MHz AVR eine LED schneller blinken lassen als ein 8MHz Cortex-M aber das ist für gewöhnlich nicht die einzige Anwendung.
Beitrag #5776186 wurde von einem Moderator gelöscht.
Beitrag #5776204 wurde von einem Moderator gelöscht.
Beitrag #5776287 wurde von einem Moderator gelöscht.
Beitrag #5776564 wurde von einem Moderator gelöscht.
Ich schrieb: >> Wenn man bei >> einem Xmega die UART mit internem R/C Oszillator verwenden will, muss >> man diesen ungenauen Oszillator mit einem weiteren kalibrierten >> Oszillator synchronisieren. dirk schrieb im Beitrag #5776287: > Genauso falsch. Gerade XMegas arbeiten intern sehr gut > Takt-stabilisiert, ein UART lässt sich problemlos ohne > Quarzverwendungbetreiben. Dirk, hier besteht ein Missverständnis. Ich weiss (und wollte das auch eigentlich aussagen), dass die Xmega mit internem R/C Oszillator UART unterstützen. Allerdings ist der 2MHz Oszillator alleine manchmal nicht genau genug. Wenn man ihn aber mit dem anderen ab Werk präzise kalibrierten 32kHz Oszillator synchronisiert, dann läuft das gut. Diese Möglichkeit der Synchronisierung habe ich bei der STM32 Mainstream Familie noch nicht gesehen.
Beitrag #5776588 wurde von einem Moderator gelöscht.
John Doe schrieb: > Das sehe ich ganz anders. > Hatte vorher hier im Forum auch dauernd gelesen, wie kompliziert doch > die Taktkonfiguration sein sollte. > Dann Reference Manual gelesen und nicht mal 15 Zeilen Code geschrieben. > Lief auf Anhieb. Ähh, ja, der läuft auch auf Anhieb. Bist Du aber auch sicher, dass der mit Deiner Konfiguration gelaufen ist und nicht einfach weiter mit der internen Quelle? Das macht er nämlich, wenn Deine Konfiguration so nicht funktioniert. Außerdem: Welcher Typ? Es ist ein ziemlich großer Unterschied, ob man den F103 oder irgendeinen F4xx in Betrieb nimmt. Letztere sind bei weitem nicht so einfach zu konfigurieren wie irgendein ATmega. Da kommt es nicht nur auf das richtige Setting an, sondern auch auf die richtige Reihenfolge. Das steht so leider auch nicht klar im Manual, das muss man sich selber (logisch) denken. Und ohne CubeMX ist es auch ziemlich schwer, den Überblick bei den Taktquellen zu behalten. > SPI: Das Gleiche. Keine 10 Zeilen Code für Init. Super simpel. Interrupt > dazu: 5 Zeilen Code mehr. DMA: Ebenfalls kein Problem. > Das gilt auch für die restliche Peripherie. Ähh, ja, da hast Du Dir auch die einfachsten Interfaces gesucht. SPI hat zwei Kontrollregister, die nur zu einem Teil belegt sind. Da sind die meisten Bits mit ihrem Reset-Wert schon ganz gut vorbelegt... Fallstricke gibt es aber beim STM32 jede Menge: Als erstes die ganzen Peripherie-Clocks, die konfiguriert und angeschaltet werden müssen. Übelstes Beispiel bis jetzt: RTC über externe LSE-Clock. Bis man die Register alle setzen kann, muss man schon Detektiv spielen (dass man die RTC peripheral clock braucht, ist noch einigermaßen klar, dass man aber für das Setzen von RTC-Registern die PWR peripheral clock braucht, damit man die Backup Domain Write protection und auch den Backup Domain Regulator anschalten muss, um die LSE-Clock anzuschalten, um dann wiederum erstmal Clock source anschalten zu können...usw. - das steht so nicht im Manual drin (nur teilweise). Nun ja, und dann kommen auch noch die ziemlich umfangreichen Konfigurationsmöglichkeiten für die alternativen GPIO-Funktionen hinzu, die sich auch noch zwischen der F1xx und F4xx ziemlich deutlich unterscheiden. > > Richtig ist, dass die Peripherie zum Teil sehr komplexe Konfigurationen > ermöglicht. Wenn man aber nur die größere Rechenleistung nutzen möchte, > die Peripherie aber nur auf "AVR-Niveau", dann ist das so gut wie gar > nicht komplexer als beim AVR. Der einzige signifikante Unterschied ist, > dass man im Gegensatz zum AVR ein paar Hundert Seiten zuvor lesen (und > natürlich auch verstehen) muss. Das ist unlogisch. Wenn es nicht komplexer wäre, müsste man auch nicht viel mehr lesen und verstehen. Ich habe schon einige Projekte mit dem ATmega und nun ein großes mit STM32F103 und STMF4xx hinter mir. Keine HAL oder andere Libs verwendet. Schnittstellen: Mehrere SPI (RFM12, Displays), UART (Konsole, GSM-Modul), I2C, ADC, DCF77, parallele Display-Schnittstellen, RTC und FLASH-Schreiberei. Mein Fazit: ATmega deutlich einfacher zu programmieren, einen Debugger habe ich praktisch nie gebraucht. Idealer Controller für Anfänger und kleinere Projekte. Sehr einfach auch in sehr stromsparenden Konfigurationen zu betreiben. STM32 bietet eine viel bessere Entwicklungsumgebung (Debugger), die braucht man aber auch wirklich dauernd. Als zweite Stufe nach Erfahrungen mit einem ATmega sicher gut geeignet, für einen Einsteiger ist meiner Meinung nach Frust vorprogrammiert.
Gastino G. schrieb: > Ähh, ja, der läuft auch auf Anhieb. Bist Du aber auch sicher, dass der > mit Deiner Konfiguration gelaufen ist und nicht einfach weiter mit der > internen Quelle? Das macht er nämlich, wenn Deine Konfiguration so nicht > funktioniert. Den automatischen Fall-Back bieten nur bestimmte STM32 Modelle. Man kann es aber in Software implementieren, für den Fall dass der Quarz z.B. nicht anschwingt. > Und ohne CubeMX ist es auch ziemlich schwer, > den Überblick bei den Taktquellen zu behalten. Ich mag die HAL nicht, aber ich benutze CubeMx gerne, um die Taktkonfiguration durch zu spielen. Das Programm zeigt nämlich schön an, was geht, und was nicht. Wenn ich mit CubeMx fertig bin, übertrage ich die Einstellungen manuell auf die Register. Und ja du hast Recht: Die richtige Reihenfolge der Settings muss man sich dann schon selbst mit Logik und ein bisschen Trial&Errror ausknobeln. > RTC ... muss man schon Detektiv spielen Für die gibt es zum Glück eine Application Note.
Markus B. schrieb: > Gibt es günstige P&D Geräte die beide können? Wurde zwar schon beantwortet - Nein. Ich würde zu einem ARM raten. Hier wird zwar immer wieder davon gesprochen dass ARM der "Overkill" ist oder so viel drin hat. Das stimmt so auch nicht, denn es gibt durchaus kleinere µC Chips mit ARM Kern. Beispiel: STM32F0xx Der hat zwar einen 32 Bit Cortex-M0, ist dennoch mit relativ wenigen Pins ein kleiner Typ. Ich würde den eher als Ersatztyp für den AVR ansehen. Die großen wie z.B. STM32F4xx sind in der Tat deutlich mächtiger und haben zum Teil umfangreiche Peripherie drin. Wenn man sich nun das P&D für einen ARM anschafft, so hat man in jedem Fall ein Werkzeug in der Hand, das alle µC mit einem ARM Kern von allen Herstellern* unterstützt. (* der ST-Link hat wohl Begrenzungen drin für ST µC, hingegen ein Segger J-LINK EDU kann alle) So ziemlich jeder µC Hersteller hat heutztage welche mit ARM Kern im Sortiment. Sei es ST, NXP, Nuvoton, Renesas, Microchip, uvm. Damit ist man in jedem Fall Herstellerunabhängig und wenn man mit ARM µC Erfahrung hat ist dies auch immer gerne bei Bewerbungen gesehen.
Moin, Stefanus F. schrieb: > Ich finde das auch nicht optimal. Ja, so kann man's ausdruecken. Naja, anscheinend verkaufen sie auch ohne vernuenftige Suchmoeglichkeiten genug von ihrem Kram. Kammanixmachen. Gruss WK
Markus M. schrieb: > So ziemlich jeder µC Hersteller hat heutztage welche mit ARM Kern im > Sortiment. Sei es ST, NXP, Nuvoton, Renesas, Microchip, uvm. > Damit ist man in jedem Fall Herstellerunabhängig und wenn man mit ARM µC > Erfahrung hat ist dies auch immer gerne bei Bewerbungen gesehen. Als C-Programmierer sieht man von der CPU sowieso nicht wirklich viel. Ok, das Interruptsystem ist vielleicht "durchschimmernd", aber der Rest, sprich die Hardwaremodule sind herstellerabhängig. Damit ist man als "AMR-Programmierer" genau so gut wie ein C2000 oder MIPS-Programmierer, wenn man kein ASM macht.
Falk B. schrieb: > Damit ist man als > "AMR-Programmierer" genau so gut wie ein C2000 oder MIPS-Programmierer, > wenn man kein ASM macht. Es geht um die Kostenersparnis vom P&D Werkzeug, nicht nur um das C/C++ programmieren. Wenn man nur einmalig ein gutes P&D Werkzeug kaufen muss und damit viele Hersteller abdecken kann ist das eine einmalige WinWin Situation.
:
Bearbeitet durch User
etwas OT.. Wo sind die drängenden Vorteile des F303 zum F103? Klar er ist neuer, aber wurde was verbessert oder Fehler ausgemärzt?
F3xx ist für Analoge Messungen/Bearbeitung konzipiert und hat entsprechend hochauflösende ADC drin.
?!? hat er das?! 12Bit wie alle anderen auch, Du meinst sicher die 373 Serie? Es geht mir aber um die 303
Thomas M. schrieb: > Wo sind die drängenden Vorteile des F303 zum F103? Kommt sehr auf den Anwendungsfall an. Für mich sind die alten attraktiver, wegen der Verfügbarkeit von Boards.
FPU hat der 3xx auch drin. Und noch spezielle OpAmp Module für Signalverarbeitung, hatte ich noch nie benutzt. Hatte ich verwechselt, die 37x haben 16 Bit ADC drin.
:
Bearbeitet durch User
hmm..ok. also sind die 303 wer schneller beim ADC noch rauschen sie weniger oder sonstwas..also im Grunde alles wie beim 103 und gar kein Drama dabei zu bleiben?
Nee, die F3 haben einen M4 mit FPU, die 103 "nur" einen M3, also keine FPU. Die Unterschiede bei den internen RC-Oszillatoren sind immens zwischen F1, F4 und neuen L4. Der STM32L451 z.B. ist mit -2/+1.5% von -40° bis +125° spezifiziert. Damit kann man wirklich ein UART betreiben. Bei der gesamten F-Familie geht das nur bei Zimmertemperatur, der STM32F405 z.B. macht ±4% bei -10° bis +85°.
Stefanus F. schrieb: > die alten > attraktiver ich habe blue pill board mit STM32F303CCT6 (cortex m4, fpu, 256k, 48k ram) verheiratet für beides zusammen unter 5$ bei aliexpress Stefanus F. schrieb: > Ja, nur von allem etwas mehr. das glaube ich ganz sicher nicht! stm32f303 - cortex m4, fpu, dsp instr. - advanced rtc/calendar, more timer functions - internal usb bootloader - much better low power mgt. - infrared interface - 4x opa's - adc, 12-bit resolution 0.19µs/5.1Ms/s, five times faster as f103/1us - ... bin geneigt zu sagen - ein (kleiner?!) quantensprung ich werde nach und nach alle meine blue pill board modifizieren! mt https://de.aliexpress.com/item/Marke-neue-original-STM32F303CCT6-STM32F303-LQFP-48-ARM-Cortex-M4-32-bit-mikrocontroller-MCU-IC-chip/32974557401.html?spm=a2g0s.9042311.0.0.23654c4dp8jw77 https://de.aliexpress.com/item/STM32F103C8T6-ARM-STM32-Minimum-System-Development-Board-Module/32656048071.html?spm=a2g0s.9042311.0.0.23654c4dp8jw77
:
Bearbeitet durch User
Der Nutzen ist gering bis nicht vorhanden, wenn man die zusätzlichen/neuen Features nicht benutzt. Die F3 Serie hat nichts, was ich bisher vermisst hatte. Ich glaube trotzdem jedem, der sagt, dass die neuen Chips für seine Projekte besser sind.
Nach eingehender Recherche, hier im Forum und in Herstellerdatenblättern bin ich zu dem Schluss gekommen dass es bei meinem bescheidenen Funktionsbedarf eigentlich vollkommen gleich ist welchen Hersteller ich nehme, ich werde mir die ARM und die AVR Serie antun, zuerst die ARM und dann kommt noch ein AVR Programmiergerät. Ich hab mich jetzt mehr oder weniger intensiv mit den STM32 auseinander gesetzt und werde wohl auch dabei bleiben. Nächste Woche dürfte das Nucleo Board kommen und dann werd ich mal die ersten Gehversuche machen. Danke für die ausfühlichen Antworten, es wird wohl nicht lange dauern bis meine ersten STM32-Fragen im Forum auftauchen.
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.