Forum: Mikrocontroller und Digitale Elektronik Mikrocontroller - die Qual der Wahl, oder doch die Wahl der Qual?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Markus B. (besser)


Bewertung
0 lesenswert
nicht lesenswert
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?

:
von pegel (Gast)


Bewertung
3 lesenswert
nicht lesenswert
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.

von jemand (Gast)


Bewertung
-3 lesenswert
nicht lesenswert
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.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Falk B. (falk)


Bewertung
3 lesenswert
nicht lesenswert
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.

von Doctor Snuggles (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Sebastian S. (amateur)


Bewertung
2 lesenswert
nicht lesenswert
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
von dsghrhtzujtj (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
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.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Markus B. (besser)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Udo S. (urschmitt)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Peter D. (peda)


Bewertung
5 lesenswert
nicht lesenswert
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.

von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Für STM32 ist das leicht: Nucleo Board enthält alles Nötige, SW4STM32 
ist die kostenlose Programmierumgebung und STM32CubeMX macht das Leben 
einfacher.

von Udo S. (urschmitt)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Stefan ⛄ F. (stefanus)


Bewertung
-2 lesenswert
nicht lesenswert
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.

von 73 de Hamburg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Stefan ⛄ F. (stefanus)


Bewertung
6 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Schorsch X. (bastelschorsch)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Mach (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von neuer PIC Freund (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> 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.

von Viktor B. (coldlogic)


Bewertung
1 lesenswert
nicht lesenswert
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

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
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
von x^y (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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).

von John Doe (Gast)


Bewertung
3 lesenswert
nicht lesenswert
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.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
>> 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.

von M. K. (sylaina)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Stefan ⛄ F. (stefanus)


Bewertung
2 lesenswert
nicht lesenswert
M. K. schrieb:
> PIC oder AVR. Den kann seit Jahren keiner
> eindeutig für sich entscheiden.

Das ist wie Citroen Berlingo versus Peugeot Partner

von Volker S. (vloki)


Bewertung
0 lesenswert
nicht lesenswert
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
von Stefan ⛄ F. (stefanus)


Bewertung
-1 lesenswert
nicht lesenswert
Beim Programmieradapter/Debugger MPLAB Snap empfehle ich, die 
Softwarekompatibilität vor dem Kauf zu klären.

von Stromverdichter (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Bewertung
0 lesenswert
nicht lesenswert
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
von Volker S. (vloki)


Bewertung
0 lesenswert
nicht lesenswert
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.
von silsi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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/

von silsi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hier noch eine vollständige Liste:
https://www.segger.com/downloads/supported-devices.php

von Dergute W. (derguteweka)


Bewertung
0 lesenswert
nicht lesenswert
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

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
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.

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
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. ;-)

von neuer PIC Freund (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> 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.

von M. K. (sylaina)


Bewertung
0 lesenswert
nicht lesenswert
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 ;)

von Günter M. (redround)


Bewertung
0 lesenswert
nicht lesenswert
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
von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
> 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.

von W.S. (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
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.

von Christopher J. (christopher_j23)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von M. K. (sylaina)


Bewertung
1 lesenswert
nicht lesenswert
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 ;)

von achje... (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von M. K. (sylaina)


Bewertung
0 lesenswert
nicht lesenswert
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 ;)

von Stefan ⛄ F. (stefanus)


Bewertung
4 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Stefan ⛄ F. (stefanus)


Bewertung
1 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
Beitrag #5775431 wurde von einem Moderator gelöscht.
Beitrag #5775882 wurde von einem Moderator gelöscht.
von Christopher J. (christopher_j23)


Bewertung
4 lesenswert
nicht lesenswert
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.

von Christopher J. (christopher_j23)


Bewertung
0 lesenswert
nicht lesenswert
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 vom Autor gelöscht.
von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Beitrag #5776588 wurde von einem Moderator gelöscht.
von Gastino G. (gastino)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Stefan ⛄ F. (stefanus)


Bewertung
1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Markus M. (mmvisual)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Dergute W. (derguteweka)


Bewertung
0 lesenswert
nicht lesenswert
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

von Falk B. (falk)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Markus M. (mmvisual)


Bewertung
0 lesenswert
nicht lesenswert
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
von Thomas M. (Firma: https://img.favpng.com/23/21/3) (thomasmopunkt)


Bewertung
0 lesenswert
nicht lesenswert
etwas OT..
Wo sind die drängenden Vorteile des F303 zum F103?
Klar er ist neuer, aber wurde was verbessert oder Fehler ausgemärzt?

von Markus M. (mmvisual)


Bewertung
0 lesenswert
nicht lesenswert
F3xx ist für Analoge Messungen/Bearbeitung konzipiert und hat 
entsprechend hochauflösende ADC drin.

von Thomas M. (Firma: https://img.favpng.com/23/21/3) (thomasmopunkt)


Bewertung
0 lesenswert
nicht lesenswert
?!? hat er das?!
12Bit wie alle anderen auch, Du meinst sicher die 373 Serie?
Es geht mir aber um die 303

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Markus M. (mmvisual)


Bewertung
0 lesenswert
nicht lesenswert
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
von Thomas M. (Firma: https://img.favpng.com/23/21/3) (thomasmopunkt)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Thomas M. schrieb:
> also im Grunde alles wie beim 103

Ja, nur von allem etwas mehr.

von Bauform B. (bauformb)


Bewertung
0 lesenswert
nicht lesenswert
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°.

von Apollo M. (Firma: @home) (majortom)


Bewertung
0 lesenswert
nicht lesenswert
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
von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Markus B. (besser)


Bewertung
0 lesenswert
nicht lesenswert
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.

Dieser Beitrag kann nur von angemeldeten Benutzern beantwortet werden. Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail, Yahoo oder Facebook? Keine Anmeldung erforderlich!
Mit Google-Account einloggen | Mit Facebook-Account einloggen
Noch kein Account? Hier anmelden.