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 ?
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.
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.
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
> 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.
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.
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.
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.
1 | #include <core_cm3.h> |
2 | |
3 | int main() |
4 | {
|
5 | // Early Trap Faults when debugging (Hard Fault, ...)
|
6 | if(CoreDebug->DHCSR & (1 << CoreDebug_DHCSR_C_DEBUGEN_Pos)) { |
7 | CoreDebug->DEMCR |= (1<<CoreDebug_DEMCR_VC_HARDERR_Pos) | |
8 | (1<<CoreDebug_DEMCR_VC_INTERR_Pos) | |
9 | (1<<CoreDebug_DEMCR_VC_BUSERR_Pos) | |
10 | (1<<CoreDebug_DEMCR_VC_STATERR_Pos) | |
11 | (1<<CoreDebug_DEMCR_VC_CHKERR_Pos) | |
12 | (1<<CoreDebug_DEMCR_VC_NOCPERR_Pos) | |
13 | (1<<CoreDebug_DEMCR_VC_MMERR_Pos) ; |
14 | }
|
15 | |
16 | ...
|
17 | }
|
18 | |
19 | void HardFault_Handler(void) |
20 | {
|
21 | while(1); |
22 | }
|
23 | ...
|
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:
1 | void HardFault_Handler(void) |
2 | {
|
3 | while(1); |
4 | }
|
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"
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.
Bauform B. schrieb: > Random .. schrieb:
1 | |
2 | void HardFault_Handler(void) |
3 | {
|
4 | while(1); |
5 | }
|
> 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
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.
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.
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.
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
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
Nimm das Development Board mit dem EFM32 Pearl Gecko von Silabs, der entspricht genau Deinen Anforderungen. Blackbird
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.
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.
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?
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.
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.
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.
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.
>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.
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
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...
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.
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
Mw E. schrieb: > Jetz vertausch mal nicht DAC mit ADC, da gibts nen kleinen aber feinen > Unterschied ;) In der Tat, zu eilig gelesen...
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.
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.
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.
Wenn schon trollen dann bitte mit etwas Resthirn. Abfahrt 6 A10 -> Erkner. Und jetz schleich dich.
Beitrag #6027251 wurde von einem Moderator gelöscht.
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!
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.
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.
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.
Angehängte Dateien:
-
nRF51822_BLE_Calliope.jpg
120 KB
> Welcher ARM-Prozessor als Anfänger ?
Kinder beginnen mit dem nRF51822.
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.
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?
Beitrag #6030104 wurde vom Autor gelöscht.
Ü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?
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
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.
Ok vielen Dank. Was tun wenn ich kommerziell anwenden will?
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.
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
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?
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
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!
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
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?
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
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.