Welcher ARM-Prozessor als Anfänger ?

Wenn Du hier fragst, klicke oben auf den Filter ARM und siehe dir die 
Anzahl der Ergebnisse an.

Dann kannst Du abschätzen, wofür es hier die meiste Unterstützung gibt.

einsteiger schrieb:

> - verschiedene Schnittstellen, ADC, DAC, DSP

DSP?

Was bedeutet Anfaenger ? Anfaenger mit Arm, oder 32 bit, oder generell ?

Eine Suche nach ARM bei einem Distributor wie zB Digikey bringt die 
Hersteller. Dann heisst es bei den Herstellern die Datenblaetter zu 
durchwuehlen.

STM32F0 oder STM32G0 z.B. STM32F030C8T6TR

> Das ist keine Schnittstelle, sondern es gibt spezielle Assemblerbefehle
> die dafür geeignet sind, digitale Filter zu programmieren

Hat das nicht mittlerweile jeder ARM? Andererseits sind sie ja 
mittlerweile so schnell das man fuer viele Dinge das auch ganz einfach 
ohne zu denken hinschreiben kann. Interessant war das IMHO zu Zeiten als 
Controller mit ein paar Mhz liefen. (z.B die R8C von Renesas)

Olaf

Du musst dich nach den Features orientieren, die du brauchst.
Alles andere hier ist doch nur Kaffeesudlesen.


Aber mal ein paar Anregungen:


"Einfacher" Mikrocontroller:
============================

günstiger Kontroller ohne viel Rechenleistung und Schnittstellen: M0, 
M0+

Floating Point:  M4 oder M7

Ethernet mit integrierter PHY: MSP432 (schönes TI Betriebssystem)

USB High Speed mit integrierter PHY: NXP oder Microchip (Cortex M7)
(manche STM32 haben PHY, aber alle kein Ethernet)

Rechenleistung (DSP):  schnelle M7 > 400 MHz gibts bei NXP und ST

aufwändige Motorsteuerungen: NXP/Freescale, Infineon

Günstig für Hobby: STM32

Günstig für hohe Stückzahlen: eher nicht STM32

Low Power:  Hängt von der Anwendug ab...
Moderner 400 MHz M7 bei kleinem Duty-Cycle
braucht sehr wenig Strom (dynamischer Verbrauch),
oder auf Low Power getrimmter M0/M4 (statischer Verbrauch).

Funkanwendung: TI, Silabs


2D Graphikengine integriert: Moderner M7

Ja, und dann gibts viele "Spezielle" Wünsche, wie Dekodieren
von mehreren Quadraturencodern in HW.
oder Unterstützung für dein Lieblingsbetriebssystem,
oder Verfügbarkeit im Lieblingsgehäuse...


Muss Linux drauf laufen:  ARM Application Processor
===================================================
* A20, A13 aus Fernost (Olimex)

* Sitara Serie von TI (Beaglebone)

* (A10, A20) Rasperry Pi

* Xilinx Zynx Board (FPGA und Linux, superflexibel)


Linux/Windows mit PC Kompatibilität: Micro/Nano PC Board
======================================================
* Intel Processor

* SATA, Gigabit Ethernet, USB 3.1, PCIe etc.

* > 4 GB RAM

* schnelle HDMI Grafikausgabe

* nicht viel teurer als die ARM Boards

* Kompatibilität und Leistung.

einsteiger schrieb:
> welchen ARM-Prozessor würdet ihr alktuell empfehen, wenn folgende Punkte
> wichtig sind :

GAR KEINEN !

SONDERN:

Stecke zu allererst deine Nase in die Datenblätter und Referenzmanuals 
verschiedener Hersteller und lies, damit du was dabei lernst.

Und auch, damit du merkst, mit welchen Dokumenten du besser oder 
schlechter zurecht kommst.

Dann kannst du auch selber entscheiden, welches Silizium dir am besten 
in deinen Kram paßt.

Das ist am Anfang das Wesentliche.

Wenn du hingegen so zu fragen anfängst, wie du es im Eröffnungspost 
getan hast, dann kriegst du von 10 Leuten mindestens 11 völlig 
verschiedene Empfehlungen.

Und was "kostenlose Entwicklungsumgebungen" betrifft, da kannst du dir 
selber was aussuchen - sofern du drauf achtest, daß sie soweit 
universell sind, daß sie dich nicht an einen bestimmten IC-Anbieter 
anschmieden.

Notepad zum Beispiel ist per se universell genug und wer Geany mag, der 
hat auch was universelles.

Und Langlebigkeit/Portierbarkeit ist definitiv DEIN Bier und nicht das 
eines Herstellers oder Chips. Da kommt es nämlich drauf an, ob du beim 
Programmieren schluderst oder nicht.

W.S.

Bernd K. schrieb:
> "ARM ist kompliziert" und man könne ohne HAL
> nicht arbeiten

Das sind 2 Probleme in einem:

Zum einen steckt die Firmenpolitik von ST dahinter, wo versucht wird, 
die Leute an ST's Galeere anzuschmieden.

Zum anderen ist es die dümmliche Arroganz gar vieler Leute selber, die 
da meinen, es sei absolut schlechter Stil, Hardware-Register selbst 
anzufassen.

Beides kann man wohl nicht ändern, also bleibt nur eines: Die Leute 
laufenlassen, schließlich passen da Anbieter und Kunden offenbar 
prächtig zueinander.

W.S.

Also wenn es stromsparend & ARM sein soll dann vieleicht SAMDxx.
Aber die sind so komplex, dass dir als Anfänger der Kopf platzt.
Ein anderer wichtiger Punkt könnte das Gehäuse sein.
Moderne, leistungsfähige µCs sind meist in TQFP / QFN.
Kannst du sowas löten?
Alternativ kann man aber den Prozessor auf einem kleinen 
Entwicklungsboard verwenden!
Wirklich stromsparend ist ein µC wenn er im sleep-modus ist,
oder wenn der Takt auf extrem langsam geschaltet werden kann
und er mit 3,3V läuft.

Die meisten Anfänger nehmen irgend einen Arduino etc.
Je mehr der Prozessor kann, umso viel komplizierter ist er.
Wenn du Grundlagen lernen willst, fange mit einem 8Bitter an.

Einen DSP-fähigen Prozessor wirst du garantiert nicht wollen!
Denn allein die Einarbeitung in Filter ist ein eigenes Studium.
Das ist auch nicht stromsparend.

Als Anfänger sollte man sich unbedingt auch das mbed Konzept ansehen, 
viele Nucleo-Boards sind kompatibel. Auch andere Linien sind erhältlich, 
siehe Hardware. Kostet alles nichts, Compiler ist im Browser 
(funktioniert besser als man zunächst denken würde), Offline ist auch 
möglich. Das Browser-Konzept ist echt interessant, keine Installation, 
geht überall. Sogar inkl. Versionsverwaltung. Der Compiler dahinter ist 
Keil(ARM).

Der Vorteil am mbed Konzept ist, dass man mit dem ganzen Low-Level Zeug 
erstmal nichts zu tun hat. Man braucht keinen speziellen Bootloader, die 
Binaries sind nachher auch in eigenen Projekten lauffähig.

Wenn es dann irgendwann doch Richtung low-Level gehen soll, kein 
Problem. Lässt sich alles recht einfach auf z.B. cubeMX portieren.

Man sieht, zu diesem Thema gibt es zahlreiche Einschätzungen bzw. 
Extreme. Es fehlt eigentlich nur noch der Hinweis auf hartes Codieren 
direkt auf Bitebene OHNE Assembler. Dann lernt man die CPU so richtig 
gut kennen ;-)

Bauform B. schrieb:
> Nicht ganz so. Für manche Chips verspricht der Hersteller 15 Jahre
> Lieferbarkeit, andere sind schon wieder abgekündigt, bevor...

Ja, ist bekannt. Aber das ist ja auch gar nicht der eigentliche Punkt. 
Sondern wenn man sauber zwischen den verschiedenen Ebenen trennt und die 
Interfaces zwischen den Ebenen jeweils unabhängig macht von dem darunter 
liegenden Zeugs, dann ist ein Chipwechsel ganz erheblich vereinfacht.

Beispiel GLCD per I2C am µC:

ganz unten: Lowlevel-Treiber für den I2C. Dessen Interface (s.o.) 
OpenSlave, ReadSlave, WriteSlave, CloseSlave. Das ist schon mal 
unabhängig von der konkreten Plattform.

eins drüber: Lowlevel-Treiber für das Display: baut auf dem I2C-Treiber 
auf, Init, Bild-Speicher im RAM, Blocktransfer zum Display, Helligkeit, 
Kontrast, usw.

noch eins drüber: GDI. Baut auf dem Bild-Speicher des Displaytreibers 
auf. Zeichnet Linien, Kringel, Flächen, Texte in diversen Fonts

noch eins drüber: grafische Elemente. Labels, Buttons, usw.

und so weiter. Mit jeder Ebene fliegt eine Abhängigkeit raus. Auf diese 
Weise ist die Portierung von einem Stück Silizium auf ein anderes 
weitaus leichter als mit jeder anderen Struktur. Beispiel sind die 
Fonts, die ich hier schon mal gepostet hatte. Gleichermaßen verwendbar 
auf NEC 78K4, Fujitsu FR, ATM7TDMI (Lernbetty...) bis heutigem Cortex-M. 
Also von 8/16 Bit CPU bis 32 Bit, von Bigendian zu Littleendian, von IAR 
über Softune bis Keil - und das ohne jegliche Quelländerung. Reicht's?

Also nochmal: Langlebigkeit und Portierbarkeit liegen fast gänzlich im 
Geschick des jeweiligen Programmierers.

W.S.

Bei STM sind die STM32L Serien auf's Stromsparen getrimmt. Für den 
Anfang würde ich ziemlich weit unten mit einem Nucleo64 Board mit 
STM32L072 oder STM32L073 anfangen. Anleitung: 
http://stefanfrings.de/stm32/stm32l0.html

Die stm32 sind relativ einfach zu verwenden. Ich habe damit nach den 
AVRs angefangen (ich nutze Teile der lib von st, für die 
Initialisierung, denn wer die Register selber setzt, hat irgendwie 
zuviel Zeit). Der Einstieg ging sehr flüssig von der Hand und nach ein 
paar Tagen habe ich dann sogar mit der DMA gespielt und größere Projekte 
realisiert.

Also wenn man sich auf etwas konzentrieren kann und sich mit einer Tasse 
Tee hinsetzt, findet man den Einstieg sehr schnell. Es gibt im Netz sehr 
viele Beispiele und Hilfe ohne Ende.

Ich bin mit Arduino angefangen und letzten Endes auf STM32 umgestiegen, 
was ein schmerzhafter aber sehr lohnenswerter Prozess war.

Verschiedene Entwicklungsumgebungen wurden ausprobiert: CooCox, Atollic, 
AC6, GNU GCC Toolchain und zuletzt die CubeIDE welche aus der Atollic 
IDE hervorgeht. Am schmerzlosesten war die CubeIDE von ST, da diese im 
Gegensatz zu vielen anderen Lösungen wenigstens zuverlässig ein 
kompilierbares Projektgerüst für die Controller erzeugen kann, beim 
STM32F070F6P6 hatte die GNU GCC Toolchain damit bereits Probleme. Ein 
Wizard zur MCU-Auswahl und Konfiguration ist in die CubeIDE integriert. 
Das hört sich jetzt so an als wäre das ein Umstiegsprozess von einigen 
Tagen oder Wochen gewesen aber bis ich bei der CubeIDE angekommen bin 
sind locker zwei Jahre vergangen, alles davor hat mich immer und immer 
wieder von STM32 weggeekelt...

Das Hauptproblem mit ST ist, dass die freien Toolchains lange Zeit 
zusammengewürfelte Müllhaufen waren und es noch zu einem gewissen Teil 
sind. Nichts funktioniert von Anfang an, überall kleine Gotchas und 
Bugs. Ich hab kein Problem damit das Datenblatt zu lesen und Register im 
Zweifelsfall selber zu beschreiben um die Features des MCUs zu nutzen, 
aber wenn es schon zum Akt wird ein lauffähiges Projektgerüst zu 
erstellen, was die verdammte Grundaufgabe solcher aufgeblähten 
Entwicklungsumgebungen ist, dann sind doch Hopfen und Malz verloren, wie 
soll ein Anfänger da Boden fassen wenn noch nicht mal DAS ohne große 
Verrenkungen über die Bühne läuft?

Also meine Empfehlung ist STM32L-Serie mit Cube IDE: Einfach weil das 
die zur Zeit funktionsfähigste/vollständigste kostenlose STM32 IDE ist. 
Ob du die CubeHAL nutzt oder nicht kannst du immer noch entscheiden, 
wichtig ist einen funktionierenden Startpunkt unabhängig von deiner 
Prozessorwahl zu haben. Die HAL hat viel Overhead aber zur 
Initialisierung ist sie zusammen mit CubeMX sehr sehr praktisch. Zum 
Debuggen und Programmieren eignen sich die ST-Link V2 Sticks die man so 
auf Ebay, etc. für ein paar Euros findet. Alle MCU-Bauformen die noch 
herausgeführte Pins haben (TQFP und TSSOP) lassen sich wunderbar mit 
etwas Flussmittel(gel) verlöten.

Florian schrieb:
> Ich bin mit Arduino angefangen und letzten Endes auf STM32
> umgestiegen,
> was ein schmerzhafter aber sehr lohnenswerter Prozess war.
>


Warum lohnenswert? Was hat dir an Arduino nicht gefallen?

> Warum lohnenswert?

Ich wollte die billigen und schnellen (32bit & 48MHz aufwärts) STM32er 
einsetzen können und deren Potential (DMA => Parallele Ausführung von 
UART, SPI und I2C) auch ausschöpfen können, das ist jetzt möglich.

Einige STM32er können zwar via Arduino bespaßt werden, aber dann ist man 
auf bestimmte Modelle die auch Support haben eingeschränkt, außerdem 
fehlt das Debugging mit durchsteppen. Weithin sind viele Funktionen wie 
SPI, I2C und Serial dort so weit weg-abstrahiert, dass man das Ganze 
entweder neu schreiben muss um Features wie DMA und Interrupts in diesem 
Kontext zu nutzen oder auf die blockierende Implementationen beschränkt 
ist. Dank dem Cube IDE Eclipse Verschnitt habe ich dort auch Debugging, 
Autovervollständigung und besseres Projekt-Management mit Ordnern etc 
etc etc

> Was hat dir an Arduino nicht gefallen?

Im Grunde finde ich Arduino sehr gut, man kann damit vieles schnell und 
zuverlässig auf die Beine stellen, besonders wenn man die ATMEGAs nutzt, 
da wurde an den Bibliotheken viel gefeilt. Der Abstraktionsgrad ist 
jedoch recht hoch und das Tooling primitiv wie oben schon angeschnitten, 
ab nem bestimmten Projektumfang macht das einfach keinen Spaß mehr. Das 
gibt so ein Gefühl keine Kontrolle und keinen Einblick in den MCU zu 
haben wenn man das exklusiv nutzt.

Gibt es von STM auch parallele Ausführungen von DAC? 
Digital-Analog-Converter bräuchte ich davon mindestens 8 Kanäle

DMA mit DAC wird natürlich unterstützt, google mal:

> Audio and waveform generation using the DAC in STM32 microcontrollers.

Aber 8 Kanäle? Wenn du 8 parallel nutzbare DAC Ausgänge meinst wird es 
schwierig, kann ich mir schwer vorstellen dass es da einen mit mehr als 
3 DACs gibt. Falls du das Mixen von 8 Tonspuren meinst, hängt das von 
deinen Programmierfertigkeiten ab >:)

Florian schrieb:
> Das Hauptproblem mit ST ist, dass die freien Toolchains lange Zeit
> zusammengewürfelte Müllhaufen waren und es noch zu einem gewissen Teil
> sind.

Florian schrieb:
> Ich wollte die billigen und schnellen (32bit & 48MHz aufwärts) STM32er
> einsetzen können und deren Potential (DMA => Parallele Ausführung von
> UART, SPI und I2C) auch ausschöpfen können, das ist jetzt möglich.

Florian schrieb:
> Weithin sind viele Funktionen wie
> SPI, I2C und Serial dort so weit weg-abstrahiert, dass man das Ganze
> entweder neu schreiben muss um Features wie DMA und Interrupts in diesem
> Kontext zu nutzen oder auf die blockierende Implementationen beschränkt
> ist.

Ach nö, das von dir genannte Hauptproblem ist, daß du dir deine eigene 
Firmware eben nicht wirklich durchdacht hast.

Du legst zwar größten Wert darauf, per Debugger duch deinen Code steppen 
zu können, scheinst aber ansonsten mit Fleiß dich vollauf darauf 
verlassen zu wollen, daß die Hersteller von Chips dir eine voll 
ausgefeilte Infrastruktur zur Verfügung stellen, damit du dich nicht 
persönlich mit deren Chips befassen und dir deine eigene Infrastruktur 
schaffen mußt.

Man kann das ja machen so wie du, hier in diesem Forum gibt es wirklich 
viele Leute, die es so tun - aber damit hängst du eben an den Produkten 
von ST ohne selbige wirklich selbst zu kennen oder gar ohne das 
Vorgekaute von ST zurecht zu kommen. Das führt dann zu aufgeblähten 
Projekten, aufgeblähtem Code, Kampf gegen IDE und nicht passenden 
Bibliotheken etc.

Und es ist ne ziemliche Einschränkung - da fällt mir das dazu ein: "yes 
sir, I can boogie - but I need a _certain song_:..."

Eben: Ohne genau diesen 'Song' aka STM32, aka ST-Software, geht dann 
eben garnichts.

W.S.

W.S. (Gast) muss ein Bot sein. Der triggert sobald jemand ST lobt und 
haut dann immer die gleichen Phrasen rein, ohne die Beiträge der Leute 
zu lesen.

Die AVR waren/sind beliebt weil gerade auch der Einstieg diese zu 
programmieren einfach ist: WinAVR installiert, die richtige MCU 
ausgewählt und ein main.c wurde erstellt. Das Leben beginnt bei main() 
und nach zwei Befehlen ist eine LED eingeschaltet. Den Krampf mit den 
vielen inkompatiblen Debugprobes und OOCD usw. gab es nicht.
Den Komfort möchte nicht nur ich auch bei anderen Controlleren haben, 
auch wenn ich verstehe das es bei Reset losgeht und noch ein paar Dinge 
vor main() abgehen. Und weil ich nicht alles mit einem einzigen µC Typen 
erschlagen will und von der Vielfallt der Cortex-M Familien profitieren 
möchte, habe ich auch nicht das Bedürfnis oder die Zeit und Musse jedes 
mal aufs Neue das Rad neu zu erfinden. Und da helfen definitiv OS und 
Frameworks wie Arduino, Mbed, HAL, ASF, FSF, ChibiOS, NutOS, RiotOS uvm. 
sowie IDE von Arduino, VSCode, Atom, Theia, Eclipse uvm.
Mit dem low level Kram kann man anfangen, muss man aber nicht. Nicht 
mehr im Jahre 2019.
Die Abstrahierung sorgt nicht nur dafür das viel Müll publiziert wird, 
sondern auch dafür das kreative Köpfe gute Ideen auf Anwenderlevel 
einbringen. Hier hatte mal jemand geschrieben Arduino ist sowas wie 
Linux für µC, das stimmte nicht. Arduino ist wie das Windows für µC. Es 
sorgt dafür das Leute etwas Bauen und der µC das Werkzeug ist, nicht wie 
die Freaks die sich mit dem µC wegen des µC beschäfftigen und am 
liebsten Zyklen zählen und sparen. Die dürfen dann gerne sinnvolle Libs 
schreiben. Wenn alle so low level denken würden hätte der PC heute noch 
einen grünen Bildschirm und einen blinkenden Cursor, von Informatikern 
für Informatiker.
So, mein Wort zum Sonntag.

Mw E. schrieb:
> W.S. scheint nur alt und borniert zu sein.

Ganz so schlimm sehe ich es nicht und aus der Lernbetty konnte man auch 
einiges mitnehmen. Nur die Datenblätter (bzw. wegen des Umfangs sind die 
ja schon geteilt in DB und User Manual) lesen sich nicht wie ein Perry 
Rhodan Roman den man mal vor dem Schlafen lesen kann. Nicht jeder ist 
der gleiche Lerntyp und andere wollen erstmal anfangen, ein 
Erfolgserlebnis haben und dann evtl. sehen wie es unter der Haube 
funktioniert. Und das finde ich nicht verwerflich. Gut, ist manchmal 
schwer verdaulich was hier gefragt wird, aber man muss ja nicht 
antworten. Und die Leute, bzw. sind das sicher oft sehr junge Anfänger, 
wird man mit den DB Predigten nur vergraulen. Eine IDE und einfach zu 
bedienender Debugger helfen dann zu verstehen was im fremden Code 
abgeht, und da sehe ich den grössten Vorteil in ARM vs. AVR.

W.S. hat da aus einer idealistischen Perspektive schon recht, es ist 
natürlich auch Faulheit am Werke bei mir, ich hab halt keine Lust jedes 
mal für einen neuen MCU auch noch Registerdefinitionen, Startercode, 
Linkerscripts und was nicht alles zu schreiben.

Aber, wieso ist es so schlimm zu erwarten, dass diese für fast jedes MCU 
Projekt absolut essenziellen Grundgerüste nicht schon verfügbar sind? 
Der Chip-Hersteller sollte doch ein Interesse daran haben, dass der 
Nutzer seiner Produkte diese auch ohne Verrenkungen einsetzen kann und 
als Programmierer ist man im Endeffekt nur Benutzer eines 
Mikrocontrollers, egal wie und womit man ihn Programmiert.

Florian schrieb:
> Aber, wieso ist es so schlimm zu erwarten, dass diese für fast jedes MCU
> Projekt absolut essenziellen Grundgerüste nicht schon verfügbar sind?

richtig, davor wurde man beim AVR auch verschont, auch wenn das zur 
Programmierung dazugehört. Und die Notwendigkeit irgendwelcher HAL gab 
es auch nicht zwingend, die paar Register waren einfacher mit benannten 
Konstanten zu setzen. Die Cortex-M haben unendlich viel Peripherie an 
Board, ich möchte nicht immer Ethernet, USB, Grafik und sonstige 
Schnittstellen selber neu erfinden. Und in Zeiten von github & Co. 
verdient man mit diesen Libs heute auch kein Geld mehr, für all den High 
Level Stuff aka Middleware hat man mal viel bezahlen müssen.

Na und?
Willst Du ihm auch noch vorschreiben, was er zu essen hat?

Für Anfänger?
Ganz klar STM32F103CB8
Der hat sich mittlerweile durchgesetzt und massenhaft bei Ebay als 
Bluepill erhältlich.
Ist so was wie ein Atemga32 nur halt im im Jahre 2019#
Keine  weiteren Spekulationen erfoderlich.
Machst Du ihn kaputt, kauft Du für 199€ oder so einen neun.
Software C kostenlos(Atolic Truestudio, Cube MX, oder mit Mikroe in 
Pascal, C oder Basic programmierbar.

Natürlich fängt man mit einem STM32 an. Dafür gibt es (für Einsteiger) 
die besten Entwicklungsumgebungen, die besten Tutorials, die besten 
EVAL-Boards (inkl. Debug Interface), die beste Unterstützung ...

Florian schrieb:
> Aber, wieso ist es so schlimm zu erwarten, dass diese für fast jedes MCU
> Projekt absolut essenziellen Grundgerüste nicht schon verfügbar sind?
> Der Chip-Hersteller sollte doch ein Interesse daran haben, dass der
> Nutzer seiner Produkte diese auch ohne Verrenkungen einsetzen kann und
> als Programmierer ist man im Endeffekt nur Benutzer eines
> Mikrocontrollers, egal wie und womit man ihn Programmiert.

Du hast den prinzipiellen Interessenkonflikt noch nicht verstanden.

Als Geräte-Entwickler sucht man nach Bauteilen, die zum aktuellen 
Projekt passen - egal, wer grad der Chip-Hersteller ist. Da möchte man 
sich am liebsten den am besten passenden Chip aussuchen. Die eigenen 
Algorithmen hingegen, also das, was die eigentliche Funktionalität des 
zu entwickelnden Gerätes (und die eigene Entwicklungsleistung) ausmacht, 
möchte man hingegen auch bei etwaigem Chipwechsel beibehalten. Folglich 
ist für einen selbst die Hersteller-Unabhängigkeit von hohem 
Stellenwert, damit das eigentliche eigene Zeugs nicht wertlos wird, wenn 
man das Silizium mal wechselt.

Als Chip-Hesteller sucht man hingegen, seinen Umsatz und Gewinn stabil 
hoch zu halten, wozu eben auch eine möglichst feste Bindung der Kunden 
an das eigene Portfolio gehört. Eben, damit so ein Kunde nicht so leicht 
den Chip der Konkurrenz einsetzt, der evt. etwas besser in dessen 
Konzept paßt oder ökonomisch besser dasteht. Genau deshalb darfst du 
bei keinem Hersteller erwarten, daß er im Sinne DEINER Interessen 
handelt.

Diesen grundsätzlichen Interessenkonflikt kannst du oder ich oder jeder 
andere hier garantiert NICHT beseitigen.

Stattdessen kannst du dich entscheiden, ob und wie weit du dich auf nur 
einen bestimmten Hersteller einlassen willst - oder ob du genau dieses 
eben NICHT tun willst.

Das ist bei allen hitzigen Diskussionen hier der eigentliche Kernpunkt.

Das ist auch der Grund, weswegen die diversen Fanboys sich maßlos 
aufregen bis hin zu unflätigen Reden, wenn jemand sich eben nicht drauf 
einläßt.

Und nochwas:
Deine Bemerkung "als Programmierer ist man im Endeffekt nur Benutzer.." 
ist falsch. Das Programmieren eines µC läuft auf das Schaffen einer 
Firmware hinaus und die ist Teil des Einsatzes dieses µC in einer 
Schaltung, auf einer Leiterplatte, in einem Gerät - es ist das von dir 
genannte Programmieren ein Stück Entwicklungsarbeit, also letztlich Teil 
eines Herstellungsprozesses. Du bist als Programmierer eben nicht 
Benutzer, sondern Hersteller (Teile-Bearbeiter) und der blanke µC ist 
das Halbzeug, welches du bearbeitest. Vergleiche das lieber mit dem 
Metaller, der sich ein Stück Eisen kommen läßt und daraus nen Löffel 
anfertigt.

Im Gegensatz dazu ist deine Frau, wenn sie mit ihrer Busenfreundin 
quasseln  will, Benutzer ihres Mobiltelefones. Begreife mal den 
Unterschied.

W.S.

W.S.
>Stattdessen kannst du dich entscheiden, ob und wie weit du dich auf nur
>einen bestimmten Hersteller einlassen willst - oder ob du genau dieses
>eben NICHT tun willst.

Das ist genau der Grund, warum ich die Arduino-API immer währmstens 
empfehle.
Sie ist Hersteller unabhängig und desto mehr Leute sie benutzen und um 
so weiter die  API entwickelt wird, desto mehr wird sie sich im 
professionellen Umfeld verbreiten.

>Deine Bemerkung "als Programmierer ist man im Endeffekt nur Benutzer.." ist 
falsch.

Nö, die ist goldrichtig, du sagst es ja selbst: Der Schöpfungswert liegt 
in der Auswahl eines passenden Mikrocontrollers, dem Schreiben der 
Firmware und der Entwicklung einer Schaltung. Aus Sicht des 
Mikrocontroller-Herstellers bist du als Entwickler einer 
Embedded-Anwendung aber nur ein Benutzer, du benutzt deren Produkt, den 
Mikrocontroller, in deiner Schaltung zur Erfüllung deiner 
anwendungsspezifischen Aufgabe, so wie in deinem beknackten Beispiel das 
Telefon zur Kommunikation benutzt wird: Das Eintippen der Nummer und die 
Laberei sind dabei das Aufspielen der Firmware und die Inbetriebnahme 
der Schaltung.

Dadurch dass du als Embedded-Entwickler MCUs in deinen Projekten nutzt, 
hat der Hersteller natürlich ein Interesse daran, dass du erstens: Deren 
Produkte einsetzt und zweitens: Bei dieser Firma bleibst. Das Letztere 
ist der Punkt auf dem du hier dementös rumreitest, hat aber nichts mit 
meiner Aussage zu tun. Wenn der Hersteller anfängt mir Scheiße in den 
Rachen zu stopfen, mit Closed Source APIs, Online-IDEs oder was auch 
immer für lustige Scherze, dann wechsel ich halt zum nächst besseren 
Hersteller der mir die gibt was ich brauche: Eine Entwicklungsumgebung 
in der ich meine Algorithmen möglichst effizient auf deren Stück 
Silizium bringen kann.

>Die eigenen Algorithmen hingegen, also das, was die eigentliche Funktionalität 
des zu entwickelnden Gerätes (und die eigene Entwicklungsleistung) ausmacht, 
möchte man hingegen auch bei etwaigem Chipwechsel beibehalten.

Da ich meine Algorithmen und Treiber in C entwickle sind diese per se 
portabel. Ich müsste für meinen SX1280 Treiber lediglich WriteSPI neu 
implementieren und die Sache ist geritzt.

Naja, ich check jetzt auch was die Anderen hier meinen, du rotzt hier im 
Endeffekt nur deine Talking-Points rein, egal wie tangential die zum 
eigentlichen Thema sind, patronisierender Unterton inklusive.

Früher war es sicher nötiger für verschiedene Produkte den µC Hersteller 
zu wechseln. Wenn man aber sieht was die Grossen heute mit den Cortex 
M0-H7 aus einer Hand alles abdecken ist das schon gewaltig und ein 
Wechsel kaum noch nötig wenn man sich auf einen eingeschossen hat. 
Selbst einfache µC können mittlerweile von Strom sparen bis schnell 
rechnen alles in einem, viel Speicher und Peripherie dazu obendrauf.

> wie ein Perry Rhodan Roman den man mal vor dem Schlafen lesen kann

Komisch, dabei schlafe ich nach spätestens 10 Seiten immer ein.

Ingo L. schrieb:
> STM32F4, welche
> enorm durch die CPU gestört werden...

Kalibrierung durchgeführt? Die ist enorm wichtig und hat massiven 
Einfluss auf das Ergebnis.

Andreas S. schrieb:
> Grundsätzlich würde ich zustimmen, nicht einen so angehangenen
> Microcontroller zu verwenden, aber der F103 ist mittlerweile in so
> dermaßen vielen Produkten enthalten, dass ST einen Teufel tun wird, ihn
> in der nächsten Zeit abzukündigen.

Ich sehe den als 32bit Pendant zum ATmega328, dem werden wir auch noch 
lange begegnen.

Mw E. schrieb:
> und fährt
> über Erkner.

Immer noch besser als über die A10 ;-)

Bernd K. schrieb:
> Die STM32 sind in ihrer Klasse die kompliziertesten und verknotetsten
> ARMe die die Menschheit je gesehen hat

Das nenne ich ein Gerücht! STM hat hervorragende Dokumentationen, mit 
denen selbst die hardwarenahe Programmierung der Peripherie eine 
Kleinigkeit ist (Ausnahmen naturgemäß USB und Ethernet)! Hatte ich mir 
bei einem simplen Atmel M0+ so manches Mal sonst etwas aufgerissen, da 
miserable Doku, so habe ich die Peripherie eines deutlich komplexeren 
STM M4 mit Leichtigkeit programmiert. Auf Codedschungel wie CMSIS, ASF 
o.ä. verzichte ich generell, bei STM kein Problem, da ich die Controller 
aufgrund der guten Doku für transparent halte!

Bernd K. schrieb:
> Das ändert nicht die unsägliche Verknotung der Hardwarregister.

Das hast du schon 1000 gefühlte Male gesagt, ohne daß irgend jemand es 
verstanden hätte. Also bring mal ein Beispiel, an dem wir sehen können, 
was du meinst.


Ich - aus meiner Sicht -  kann da konkret werden:

1. Es gibt bei den STM32 einige Chips, die kombinierte SPI/I2S 
Peripherie-Cores enthalten. Aber diese Cores sind schlichtweg 16 bittig 
und haben keinerlei Fifo. Was das für den I2S-Betrieb bedeutet, kann man 
sich ausmalen. Da ist man zwingend auf DMA als eine Art 
Transmissionsriemen angewiesen - mit all deren Nachteilen, weil es nur 
"universelle" DMA gibt. Hätten die Cores mit höherem Datenaufkommen 
einen passend großen Fifo oder eben selbst DMA-Fähigkeit, dann wäre 
alles gut.

2. Der USB-Core gerade im STM32F103 ist - gelinde gesagt - ein bissel 
eigentümlich. Status setzen per XOR, kein schaltbares NAK_BI und so 
weiter.

So, und nun bist du dran mit konkreten Beispielen.

W.S.

W.S. schrieb:
> Der USB-Core gerade im STM32F103 ist - gelinde gesagt - ein bissel
> eigentümlich.

ST scheint jedoch zu mögen, denn in der Nachfolge-Serie STM32F303 und 
auch in den neuen STM32L0 ist der gleiche USB-Core drin.

Stefan F. schrieb:
> ST scheint jedoch zu mögen..

Ja, ist klar. Man kommt ja auch so einigermaßen damit zurecht.
Könnte dennoch weitaus schöner sein.

Aber ich schätze, wenn eine Firma erstmal einen Core teuer eingekauft 
hat, dann will sie den auch benutzen. Ich sehe da durchaus einige Dinge 
bei den STM32, die mir nicht wirklich gefallen, aber ich bin durchaus 
nicht bereit, da von "unsäglich verknotet" und dergleichen zu schreiben 
oder gar ausfällig zu werden.

Und es ist eigentlich auch schnurz, daß gerade die derzeit billigen 
STM32F103C8T6 schon ein paar Jahre auf dem Buckel haben. Der Preis ist 
auch ein Argument. Ich hatte das vor Jahren schon mal: vom PIC16 nach 
LPC2101 gewechselt, weil dieser inzwischen billiger geworden ist - 
selbst wenn man die 2 Regler (3.3V, 1.8V) dazu kalkuliert. Sachlich 
waren die LPC's sinnlos überdimensioniert. Ich halte aber auch garnichts 
davon, ständig nur auf höher, schneller, weiter und mehr Bässe zu 
schielen und auf alles Andere zu spucken.

W.S.


ps:
Mw E. schrieb:
> Hast du inzwischen..

Warum lernst du nicht einfach mal, dich anständig zu benehmen?
Ist das heutzutage nicht mehr üblich?

Über ein USB-Kabel sollen digitale Audiodaten in 8 Analogsignale
umgewandelt werden für Tontechnik. Ich weiss nicht wie
Tontechnikhersteller (ala Behringer) das machen. Deswegen war hier ja
meine Frage ... Kann man hier auf STM zugreifen oder muss was anderes
her? Einen Treiber schreiben für USB muss man ja auch noch...

Normalerweise beziehe ich mich von Aliexpress, aber da scheinen die
STM32 Entwicklerboards nicht auf dem Markt zu existieren. Mögen die
Chinesen STM32 nicht so?

Ok vielen Dank. Was tun wenn ich kommerziell anwenden will?

Ki-Lov schrieb:
> Ok vielen Dank. Was tun wenn ich kommerziell anwenden will?

Es gibt von Olimex Boards, die den Nucleos ähnlich sind.

Martin L. schrieb:
> Stand bei Audio-Verarbeitung heute ist mindestens 24 Bit und 96 bzw. 192
> kHz. Das geht mit keinem Controller mit Bordmitteln, da benötigt es
> einen externen D-A-Wandler.
> Eine parametrische Suche bei einem beliebigen Distributor (Mouser,
> DigiKey,...) liefert dann eine Auswahl. DigiKey z.B. listet 9
> verschiedene D-A-Wandler mit 8 Kanälen und mindestens 24 Bit. Diese
> Auswahl kann man auf zusätzliche "Wünsche" (Interface zum Controller,
> Gehäusebauform,...) durchsuchen.

Mit USB-Anschluss?

Wenn ich jetzt das hier nehme: 
https://www.mouser.de/datasheet/2/76/CS4382A_F2-1141976.pdf  192 kHz 
8-Channel D/A Converter

Seite 19: TYPICAL CONNECTION DIAGRAM

Muss ich einfach den Schaltplan nach diesem Diagram übernehmen und dann 
schauen wo ich ein Mikrokontroller herbekomme der über USB-Datenstream 
in digital 8 Kanäle PCM Audio ausgibt?

Vielleicht wäre es für mich einfacher STM32G4 zu nehmen.

Gibt es Anleitungen dazu wie ich grundsätzlich auf STM32G4 Audiodaten 
aus einem DAW-Programm über USB in Analog umwandeln kann?

24 Bit mögen ja auf der ADC-Seite begrenzt Sinn machen (um mit zu 
niedrig ausgepegelten Aufnahmen noch was anfangen zu können), aber im 
DAC ist das ja völlig absurd. Da steckt von der Hörschwelle bis zum 
(recht nahen) Jetantrieb alles drin. Das muss man erst mal wieder in 
Schall gewandelt kriegen!

Naja, ich muss dann halt wissen was ich genau lernen muss um das zu 
verwirklichen.



Ablaufplan:

1. USB-Kabel rein in den PC
2. DAW-Programme erkennen das als 8x Audio-Output die auswählbar sind


DAW-Programm -> USB -> USB-Schnittstelle -> Mikrokontroller -> 8 Kanal 
DAW-Chip -> 8x Audioverstärker mit Regler

Audioverstärker mit Regler kann man fertig kaufen in Modulen, das mache 
ich
 nicht selber



Wo fange ich zum lernen an?