Hallo! (Die eigentliche Frage steht ganz unten) Nach vielen Jahren melde ich mich wieder. Ich habe ein kleines Raspberry-Pi-Projekt und bin genervt von sporadischen Aussetzern. Da habe ich verklärt an die schöne alte Zeit zurückgedacht und gedacht "Mit einem Mikrocontroller weiß ich wenigstens was passiert. Takt für Takt." Inzwischen hat Arduino ja eine ziemliche Erfolgsgeschichte hingelegt. Aber wenn ich ein bisschen in den Code schaue, schaudert es mir. Pin-Konfiguration im RAM, die dann bei jedem Zugriff zur Laufzeit ausgewertet wird? Oje! Der Blick in einige der tollen Arduino-Libraries (in dem Fall von Adafruit) sprach auch nicht gerade von Qualität. Geht zwar, aber 6 von 7 Schritten aus dem Datenblatt einfach weggelassen. Sicher gibt es auch Qualität. Aber die zu suchen macht sicher weniger Spaß als sie selbst zu schreiben. Die Entscheidung stand fest: Ich möchte möglichst "bare metal" programmieren. Also, ein Bootloader soll schon dabei sein. Aber dass mit heimlich, wie bei Arduino Interruptroutinen untergeschoben werden, das möchte ich nicht. Inzwischen gibt es ja auch richtig schön schnelle Chips. Da könnte ich vielleicht sogar I2S nehmen, statt mit komprimierten Musikdaten zu arbeiten. Ich habe mir das Datenblatt des Freescale ARM Cortex-M4 angeschaut (Teensy 3.6). Aber das war mir dann doch ein bisschen zu hardcore. Tausende Register setzen, damit man etwas initialisiert kriegt. Selber die Takte routen, selber den Speicherplatz aufteilen. Nein, da war die Zeit mit den ATmegas doch einfacher. Oder verkläre ich da die Vergangenheit? Oder bin ich beim ARM ins falsche Kapitel gerutscht? Gut, man könnte sagen, dass man mit diesen schnellen Prozessoren den ganzen Arduino-Overhead wieder wettmacht. Und irgendwie klingt es ja auch verlockend, einfach eine FAT-Library oder eine USB-Library nutzen zu können. Aber dann hab ich ja doch wieder die Unsicherheit, dass bei all dem Code, der da gleichzeitig läuft, sich das Projekt im entscheidenden Moment verschluckt. Und irgendwie hat es auch mehr Spaß gemacht, den SPI-Bus in Hardware umschaltbar zu bauen (so dass die SD-Karte die Daten direkt in den MP3-Decoder-Chip schieben kann und man sich den Puffer spart) als im Arduino ein a = FAT-Library.read und ein MP3-Chip-Library.write(a) aufzurufen. Genug Nostalgie. Schauen wir in die Zukunft. Nun, ich erinnerte mich auch an mikrocontroller.net. Habe damals viel gelernt, allein durchs lesen von alten Diskussionen. Jetzt dachte ich, frag ich mal Euch! Welchen Chip (welches Board) würdet Ihr mir heute empfehlen? Ich würde mir einen wünschen, der schnell genug für I2S ist, den ich möglichst "bare metal" programmieren kann (zumindest so dass alles zur Laufzeit deterministisch und unter meiner Kontrolle ist), der nicht übermäßig komplex ist und für den es eine gut gepflegte Toolchain gibt. Vielen Dank!
Mir fallen da im Moment die STM32F4xx ein mit mehreren I2S/SPI Bussen und genügend Rechenleistung für MP3 Dekodierung und USB Host Unterstützung. Die Sache mit der Toolchain sollte sich nach einigem Durcheinander inzwischen auch geklärt haben - z.B. Eclipse und TrueStudio sollten sich noch eine Weile halten.
:
Bearbeitet durch User
M. H. schrieb: > Selber die Takte routen, selber den Speicherplatz aufteilen. Kann man natürlich auch machen lassen. So ziemlich jeder Hersteller von ARM-Derivaten hat dafür was im Programm, HAL, ASF und wie die Dinger alle heißen. Allerdings entfernst du dich damit natürlich von diesem Anspruch: > zumindest so dass alles zur Laufzeit deterministisch und unter meiner > Kontrolle ist Deterministisch ist es natürlich, aber diese Zwischenschichten, die dir die komplexere Initialisierung und dergleichen Dinge abnehmen möchten, hast du natürlich nicht mehr unter deiner Kontrolle. Yep, so ein ARM ist in der Tat komplexer als ein ATmega. Es gibt auch kleinere, Cortex-M0 oder Cortex-M0plus-basiert, die sind in der Komplexität dann irgendwo zwischen einem Xmega und den größeren Cortex-M3/M4- (und mittlerweile -M7) Boliden. Gut gepflegte Toolchain für ARM gibt es dahingehend, dass ARM Ltd. selbst (meines Wissens) sich in den GCC mit einbringt. Dadurch hast du den eigentlich immer erstmal als Compiler zur Hand. Bibliothek ist üblicherweise in diesem Umfeld die newlib. Ist insgesamt ein wenig „unixoider“ als die avr-libc, da sie aus Einzelteilen stammt, die wiederum selbst aus dem Unix-Umfeld kommen. So geht ein malloc() dann eben auf eine Funktion _sbrk(), die vom „System“ einen Speicherblock anfordert. Gerde die kleinen Cortexe sind durchaus noch „bare metal“ beherrschbar. Zwischen einem AT90S1200 und einem ATxmegaD lagen in der Dicke des Handbuchs auch schon mehr als eine Größenordnung ;-), die ARMs sind dann gar nicht mehr so üppig viel dicker geworden im Vergleich.
M. H. schrieb: > Welchen Chip (welches Board) würdet Ihr mir heute empfehlen? M16C. Ist im Prinzip ein 68000 Prozessor nur als uC mit 100 Pins. Schnell, in C programmierbar, IDE ist von Visual Studio, und bare metal, also keine Libnraries von Kleinkindern, sondern du darfst alles selbst programmieren. Er führt Instruktionen ohne cache und ohne Pipelining aus, also kann man noch Takte zählen. Fertige Boards von glyn.de https://www.renesas.com/en-eu/products/software-tools/boards-and-kits/renesas-starter-kits/renesas-starter-kit-for-m16c-65.html Nachteile: Datenrichtung nur Portweise schaltbar ausser es sind Sonderfunktionen, Ports nur mit 2mA belastbar, es gibt keine deutschsprachige Gemeinde von der man Code schnorren kann. Vorteile: Echte DACs on chip, genug Speicher, PWM Timer gut für 3 Phasen BLDC.
Michael B. schrieb: > M16C Aber auch schon gut in die Jahre gekommen und relativ teuer geworden. Ich habe den in 3 Designs in verschiedenen Varianten drinnen, kleine Stückzahlen. Da kostet der 20€/Stk. War mal die low-power-Variante schlechthin bei rel. viel Rechenleistung. Ein L4 schlägt den um Längen. Für neue Sachen setze ich den nicht mehr ein.
Schau Dir mal den NRF51 von NordicSemi an, wie er z.B. auf dem micro:bit drauf ist. Abgesehen von den Radio-Sachen für Blueooth Low Energy ist das ein vergleichweise übersichtlich aufgebauter Chip.
Jim M. schrieb: > Abgesehen von den Radio-Sachen für Blueooth Low Energy ist das ein > vergleichweise übersichtlich aufgebauter Chip. … wie andere Cortex-M0s auch. ;-) Warum willst du ihm eine auf HF-Protokolle spezialisierte Hardware aufdrängeln (wobei man den HF-Teil praktisch nicht mehr bare metal programmieren kann, weil die Lebenszeit dafür nicht ausreicht), wenn er eigentlich nur einen CM0 (oder CM0+) sucht?
Ich kann die STM32 empfehlen. Die programmiere ich stets bare-metal, bis auf die #defines und typedef Sachen werfe ich alles raus, was mit HAL zu tun hat. Der Chip den ich aktuell verwende hat nen Cortex-M4F, ist also durchaus komplexer. Kann man aber noch selbst alles machen. Natürlich, du musst einiges an Zeit reinstecken, aber es ist machbar.
Johannes O. schrieb: > Ich kann die STM32 empfehlen. Ich finde auch nach nun etwas längerer Beschäftigung mit denen deren Peripherals nicht so sonderlich toll geraten. Externinterrupts, die man quer über die Ports splitten muss, weitgehend nur 16-bit-Peripherie, ein SPI, bei dem man unbedingt alle Werte rücklesen muss (obwohl man bei SPI praktisch immer erstmal welche hat, die man gar nicht haben will). Allerdings haben sie verdammt viel Peripherie reingestopft in die Dinger, alles ist x-mal vorhanden. Bare-metal-programmierbar sind sie allerdings in der Tat.
M. H. schrieb: > Gut, man könnte sagen, dass man mit diesen schnellen Prozessoren den > ganzen Arduino-Overhead wieder wettmacht. Und irgendwie klingt es ja > auch verlockend, einfach eine FAT-Library oder eine USB-Library nutzen > zu können. Aber dann hab ich ja doch wieder die Unsicherheit, dass bei > all dem Code, der da gleichzeitig läuft, sich das Projekt im > entscheidenden Moment verschluckt. Durchaus. Aber man muss auch bei der Softwareentwicklung ökonomisch denken: Wenn die Software nicht beweisbar fehlerfrei sein muss, dann nutzt man sinnvollerweise die bereits vorhandenen (und bewährten) Bibliotheken. Oder den Matlab-Codegenerator... Das spart Zeit und des Kunden Geld. Alles-selber-machen ist ein schönes Ziel, das einem aber nur seltenst bezahlt wird.
M. H. schrieb: > Ich habe ein kleines Raspberry-Pi-Projekt und > bin genervt von sporadischen Aussetzern Du brauchst nur die Raspbian SD-Karte entfernen und eine RiscOS pico SD-Karte einlegen schon gibt es auf dem Pi Zero oder A+ us Genauigkeit. Man muss sich aber umgewöhnen: Entweder Entwicklung in C auf einem Pi mit RiscOS Desktop und das Binary per Nullmodem-Kabel auf das Pi mit RiscOS pico rüberschieben. Oder auf dem Pi mit RiscOS pico mit vi ähnlichem Steinzeit-Editor basteln. Übrigens auch in BASIC gibt es unter RiscOS pico keine Aussetzer: https://www.youtube.com/watch?v=wLRQ4UNKeZw https://www.riscosopen.org/content/downloads/raspberry-pi
Vielen Dank. Da habe ich schon mal eine ganze Menge Stoff zu lesen. Eine kleine Klarstellung noch: Wenn ich schrieb "bare metal", dann meinte ich hier nicht unbedingt, dass ich auf Librarys des Herstellers verzichten will. Sie müssen nur qualitativ hochwertig sein und müssen klip und klar sagen, wenn und was sie mit Timern machen. (Ich hab die Nase voll vom Raspberry-Pi-Linux, wo Dinge von Hand gestartet funktionieren, aber nicht im Start-Script. Und wo man dann im Forum die Tipps bekommt, doch einfach im Start-Script 3 Sekunden zu warten. Im entscheidenden Moment reichen dann zufällig auch die 3 Sekunden nicht – egal wie oft man zuvor getestet hat.) Wer noch Tipps hat, die neben dem Chip auch die Toolchain (Editieren, Compilieren, Hochladen) und ggf. ein Board empfehlen, immer her damit.
M. H. schrieb: > und ggf. ein Board empfehlen Es gibt bei ST einige Boards mit den STM32, aber man muss sich entscheiden, ob man onboard Peripherie haben will (Discovery Boards) oder eher nur den puren MC (Nucleo Boards). Wenn du mit Audio experimentieren willst, ist z.B. das STM32F4 Discovery nicht so schlecht. Da ist ein DAC schon drauf und es gibt noch einen freien I2S Bus. Allerdings nicht viel RAM. Mit Bildschirm und 8MB SDRAM gibts das STM32F429 Discovery, aber da sind so gut wie keine Pins mehr frei, um was dazu zu bauen. Als Toolchain würde ich heute vermutlich wieder zu Atollics TrueStudio wechseln, wenn mein altes Coocox hier nicht alles bieten würde, was ich derzeit brauche. Coocox ist tot, Atollic hat mal eine zeitlang Geld gekostet, nun aber nicht mehr.
:
Bearbeitet durch User
M. H. schrieb: > Ich hab die > Nase voll vom Raspberry-Pi-Linux, wo Dinge von Hand gestartet > funktionieren, aber nicht im Start-Script. Und wo man dann im Forum die > Tipps bekommt, doch einfach im Start-Script 3 Sekunden zu warten. Im > entscheidenden Moment reichen dann zufällig auch die 3 Sekunden nicht – > egal wie oft man zuvor getestet hat. Das ist Debian basiert. Eines der stabilsten Linuxe. Start Scripts sind Linux und sind nichts Pi-spezifisches. Wenn es Abhängigkeiten gibt, dann kann man diese auch definieren. Die Qualität der Antworten im Forum ist recht durchwachsen. Sowas würde ich daher ggf. in einem Debian Forum erfragen. Was genau war denn das Problem und wie passt der Pi in deine Anforderungen?
Sehr elegant sind µCs von Renesas. Beispiele dafür sind H8SX und RX Prozessoren. Sie sind intern gut strukturiert. Verpackt sind sie in Gehäusen, wo die Pins eines Ports direkt nebeneinander herausgeführt sind, was ideal fürs Layout ist. Zum Einstieg sieh Dir vielleicht das Datenblatt des kleinen RX210 an. Den ADC mal außen vor gelassen, sind beim 100-pol. Gehäuse nur 2 x VCC und 2 x VSS Anschlüsse zu verdrahten; das Layout wird damit sehr einfach. Die größeren Brüder heißen dann RX610, RX62, RX63, RX64 und RX71, was richtige Edelprozessoren sind ;-) Aktuell ist jetzt das E2Studio, was mir nicht zusagt. Meine Projekte habe ich alle mit HEW erledigt, was mir sehr gut gefallen hat. Renesas ist hier nicht sonderlich bekannt, was daran liegen mag, daß man keine EVAL-Boards 'hinterhergeworfen' bekommt und beim Einkauf von Standard-Ausführungen zumeist mit langen Lieferzeiten zu rechnen ist. STM32F-Typen bekommt man hingegen an jeder Ecke und sofort.
Matthias S. schrieb: > Wenn du mit Audio experimentieren willst, ist z.B. das STM32F4 Discovery > nicht so schlecht. Da ist ein DAC schon drauf und es gibt noch einen > freien I2S Bus. Allerdings nicht viel RAM. Mit Bildschirm und 8MB SDRAM > gibts das STM32F429 Discovery, aber da sind so gut wie keine Pins mehr > frei, um was dazu zu bauen. Leider gibt es die Kombination wieder nicht als Board ... I2S + SDRAM + SD-Slot ... :( Ist echt doof ... das eine hat SDRAM, TFT und das andere hat einen I2S-Audio-DAC drauf ... Aber so die Kombination hatte ich noch nicht als fertiges Board gesehen. Und einen SD-Slot haben beide Discoverys nicht. > Als Toolchain würde ich heute vermutlich wieder zu Atollics TrueStudio > wechseln, wenn mein altes Coocox hier nicht alles bieten würde, was ich > derzeit brauche. Ich verwende Eclipse + ARM-Plugin und OpenOCD zum Debuggen ... Funktioniert prima :)
:
Bearbeitet durch User
Ich hatte vor einigen Wochen angefangen mich mit dem STM32L0 ("L"!) zu
beschäftigen. Erste Gehversuche hatte ich hier dokumentiert:
https://drolliblog.wordpress.com/2017/04/06/led-blink-with-the-stm32l031x6/
Positiv:
- Die Chips lassen sich bequem über RS232 programmieren.
- Klein, aber noch handhabbar
- Geringer Stromverbrauch
- GCC Toolchain, C-Headerdateien mit allen Register Definitionen
- Cortex-M0+
Von der STM Cube MX Library hatte ich erstmal die Finger gelassen. Wegen
der schlechten Lib-Dokumentation musste ich ständig im Code der Library
nachlesen, was die Funktion denn nun wirklich tut. An Ende habe ich dann
doch lieber die HW-Register direkt angesprochen.
Was mir bei anderen ARMs auch schon aufgefallen ist: Um irgendwas zu
aktivieren, muss man irgendwo anders Clockleitungen aktivieren, Resets
durchführen und/oder Sperrmechanismen entriegeln. Das ist nicht weiter
schlimm und die Datenblätter sind hier durchaus vollständig und präzise,
aber es erfordert doch genaues lesen.
Grüße,
Oliver
Mampf F. schrieb: > Leider gibt es die Kombination wieder nicht als Board ... I2S + SDRAM + > SD-Slot ... :( Das STM32F746 Discovery hat genau das: * 8 MByte SDRAM * 480x272 LCD * Audio-Codec WM8994 welcher über I²S angebunden ist. Der I²S ist nicht rausgeführt, aber der Codec bietet bereits 2 Mikrofone, 1 Line-In, 1 Kopfhörer-Ausgang, 1 Speaker-Ausgang. Vielleicht reicht dir das schon. * microSD-Slot mit echtem SD bus (kein SPI)) Das ganze ist jedenfalls definitiv schnell genug für 44.1kHz Audio (vermutlich auch mehr). In der Doku steht überall was von SAI, das ist ein Peripherie-Block welcher u.a. I²S spricht.
M. H. schrieb: > Welchen Chip (welches Board) würdet Ihr mir heute empfehlen? Ich würde > mir einen wünschen, der schnell genug für I2S ist, den ich möglichst > "bare metal" programmieren kann (zumindest so dass alles zur Laufzeit > deterministisch und unter meiner Kontrolle ist), der nicht übermäßig > komplex ist und für den es eine gut gepflegte Toolchain gibt. > > Vielen Dank! Hmm, weil alle hier STM32 schreien, sollte man doch mal eine Alternative erwähnen: PIC32MX oder MZ. Auch die sind noch schön bare-metal programmierbar und schnell genug für sinnvolle I2S-Andwendungen. Konkret habe ich persönlich schon mal einen mp3-Player mit einem PIC32MX470 umgesetzt, decodierung in Software und Ausgabe über I2S. Mir persönlich sagt die Peripherie der PIC32MX erheblich mehr zu, als jene der STM32. Insbesondere praktisch finde ich die Art, wie man mit den von Microchip definierten Headern auf die Einzelbits Register zugreifen kann.
PIC32 schrieb im Beitrag #5078008: > Insbesondere praktisch finde ich die Art, wie man mit > den von Microchip definierten Headern auf die Einzelbits Register > zugreifen kann. Woah, dass ich habe ich schon immer vermisst! Das gibt es seit dem ersten C Compiler fürn 8051. :-<<<
Jörg W. schrieb: > Jim M. schrieb: >> Abgesehen von den Radio-Sachen für Blueooth Low Energy ist das ein >> vergleichweise übersichtlich aufgebauter Chip. > > … wie andere Cortex-M0s auch. ;-) Die NRF51/NRF52 haben wirklich deutlich einfachere Peripherals. Wenn Du da z.B. eine Peripheral einschaltest, dann bekommt die auch einen Takt. Fast alle Pins sind beliebig an alle Peripherals schaltbar. Die Dokumentation ist "relativ" gut und im Gegensatz zu z.B. ST, bekommt man im Forum von Nordic eigentlich fast immer eine Antwort, wenn man eine vernünftige Frage stellt. Die low level Libraries sind auch handwerklich deutlich besser, als z.B. die von ST. > Warum willst du ihm eine auf > HF-Protokolle spezialisierte Hardware aufdrängeln (wobei man den > HF-Teil praktisch nicht mehr bare metal programmieren kann, weil die > Lebenszeit dafür nicht ausreicht), wenn er eigentlich nur einen CM0 > (oder CM0+) sucht? https://github.com/TorstenRobitzki/bluetoe (Ok, ist auch nocht nicht ganz fertig. Aber wenn nichts dazwischen kommt (z.B. Kunden), dann werde ich das noch fertig stellen ;-) Die Radio-Peripheral ist auch nur eine Peripheral (ok, wahrscheinlich die, die im Chip am meisten kostet) von anderen und auch in anderen Controllern wird man nie alle Peripherals nutzen.
Torsten R. schrieb: > Die Radio-Peripheral ist auch nur eine Peripheral (ok, wahrscheinlich > die, die im Chip am meisten kostet) Eben. Ich würde auch keinen ATmega256RFR2 jemandem empfehlen, der nur einen Controller braucht, bloß weil ich diesen Chip gerade besonders gut kenne.
M. H. schrieb: > Welchen Chip (welches Board) würdet Ihr mir heute empfehlen? Ich würde > mir einen wünschen, der schnell genug für I2S ist, den ich möglichst > "bare metal" programmieren kann (zumindest so dass alles zur Laufzeit > deterministisch und unter meiner Kontrolle ist), der nicht übermäßig > komplex ist und für den es eine gut gepflegte Toolchain gibt. "bare metal" kann man eigentlich fast alle µC programmieren. Für Audio oder SDR-Zwecke fallen aber fast alle kleineren Typen (8Bit usw.) heraus. Was übrig bleibt, sind PIC32 und Cortex M4F. Nun mußt du PIC32 und Renesas betreffend, jemand anderes als mich fragen, aber zu den unten genannten Cortexen kann ich was beitragen: 1. die hier extrem häufig genannten STM32F... sind zwar durchaus weit verbreitet, haben konstruktiv aber gerade für I2S-Zwecke eine eher sau-ungünstige Peripherie. Die ist nämlich in weiten Teilen nur 16 bittig ausgeführt und oft fehlen sinnvolle Caches und das macht Streß. Bei den F446ern z.B. hat man zwar bei allen SPI Cores auch nen I2S-Modus, aber der ist so doof gemacht, daß man keine Freude dran hat - entweder 4 Interrupts pro Sample oder sich mit DMA herumschlagen. Bleiben also nur die 2 SAI-Cores übrig, von denen aber einer bei allen kleineren Gehäusen nicht benutzbar ist - und wie deren Cache wirklich funktioniert, muß man wohl ausprobieren. 2. bei NXP sieht die Peripherie bei den LPC4xxx zum Teil deutlich besser aus, da viel mehr eben echt 32 bittig gemacht ist. Dafür ist die Typenvielfalt geringer - und bei den Dualcore-Typen (M4F+M0) sehe ich bei der Softwareentwicklung noch nicht richtig durch. Vielleicht muß man beide Codeseiten separat entwickeln, um sauber zwischen M4F-Code und M0-Code trennen zu können. ansonsten entfalten gerade diese Typen ne ziemliche Rechenleistung. 3. bei den NXP-Kinetis mußt du zuerst dir die Doku anschauen, ob du damit klar kommst und verstehst, was die eigentlich meinen. Ich krieg damit regelmäßig nen Koller. Aber hier gibt's ja einen Leut, der deren Doku ausgesprochen gut findet. 4. Guck dir auch die neueren Nuvoton-Typen an, dort gibt es auch recht nette Chips, aber auch dort: zuerst Doku reinziehen. Ich hatte Nuvoton in letzter Zeit bissel schleifen lassen aus Zeitgründen. W.S.
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.