mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Welcher ARM-Prozessor als Anfänger ?


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.
Autor: einsteiger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

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

- möglichst geringer Energieverbrauch, low-Power Modes
- kostenlose Entwicklungsumgebung mit C-Compiler
- verschiedene Schnittstellen, ADC, DAC, DSP
- lange Verfügbarkeit, ev. auch Portierungsmöglichkeiten auf 
Nachfolgemodell
- geeignet für eigenes Platinendesign oder oder kompakte Module 
verfügbar

Was wären aus Eurer sicht noch wichtige Aspekte für die Auswahl ?
Wie ist die MSP432-Familie zu bewerten ?

Autor: pegel (Gast)
Datum:

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

Autor: Harry L. (mysth)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert

Autor: RISC-V (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
einsteiger schrieb:

> - verschiedene Schnittstellen, ADC, DAC, DSP

DSP?

Autor: Weg mit dem Troll (Gast)
Datum:

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

Autor: Christoph db1uq K. (christoph_kessler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Beitrag "ARM-Assembler-Tutorial"

Ich habe mir den Nucleo...446 gekauft, für 17,99€ bei Conrad kann man 
wenig falsch machen. Mir kommt es speziell auf die DSP-Fähigkeiten an. 
Das ist keine Schnittstelle, sondern es gibt spezielle Assemblerbefehle 
die dafür geeignet sind, digitale Filter zu programmieren

Autor: Curby23523 N. (nils_h494)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
STM32F0 oder STM32G0 z.B. STM32F030C8T6TR

Autor: Olaf (Gast)
Datum:

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

Autor: udok (Gast)
Datum:

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

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
Curby23523 N. schrieb:
> STM32

Er hat Anfänger gesagt!

Die STM32 sind in ihrer Klasse die kompliziertesten und verknotetsten 
ARMe die die Menschheit je gesehen hat, sie sind auch die primäre 
Ursache für den Mythos "ARM ist kompliziert" und man könne ohne HAL 
nicht arbeiten (und mit HAL auch nicht). Trotzdem werden sie überall 
irrational gehypet, vorwiegend von Leuten die noch nie was anderes als 
STM32 unter den Fingern gehabt haben.

Ich empfehle Freescale/NXP Kinetis, die sind spürbar weniger verwirrend 
und weniger anstrengend.

Autor: W.S. (Gast)
Datum:

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

Autor: W.S. (Gast)
Datum:

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

Autor: Random .. (thorstendb) Benutzerseite
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Ich finde die STM32 ohne HAL wesentlich einfacher als mit HAL :-)
Und es gibt wesentlich kompliziertere ARM basierte MCUs als STM. Hat man 
das Prinzip bei denen einmal verstanden sind sie eig. recht einfach - 
eine HAL braucht man nicht.

Ansonsten sollte man sich auch mal die SAM3 und neuere von Atmel 
anschauen.

Prinzipiell gilt für alle ARM basierten MCUs (wg. Stromsparen etc.):
1. Peripheral clocken, s. Clock Tree, z.B. APBxENR bei STM (ansonsten 
--> HardFault)
2. Peripheral und Interrupt(s) konfigurieren
3. Peripheral und Interrupt(s) einschalten

Es empfiehlt sich, die Fault Handler einzelnd auszukodieren, und beim 
Debuggen den Vector Catch zu aktivieren. Spart Zeit beim Debuggen und 
Breakpoints.
#include <core_cm3.h>

int main() 
{
  // Early Trap Faults when debugging (Hard Fault, ...)
  if(CoreDebug->DHCSR & (1 << CoreDebug_DHCSR_C_DEBUGEN_Pos)) {
    CoreDebug->DEMCR |= (1<<CoreDebug_DEMCR_VC_HARDERR_Pos) | 
                        (1<<CoreDebug_DEMCR_VC_INTERR_Pos)  | 
                        (1<<CoreDebug_DEMCR_VC_BUSERR_Pos)  | 
                        (1<<CoreDebug_DEMCR_VC_STATERR_Pos) | 
                        (1<<CoreDebug_DEMCR_VC_CHKERR_Pos)  | 
                        (1<<CoreDebug_DEMCR_VC_NOCPERR_Pos) | 
                        (1<<CoreDebug_DEMCR_VC_MMERR_Pos)   ;
  }

...
}

void HardFault_Handler(void)
{
 while(1);
}
...

Autor: Bauform B. (bauformb)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
W.S. schrieb:
> Und Langlebigkeit/Portierbarkeit ist definitiv DEIN Bier und nicht das
> eines Herstellers oder Chips.

Nicht ganz so. Für manche Chips verspricht der Hersteller 15 Jahre 
Lieferbarkeit, andere sind schon wieder abgekündigt, bevor sie beim 
Distributor auftauchen. Dazu gehört natürlich auch, dass du nicht gerade 
ein uraltes Teil wie den (hier) beliebten STM32F103 aussuchst.

Random .. schrieb:
 void HardFault_Handler(void)
{
 while(1);
}

Man darf auch sehr viel mehr als while(1) einbauen. Je nach verfügbarer 
Hardware braucht man evt. keinen Debugger weil man Fehlermeldungen, 
Register, Stack... im Klartext ausgibt. Oder zum Beispiel
Beitrag "ARM Cortex-M3/4/7 Faulthandler"

Autor: Alexxx (Gast)
Datum:

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

Autor: Random .. (thorstendb) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bauform B. schrieb:
> Random .. schrieb:
 
void HardFault_Handler(void)
{
  while(1);
}
> Man darf auch sehr viel mehr als while(1) einbauen.

Klar, in der richtigen Firmware ist noch einiges mehr drin. Auch dabei 
wird nochmal zwischen Debug und Release unterschieden sowie Log Ausgaben 
gemacht.
War ja nur ein Beispiel :-)

: Bearbeitet durch User
Autor: Harald (Gast)
Datum:

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

Autor: Random .. (thorstendb) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Ich würde von HAL und mbed etc. abraten, und mich mitten in das Register 
Abenteuer stürzen. Vor allem, wenn es erstmal ein Hobby sein soll.
Ne Lampe kriegt man recht einfach zum Blinken, von da geht es dann 
weiter.
Sachen wir CMSIS (Headerfile!) und Debugger (z.B. unterstützt MDK-ARM 
die STLinks auf den Demoboards) helfen (vgl. SystemViewer, "Datenblatt" 
im Debugger).
So lernt man von Anfang an die MCU kennen. Läuft mit der HAL was nicht, 
ist man oft aufgeschmissen.

Autor: Harald (Gast)
Datum:

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

Autor: W.S. (Gast)
Datum:

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

Autor: 900ss D. (900ss)
Datum:

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

Bernd K. schrieb:
> Ich empfehle Freescale/NXP Kinetis

Ich "empfinde" es genau umgekehrt :)

Aber empfehlen möchte ich keinen. Ich würde als Anfänger mit 'nem AVR 
anfangen. Wenn man das alles (inkl. Toolchain, Startup des uc u.s.w.) 
verstanden  hat, auf ARM wechseln. Aber danach war hier nicht gefragt :)

Die STM32 haben halt für Bastler den Vorteil, für ein paar € Boards zu 
bekommen. Oder man nimmt die Teensy ab 3.x aufwärts. Ist aber schon 
etwas teurer mit super Support. Und ist Freescale ;)

: Bearbeitet durch User
Autor: Stefan F. (stefanus)
Datum:

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

Autor: Lothar J. (black-bird)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nimm das Development Board mit dem EFM32 Pearl Gecko von Silabs, der 
entspricht genau Deinen Anforderungen.

Blackbird

Autor: Rainer V. (a_zip)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry, aber es treibt mich..."lieber ARM dran, als ab"
Viel Spass beim Softeln...
Rainer

Autor: Mw E. (Firma: fritzler-avr.de) (fritzler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Random .. schrieb:
> Es empfiehlt sich, die Fault Handler einzelnd auszukodieren, und beim
> Debuggen den Vector Catch zu aktivieren. Spart Zeit beim Debuggen und
> Breakpoints.

Bauform B. schrieb:
> Man darf auch sehr viel mehr als while(1) einbauen. Je nach verfügbarer
> Hardware braucht man evt. keinen Debugger weil man Fehlermeldungen,
> Register, Stack... im Klartext ausgibt. Oder zum Beispiel
> Beitrag "ARM Cortex-M3/4/7 Faulthandler"

Da wollt ich grade meine Faulthandler hier posten, aber wer ander war 
schneller. So gehts eben auch.

Wenn was unklar ist zu den Faulthandlern, dann in dem verlinkten Thread 
bitte posten und es wird Klarheit geschaffen.

Autor: flips (Gast)
Datum:

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

Autor: Florian (Gast)
Datum:

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

Autor: KI-Lover (Gast)
Datum:

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

Autor: Florian (Gast)
Datum:

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

Autor: KI-Lover (Gast)
Datum:

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

Autor: Florian (Gast)
Datum:

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

Autor: W.S. (Gast)
Datum:

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

Autor: Johannes S. (jojos)
Datum:

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

: Bearbeitet durch User
Autor: Mw E. (Firma: fritzler-avr.de) (fritzler)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Johannes S. schrieb:
> 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.

W.S. scheint nur alt und borniert zu sein.
Er erzählt ja wirklich immer das Gleiche und bekommt immer den gleichen 
Gegenwind von verschiedenen Usern inkl Mods.
Er tut so als wäre er der größte C Guru aller Zeiten und wills den 
Leuten aufdrücken.
Durch seine Magic Number Nutzung diskreditiert er sich aber selbst 
überhaubt mitreden zu dürfen bei Codestruktur.

@W.S:
Du merkst es wirklich nicht mehr in deinem Altersstarrsinn, dass du hier 
nurnoch nervst oder?

Autor: Johannes S. (jojos)
Datum:

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

: Bearbeitet durch User
Autor: Florian (Gast)
Datum:

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

Autor: Johannes S. (jojos)
Datum:

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

: Bearbeitet durch User
Autor: Bernd K. (prof7bit)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Florian schrieb:
> ich hab halt keine Lust jedes
> mal für einen neuen MCU auch noch Registerdefinitionen, Startercode,
> Linkerscripts und was nicht alles zu schreiben.

Keiner außer W.S. schreibt seine Registerdefinitionen selber. Selbst die 
hartgesottensten Low-Level Treiberschreiber, selbst die die selbst am 
eigenen Startup und am Linkerscript rumschrauben, nehmen für die 
Registerdefinitionen stets die von Hersteller gelieferten oder leiten 
sie sich in der ihnen genehmen Form automatisiert von der .svd Datei ab.

Nur W.S. ganz alleine auf diesem Planeten geht den nächsten und 
allerletzten Schritt (am Abgrund der Klippe) und schreibt alles komplett 
von Hand, schlechter strukturiert und fehlerbehaftet, aber dafür 
selbstgeschrieben.

Autor: m.n. (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Na und?
Willst Du ihm auch noch vorschreiben, was er zu essen hat?

Autor: kein gast (Gast)
Datum:

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

Autor: MaWin (Gast)
Datum:

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

Autor: W.S. (Gast)
Datum:

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

Autor: Bernd (Gast)
Datum:

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

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
W.S. schrieb:
> Da möchte man
> sich am liebsten den am besten passenden Chip aussuchen.

Am liebsten(!) bleibt man jahrelang beim gleichen Chip oder zumindest 
bei der gleichen Produktreihe eines Herstellers! Ansonsten steigt der 
Frustlevel bei Entwicklung neuer und Pflege alter Projekte irgendwann 
ins unermessliche und irgendwann kannst Du auf der Gebäudeseite wo die 
Entwicklungsabteilung sitzt keine Autos mehr parken weil dort regelmäßig 
Tische und Stühle durch die geschlossenen Fenster fliegen! Man darf dann 
nämlich bei jedem neuen Projekt (und auch bei jedem alten nach ein paar 
Jahren) erstmal wieder stundenlang völlig anders strukturierte 
Dokumentation wälzen um zu sehen ob und wie man jetzt bei diesem 
speziellen Exemplar zum Beispiel mal irgendwelche drei Timer mit 2 
unterschiedlichen Perioden auf ganz spezielle Weise miteinander 
synchronisieren kann (oder ob das überhaupt genau so geht oder nur 
irgendwie anders), wie man irgendeinen ganz speziellen PWM-Modus dort 
konfiguriert (oder ob der das überhaupt kann), wie dort der ADC mit dem 
DMA zusammenspielt und wie der getriggert werden kann oder ob man das 
ganze Konzept umkrempeln muss, und wenn man dann sicher ist daß man bei 
der langen Recherche nichts übersehen hat (hat man mit Sicherheit! Und 
zwar mindestens zwei "Kleinigkeiten" wie sich später leider 
herausstellen wird!) und nun mit dem neuen Chip loslegen will sich dann 
wieder mit ner komplett anderen HAL auseinandersetzen muss deren 
Erschaffer komplett anderes Kraut geraucht haben als die vom vorherigen 
Hersteller oder wenn man keine fertige HAL benutzt dann halt ersatzweise 
mit komplett anders aufgebauten Registern und anderer Funktionsweise, ob 
der verdammte Debugger den neuen Exoten überhaupt unterstützt oder ob 
man auch da noch ein paar Extrawürste einführen muß, ob man womöglich 
noch nen anderen Compiler braucht, oder ob einem gar der Hersteller noch 
ne weitere unnütze verbastelte Schrott-IDE zu seiner IDE-Sammlung 
hinzufügen will, etc.

Das ist alles so speziell (und zwar egal ob mit oder ohne HAL) und da 
kann (und muss!) man so viel Energie und Zeit reinstecken um sich mit 
der Hardware und den Libs eines Herstellers anzufreunden bis man 
wirklich ernsthafte Kunststücke damit zuwege bringt auf dem 
wettbewerbsfähigen Niveau das jeden Tag von einem erwartet wird daß man 
das nicht leichtherzig alle 6 Monate in den Wind schießt und wieder 
komplett bei 0 anfängt.

Autor: Florian (Gast)
Datum:

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

Autor: Johannes S. (jojos)
Datum:

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

Autor: Gretel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> wie ein Perry Rhodan Roman den man mal vor dem Schlafen lesen kann

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

Autor: Martin L. (maveric00)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Florian schrieb:
> 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 >:)

ST hat eine neue Reihe herausgebracht, die fast an die Anforderung 
kommt: Die STM32G4x3 haben bis zu 7 12-Bit DAC mit 15 MSamples/s. Die 
haben auch einige andere analoge Baugruppen integriert (7 Komparatoren, 
6 OpAmps), so dass man sich ggf. zusätzliche Beschaltung sparen kann.

Schöne Grüße,
Martin

Autor: Ingo L. (corrtexx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Martin L. schrieb:
> ST hat eine neue Reihe herausgebracht, die fast an die Anforderung
> kommt: Die STM32G4x3 haben bis zu 7 12-Bit DAC mit 15 MSamples/s.
Hoffentlich sind die besser als die ADC-Einheiten in den STM32F4, welche 
enorm durch die CPU gestört werden...

Autor: H. (Gast)
Datum:

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

Autor: Mw E. (Firma: fritzler-avr.de) (fritzler)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Martin L. schrieb:
> ST hat eine neue Reihe herausgebracht, die fast an die Anforderung
> kommt: Die STM32G4x3 haben bis zu 7 12-Bit DAC mit 15 MSamples/s.

Von denen aber nur 3 Kanäle außen abgreifbar sind und das sind auchnoch 
die langsamen mit 1MS/s.

7 x 12-bit DAC channels
– 3 x buffered external channels 1 MSPS
– 4 x unbuffered internal channels 15 MSPS

Die gehen dann zB an die Comparatoren, wär ja zu schön wenn die 
rausgeführt wären :/

Ingo L. schrieb:
> Martin L. schrieb:
>> ST hat eine neue Reihe herausgebracht, die fast an die Anforderung
>> kommt: Die STM32G4x3 haben bis zu 7 12-Bit DAC mit 15 MSamples/s.
> Hoffentlich sind die besser als die ADC-Einheiten in den STM32F4, welche
> enorm durch die CPU gestört werden...

Jetz vertausch mal nicht DAC mit ADC, da gibts nen kleinen aber feinen 
Unterschied ;)

: Bearbeitet durch User
Autor: Ingo L. (corrtexx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mw E. schrieb:
> Jetz vertausch mal nicht DAC mit ADC, da gibts nen kleinen aber feinen
> Unterschied ;)
In der Tat, zu eilig gelesen...

Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Bauform B. schrieb:
> Dazu gehört natürlich auch, dass du nicht gerade
> ein uraltes Teil wie den (hier) beliebten STM32F103 aussuchst.

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. Da werden eher andere (auch neuere) 
STM32-Derivate dran glauben müssen.

Auf Grund der wichtigen Bedeutung auf dem Markt ist ja GigaDevice recht 
spät eingestiegen, STM32-Clones auf den Markt zu bringen, z.B. DG32F103. 
Und mittlerweile haben die noch einmal nachgelegt und einfach den 
Cortex-M3 durch einen RISC-V ausgetauscht, trotz der mutmaßlich 
altmodischen Peripherie drumherum. Und so etwas macht man nicht, wenn 
der Markt zu erkennen gibt, dass er in Kürze keine STM32F1xx-kompatiblen 
Microcontroller mehr benötigt.

Im Gegensatz zu z.B. Smartphones gibt es dann nicht die ein bis drei 
Produkte, die 90-100% der Stückzahlen eines Prozessortyps darstellen, 
der mit Abkündigung des Smartphones ebenfalls gleich wieder vom Markt 
verschwindet, sondern eine Unzahl von Gerätetypen, von denen vielleicht 
nur ein oder zwei gerade einmal 1% der Stückzahlen ausmachen.

Atmel/Microchip war/ist ja auch so ein Hersteller, dessen Kunden aus 
Gewohnheit o.ä. jahrzehntelang auf manche teils sogar grottenschlechten 
Bauteile aufsetzen. Die auf den Arduinos verbauten AVR-Controller sind 
ja nun auch nicht unbedingt der heißeste Scheiß.

Fazit:
Der STM32F103 hat ähnlich wie ein ATmega8 einen ähnlichen Kultstatus 
erreicht wie zuvor der 8051, der ja auch immer noch von einigen 
Hersteller gebaut wird.

Nichtsdestotrotz ist es für einen Einsteiger vermutlich sinnvoll, mit 
einem der aktuellen Super-Low-Cost-Board mit irgendeinem STM32Lxx, 
LPCxxxx oder Kinetis herumzuspielen. Der Spaß kostet auch maximal 30 
Euro oder sogar noch viel weniger.

Als Anfänger jedoch gleich die eierlegende Wollmilchsau zu fordern und 
dabei auch noch schwierig zu erfüllenden nichttechnischen Anforderungen 
aufzustellen, schießt ziemlich über das Ziel hinaus. So etwas produziert 
dann einfach nur Komplexität und treibt die Kosten hoch. Man kann 
natürlich zu den Halbleiter- und Boardherstellern hingehen und eine 
Lieferbarkeit von 30 Jahren fordern. Womöglich bekommt man dafür dann 
sogar ein Angebot. Darin sind dann aber auch schon die Kosten 
eingepreist, die entstehen, wenn in 11 Jahren der letzte Wafer 
hergestellt und dann bei Unternehmen wie Rochester für die folgenden 19 
Jahre eingelagert wird.

Autor: Stefan F. (stefanus)
Datum:

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

Autor: Mw E. (Firma: fritzler-avr.de) (fritzler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oh ich seh im Refman grade, dass die internen Opamps (15MHz Bandbreite) 
das interne DAC Signal als input nehmen können, das geht dann auf VIN+.
Den Opamp als Spannungsfolger schalten und schon kommts am OPAMP VOUT 
Pin raus.
Also gehts doch, das war im Datenblatt nur so nicht ersichtlich.

Das is aber so als würde man von Rom nach Paris fahren wollen und fährt 
über Erkner.

Autor: m.n. (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Mw E. schrieb:
> und fährt
> über Erkner.

Immer noch besser als über die A10 ;-)

Autor: Mw E. (Firma: fritzler-avr.de) (fritzler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn schon trollen dann bitte mit etwas Resthirn.
Abfahrt 6 A10 -> Erkner.

Und jetz schleich dich.

Beitrag #6027251 wurde von einem Moderator gelöscht.
Autor: Drosius Ingolf (Gast)
Datum:

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

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Drosius Ingolf schrieb:
> Das nenne ich ein Gerücht! STM hat hervorragende Dokumentationen,

Das ändert nicht die unsägliche Verknotung der Hardwarregister. Das 
fällt Dir aber vermutlich erst wirklich auf (dann aber umso stärker) 
wenn Du mal ne Zeit lang vergleichsweise mit was anderem als STM32 
gearbeitet hast.

Autor: Andi B. (andi_b2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wer lange genug in diesem Bereich tätig ist, versucht um ST eher einen 
Bogen zu machen. Die Langzeiterfahrung zeugt halt viel zu oft von 
mangelnder Qualität. Das kann sich ja mittlerweile gebessert haben nach 
der 1000sten Umstrukturierung, muss aber nicht.

Autor: W.S. (Gast)
Datum:

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

Autor: Georg M. (g_m)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
> Welcher ARM-Prozessor als Anfänger ?

Kinder beginnen mit dem nRF51822.

Autor: Mw E. (Firma: fritzler-avr.de) (fritzler)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
W.S. schrieb:
> 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.

Hast du inzwischen auch schon Alzheimer zu deinem Starrsinn?
Bernd hat jetzt schon öfter Beispiele genannt als ich mal nett 
nachfragte.
Diese hatte er dir auch schon genannt.

W.S. schrieb:
> 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.

Du zeigst mal wieder, dass du keine Ahnung hast aber mitreden willst.
Netzwerk und USB OTG HS haben zB einen eigenen DMA und eine eigene FIFO.
SDIO, Camera Interface und USB OTG FS haben eine eigene FIFO.
Der LCD-TFT ist auch sein eigener Busmaster.
In den H7 gibts einen SDIO als Busmaster, also eigener DMA.
Für I2S mit FIFO gibts übrigens die SAI.
-> Es kann also nicht die Rede sein von "Hätten die Cores mit höherem 
Datenaufkommen einen passend großen Fifo"
Die gibts nämlich, du weist es nur mal wieder nicht aber tust so als 
hätteste die Weisheit mit Löffeln gefressen und nur deine Weisheit 
zählt.

Ein I2S hat keine hohen Datenraten, selbst bei 96kHz bei 24Bit nicht.

Autor: Stefan F. (stefanus)
Datum:

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

Autor: W.S. (Gast)
Datum:

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

Beitrag #6030104 wurde vom Autor gelöscht.
Autor: Ki-Lov (Gast)
Datum:

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

Autor: Mw E. (Firma: fritzler-avr.de) (fritzler)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
W.S. schrieb:
> ps:
> Mw E. schrieb:
>> Hast du inzwischen..
>
> Warum lernst du nicht einfach mal, dich anständig zu benehmen?
> Ist das heutzutage nicht mehr üblich?

Wann lernst du mal hier nicht weiter im Forum zu nerven mit deinen 
kruden Ansichten? Im Projekte und Code Unterforum zerredest du ja 
schonwieder das nächste Projekt obwohl dir bereits ein Mod DEUTLICHST 
gesagt hat was er davon hält.
Ich hab dir aufgezeigt wie extrem falsch deine Aussage weiter oben ist.
Da sowas wiederholt und vehement von dir kommt fällt der Ton 
dementsprechend aus!
Kurze Zusammenfassung: DU Bist das Problem und nicht der Gegenwind hier 
im Forum (ich bin ja nicht der einzige).

: Bearbeitet durch User
Autor: Alex D. (daum)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ki-Lov schrieb:
> 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?

Beim chinesen gibt es hauptsächlich boards mit STM32F103 und STM32F407.

Wenn das Projekt nicht kommerziell wird, dann ist wohl ein Nucleo board 
die beste lösung, gibts auch bei "normalen" (nicht chinesischen) 
Händlern (z.B. Mouser, digikey, etc.). Bei den STM32G4 gäbe es das 
NUCLEO-G474RE (hat 7 DACs).

Beitrag #6030500 wurde vom Autor gelöscht.
Autor: Ki-Lov (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok vielen Dank. Was tun wenn ich kommerziell anwenden will?

Autor: Christopher J. (christopher_j23)
Datum:

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

Ein eigenes Board designen? Die Schaltpläne für die Nucleos und 
Discovery-Boards sind frei verfügbar.

Autor: Martin L. (maveric00)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Ki-Lov schrieb:
> Ü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?

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.

Um aus den Komponenten allerdings tatsächlich ein Audio-Gerät mit 
erträglichem Klang zu bauen benötigt es noch viel mehr - zum Beispiel 
eine gescheite Stromversorgung mit getrennten Zweigen für Analog- und 
Digitalteil, vernünftige Analog-Ausgangsbeschaltung und das passende 
Platinen-Layout. Sonst hörst Du die Daten Deiner USB-Schnittstelle ohne 
Wandlung direkt.

Wenn daraus kein kommerzielles Projekt werden soll, ist der Kauf eines 
Behringer-Produktes (o.ä.) vermutlich günstiger (und liefert bessere 
Qualität). Sollte es kein zu Deinen USB-Daten kompatibles 
Audio-Interface geben, dürfte es einfacher sein, ein Zwischengerät mit 
zwei USB-Anschlüssen zu bauen, welches die Daten dann passend umformt.

Wenn das Projekt allerdings zum Produkt werden soll benötigst Du 
wesentlich mehr Know-How als Du Dir hier im Forum aneignen kannst, denn 
Deine Frage verleitet zu der Annahme, dass Du Dich noch nicht intensiv 
mit der Materie beschäftigt hast.

Schöne Grüße,
Martin

Autor: Stefan F. (stefanus)
Datum:

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

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

Autor: Ki-Lov (Gast)
Datum:

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

Autor: Ki-Lov (Gast)
Datum:

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

Autor: Martin L. (maveric00)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Ki-Lov schrieb:
> 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?

Nein, diese D-A-Wandler sind dafür gedacht, an einen Controller oder ein 
CODEC / Decoder angeschlossen zu werden. Entsprechend benutzen sie 
Low-Level Interfaces (i2s, serial interfaces,...).

Ich kenne kein IC, welches generell USB Audio auf 8 Kanäle ausgeben 
würde - das liegt unter anderem daran, dass der USB Audio Standard 
extrem viele unterschiedliche Elemente enthält und damit ein 
"generischer" USB-Audio-Wandler kaum möglich scheint.

Schöne Grüße,
Martin

Autor: Ki-Lov (Gast)
Datum:

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

Autor: rµ (Gast)
Datum:

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

Autor: Rainer V. (a_zip)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also nichts für Ungut, aber wenn das wirklich "kommerziell" werden soll, 
dann melde ich mal erhebliche Zweifel an den Fähigkeiten des TO an. 
Selbst für ein ambitioniertes Bastelprojekt fehlen dem TO n.m.M massiv 
Kenntnisse, zumindest den bisherigen Äußerungen nach zu urteilen. So 
oder so kann ich nur empfehen, das Projekt in möglichst kleine 
Teilprojekte aufzuteilen und dann eins nach dem Anderen zu entwickeln. 
Trotzdem (hoffentlich) viel Spass! Und ja, ich weiß, kaum ein Chef der 
Welt hält Spass bei der Arbeit für ein Kriterium, aber dennoch :-)
Gruß Rainer

Autor: Ki-Lov (Gast)
Datum:

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

Autor: Christopher J. (christopher_j23)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Ki-Lov schrieb:
> Naja, ich muss dann halt wissen was ich genau lernen muss um das zu
> verwirklichen.

Falls du der TO bist, solltest du dir auch mal die Forenregeln 
durchlesen, vor allem die Regel bezüglich der Anzahl an Nicknamen

Autor: Rainer V. (a_zip)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christopher J. schrieb:
> Falls du der TO bist, solltest du dir auch mal die Forenregeln
> durchlesen, vor allem die Regel bezüglich der Anzahl an Nicknamen

Hab auch gerade erst gemerkt, dass sich das Thema hier schwer verändert 
hat! Also alles zurück auf Los :-)
Gruß Rainer

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.