Hallo, die meisten Mikrocontroller haben Standardperipheriemodule, wie ADCs, PWMs, Kommunikationsschnittstellen (UART, SPI, I2C), EEPROMs etc. Meine Frage ist nun, ob es eine C-Lib oder Layer gibt, der diese Standardmodule einheitlich abstrahiert, d.h. dass ich z.B. einen Header GenericAdc.h einbinden kann, der auf Methoden in einer ADC_STM32xyz.c verweist, die die ADC-Funktion abstrahieren. Bei Wechsel auf einen anderen uC ist dann nur das Sourcefile gegen ein ADC_MSP32xyz.c auszutauschen, die natürlich die selben generischen Methoden bereitstellen muss. Mir ist klar, dass dabei Abstriche bei den peripheriespezifischen Sonderfunktionen gemacht werden müssen, aber letztlich ist mir bei Projekten mit AVRs, STMs oder MSPs aufgefallen, dass ein Großteil der Peripherie doch immer die gleichen Grundfunktionen bereitstellt und sich daher einheitlich, d.h generisch abstrahieren lassen sollte. Mich interessiert nun einfach ob es solche Projekte bereits gibt und falls nein, was aus eurer Sicht gegen den Ansatz spricht.
Gegen den Ansatz spricht, dass die Fähigkeiten der Hardware sehr unterschiedlich ist. Ein einheitliches Framework muss daher viele interessante Features ungenutzt lassen und andere fehlende Features durch Software-Emulation ersetzen. Das Ergebnis ist ein Programm, dass die Hardware nur zum Teil nutzt und daher entweder suboptimale Performance hat oder unnötig hohe Hardwareanforderungen. Ob diese Nachteile für ein Projekt relevant sind, muss jeder selbst entscheiden. Arduino ist ja trotzdem recht erfolgreich.
Volkker schrieb: > Arduino Arduino hat m.E. nicht die Modulabstraktion zum Ziel sobdern uC-Programmierung möglichst niederschwellig für jeden mit möglichst wenig Vorkenntnissen möglich zu machen mit all dem dafür notwendigen Overhead. Wird Arduino denn irgendwo professionell eingesetzt? Ich denke nicht. Johannes S. schrieb: > Mbed-os Das kenne ich nur vom Hörensagen. Stellt Mbed denn ein Framework bereit das ohne das zugehörige OS benutzt werden kann? Stefan ⛄ F. schrieb: > Ein einheitliches Framework muss daher viele interessante Features > ungenutzt lassen und andere fehlende Features durch Software-Emulation > ersetzen. Das Ergebnis ist ein Programm, dass die Hardware nur zum Teil > nutzt und daher entweder suboptimale Performance hat oder unnötig hohe > Hardwareanforderungen. > > Ob diese Nachteile für ein Projekt relevant sind, muss jeder selbst > entscheiden. Arduino ist ja trotzdem recht erfolgreich. Korrekt, der Funktionsumfang sollte sich daher m.E. auf dem kleinsten gemeinsamen Nenner der Module bewegen, mit den von dir genannten Nachteilen.. Großer Vorteil ist aber maximale Plattformunabhängigkeit, was in Zeiten stetig günstig werdender Rechenleistung aber wohl immer wichtiger im Vergleich zu Softwareoptimierung wird, zumal Produktzyklen tendenziell auch nicht länger werden.
Andreas F. schrieb: > Das kenne ich nur vom Hörensagen. Stellt Mbed denn ein Framework bereit > das ohne das zugehörige OS benutzt werden kann? das OS ist das Framework, es gibt ein API (in C++) das für verschiedene µC implementiert ist: https://os.mbed.com/docs/mbed-os/v6.3/apis/index.html Low Level ist das was unter 'Drivers' zu finden ist. Der Haken: das ist nur für die Cortex-M (weil es auch von ARM gepflegt wird). Wenn man weitere Plattformen 'gleich' haben möchte sind ChibiOS oder NuttX noch ähnliche Ansätze. Aber schon auf den Cortex-M alles gleichzuhalten ist sehr viel Aufwand. Andreas F. schrieb: > Großer Vorteil ist aber maximale Plattformunabhängigkeit, > was in Zeiten stetig günstig werdender Rechenleistung aber wohl immer > wichtiger im Vergleich zu Softwareoptimierung wird, zumal Produktzyklen > tendenziell auch nicht länger werden. das sehe ich auch so, es ist mir wichtiger als die beste Performance im Sinne von 'meine Assembler Routine kann eine LED aber viel schneller blinken lassen'. Bezahlbare µC sind bei >500 MHz, >1 MB Ram und >2 MB Flash angekommen, die Kunst ist das alles Softwaretechnisch noch zu beherrschen.
Andreas F. schrieb: > Meine Frage ist nun, ob es eine C-Lib oder Layer gibt, der diese > Standardmodule einheitlich abstrahiert Nein. Volkker schrieb: > Arduino Ja, aber bis zur Nutzlosigkeit abstrahiert. Andreas F. schrieb: > dass ein Großteil der Peripherie doch immer die gleichen Grundfunktionen > bereitstellt Bloss mit ekeligen modellspezifischen Unterschieden. Was willst du für eine Funktion ? Eine die garantiert auf allen uC funktioniert, also die kleinste gemeinsame Funktionalität abbildet oder eine die alle Möglichkeiten unterstützt, also das grösste möglichen Features anbietet und dann auf den simpleren nicht funktioniert ? 'analog input lesen auf Pin 10 mit 12 bit und 32000 sps'. geht nicht weil Analogeingänge nur auf Pin 12-17 möglich sind geht nicht weil dieser uC nur 10 bit A/D (man könnte trotzdem 12 liefern, fie untrten beiden immer 0 oder 4 mal;nacheinander messen und aufsummieren, mit etwas rauschen hätte man mehr Auflösung) geht nicht weil nur 20000 oder 40000sps bei der aktuellen Quartzfrequenz auswählbar sind, man müsste einen 3.Hz statt dem 4MHz Quartz einlöten geht schon, aber nur per DMA und DMA ist durch andete Funktionen schon belegt geht, aber dieser uC könnte 2 Kanäle gleichzeitig sampeln, wie es z.B. für Leistungsberechnung (Strom I x Spannung U) nötig ist, bloss die Funktion ist ungeeignet das zu definieren. Die verschiedenen herstellerspezifischen Abstraktionslayer wie HAL von ST versuchen modellunabhängig zu sein, werden aber als überkomplex abgelehnt. Es ist also zu schwierig. Normale uC Programmierung kämpft mit Resourcen und Energieeinsparung, da ist ein Arduinolayer eher Kinderspielzeug.
ja nee, is klar. Darum benutzt auch keiner HAL, diverse OS und Arduino schon gar nicht.
Johannes S. schrieb: > und Arduino schon gar nicht. In professioneller Mikrocontrollerentwicklung ? Hoffentlich nicht. Maschinenbauer nutzen ja auch kein Lego.
>> Großer Vorteil ist aber maximale Plattformunabhängigkeit,..
die gibt es nicht, weil manche Perif-Module viel zu complex sind.
Wer diese Features nutzen will muss ins DB guggen.
Andreas F. schrieb: > Volkker schrieb: >> Arduino > > Arduino hat m.E. nicht die Modulabstraktion zum Ziel sobdern > uC-Programmierung möglichst niederschwellig für jeden mit möglichst > wenig Vorkenntnissen möglich zu machen Arduino macht beides. Immerhin gibt es die Arduino-Umgebung nicht nur für AVR, sondern auch für etliche Cortex-M. Letzteres sogar für mehrere Hersteller, womit es in dieser Hinsicht mehr leistet als die herstellerspezifischen Abstraktionen a'la HAL oder ASF. > Wird Arduino denn irgendwo professionell eingesetzt? Ich hoffe nicht. Aber das war ja nicht die Frage, oder? Ich halte die Idee für nicht zielführend. Im Detail unterscheidet sich die Hardware dann doch so weit, daß man mit einem generischen Framework nicht weit kommt. Das was als kleinster gemeinsamer Nenner übrig bleibt, ist einfach zu wenig. Overhead fängt man sich ja auch immer noch ein. Wer will das schon? Wenn man seinen eigenen Code ordentlich strukturiert und die hardwareabhängigen Teile schön separat hält, ist eine Portierung auch nicht so wahnsinning aufwendig.
Axel S. schrieb: > Ich hoffe nicht. Aber das war ja nicht die Frage, oder? Warum nicht professionell einsetzen? Dahinter steckt ein gcu-gcc/-g++ als Compiler und die LIbraries sind auch einsehbar. Im Gegensatz zu STM-Discovery- und -Nucleso-Boards dürfen die (originalen) Arduino-Boards sogar in kommerziellen Geräten verbaut werden. Die HAL von STM ist ja auch als fehlerbehaftet verschrien, und ich habe sogar schon in einer origial Keil-MDK-Library einen supderdämlichen Fehler entdeckt - und der Kram kostet wirklich Geld (wir verwenden in der Firma die PRO-Version u.a. wegen der USB-Host-Library).
Andreas F. schrieb: > Meine Frage ist nun, ob es eine C-Lib oder Layer gibt, der diese > Standardmodule einheitlich abstrahiert, d.h. dass ich z.B. einen Header > GenericAdc.h einbinden kann, Nein, so eine General-C-Lib wird es nie geben. Aber im Detail geht da schon einiges. Dein Beispiel mit dem ADC ist da grad recht daneben, aber für solche Dinge wie serielle Kanäle (UART und USB als VCP) geht so etwas durchaus. Das nennt sich dann Lowlevel-Treiber und die Vereinheitlichung besteht eben NICHT darin, eine einheitliche C-Lib haben zu wollen, SONDERN sie besteht darin, daß die jeweiligen Lowlevel-Treiber intern zwar chipspezifisch sind, nach außen hin jedoch eine einheitliche Schnittstelle zum Benutzen bieten. Damit hat man 'weiter oben' in der Firmware eine einheitliche Schnittstelle für die UART's und dergleichen und ist deshalb in diesem Punkte plattformunabhängig. Ich hab sowas hier schon oft genug gepostet, such einfach mal danach. Ebenfalls sind echte HAL-Funktionen sinnvoll, also sowas, das ebenso die zugrundeliegende Hardware/Peripherie nicht nach oben hin durchgrinsen läßt, sondern nach oben hin die eigentlich bezweckte Funktion bietet. Beispiele: 1. schlecht, weil keine Abstraktion: void SetzePin(MotorPort,MotorPin,1); 2. gut, weil echte HW-Abstraktion: void SchalteMotorEin(void); void SchalteMotorAus(void); Bei 1. müssen sich die höheren Schichten drum kümmern, an welchem Port und welchem Pin der Motor hängt und ob er nun mit 1 ein- und mit 0 ausgeschaltet wird oder umgekehrt. So etwas wird leider von Vielen hier immer wieder praktiziert, ist aber vom Prinzip her Mumpitz. Bei 2. müssen sich die höheren Programmschichten eben nicht um die dreckigen Details kümmern und es kann ihnen schnurz sein, ob der Motor nun per Portpin oder per Netzwerk bei den Antipoden geschaltet werden muß. So. Prinzip verstanden? W.S.
W.S. schrieb: > 2. gut, weil echte HW-Abstraktion: > void SchalteMotorEin(void); > void SchalteMotorAus(void); oder
1 | void SchalteMotor(int EinAus); |
Andreas F. schrieb: > Meine Frage ist nun, ob es eine C-Lib oder Layer gibt, der diese > Standardmodule einheitlich abstrahiert, d.h. dass ich z.B. einen Header > GenericAdc.h einbinden kann, der auf Methoden in einer ADC_STM32xyz.c > verweist, die die ADC-Funktion abstrahieren. Bei Wechsel auf einen > anderen uC ist dann nur das Sourcefile gegen ein ADC_MSP32xyz.c > auszutauschen, die natürlich die selben generischen Methoden > bereitstellen muss. Also ohne nachzudenken einfach die benötigten Libs reinkopieren? Andreas F. schrieb: >> Arduino > > Arduino hat m.E. nicht die Modulabstraktion zum Ziel sobdern > uC-Programmierung möglichst niederschwellig für jeden mit möglichst > wenig Vorkenntnissen möglich zu machen mit all dem dafür notwendigen > Overhead. "... möglichst niederschwellig ...". Genau das willst Du doch mit Deiner gewünschten "Universalität". Nimm Arduino. Blackbird
STK500-Besitzer schrieb: > oder void SchalteMotor(int EinAus); Kann man machen, ist aber blöd. Gründe: normalerweise weiß man im Algorithmus, wo man den Motor einschalten muß und wo Ausschalten dran ist. Der Aufruf müßte das Laden eines Arguments umfassen, die Lowlevel-Funktion müßte es auswerten - und WOZU? Obendrein: Ein int EinAus müßte definiert werden, ein bool obEin ebenfalls. Und beides ist sachlich nicht notwendig. Und es ist eine Stelle, wo man Schusselfehler machen kann. Bei zwei separaten void Funktionen (void) braucht es keinerlei Argument, was den Aufruf und die Funktionen codemäßig simpel macht und obendrein auch noch Schusselfehler vermeidet. W.S.
Ein schalteIrgendwas() zu bauen ist aber schon der Applikationslevel. Das OS hat nix mit Motor oder Licht zu tun, das soll es mir einfach machen einen Portpin zu setzen. Über eine API die möglichst HW unabhängig ist und das gibt es bei den genannten und weiteren OS. Man kann die Pins dabei auch einfach mit D1,D2,D3 durchnummerieren wie es Arduino macht weil die Port/Pin Bezeichnungen wieder Herstellerabhänging sind. Aber inrgendwo muss man die definieren und da kann ich auch diese Abhängigkeit per #ifdef oder über das Buildsystem einbauen.
STK500-Besitzer schrieb: > Axel S. schrieb: [Arduino professionell einsetzen] >> Ich hoffe nicht. Aber das war ja nicht die Frage, oder? > > Warum nicht professionell einsetzen? Warum baut man ein Haus nicht aus Legosteinen? Warum fährt man mit dem Seifenkisten-Auto kein Formel1-Rennen? > Dahinter steckt ein gcu-gcc/-g++ als Compiler und die LIbraries sind > auch einsehbar. Für den Compiler können die Arduino-Leute nichts. Der kommt aus dritter Hand und ist nicht zu beanstanden. Aber die Libraries sind gruselig. Daß man den Quellcode sehen kann, macht die Sache nicht besser. > Die HAL von STM ist ja auch als fehlerbehaftet verschrien, und ich habe > sogar schon in einer origial Keil-MDK-Library einen supderdämlichen > Fehler entdeckt - und der Kram kostet wirklich Geld (wir verwenden in > der Firma die PRO-Version u.a. wegen der USB-Host-Library). Ja. Und? Wird dadurch Arduino irgendwie besser?
Axel S. schrieb: > Daß man den Quellcode sehen kann, macht die Sache nicht besser. Absurde Kritik! Wie kann man denn nur "offenen Code" in eine abwertende Kritik einbauen? Axel S. schrieb: > Aber die Libraries sind gruselig. Ein Rundumschlag! Natürlich sind alle, gefühlte 3000, Arduino kompatiblen Libraries Mist. Und du hast sie auch alle untersucht. Nee... Vermutlich meinst du das mitgelieferte Framework, und nicht die Libraries. Oder?
Johannes S. schrieb: > Ein schalteIrgendwas() zu bauen ist aber schon der Applikationslevel. Nein. Das ist ein (anwendungsspezifisches) HAL. Und da wir von µC Programmierung reden, ist in meinen Augen ein OS nicht vorhanden. Man braucht dann schlicht kein weiteres Abstraktionslayer. > Das OS hat nix mit Motor oder Licht zu tun, das soll es mir einfach > machen einen Portpin zu setzen. Wenn man ein OS hat, dann braucht man natürlich dort eine Abstraktion von der Hardware. Aber auch dann ist die Frage, ob man ein generisches Layer mit Analog- und Digitalpins a'la Arduino macht. Oder ob man nicht einen spezifischen Treiber macht, in diesem Beispiel einen Motortreiber. Letzteres finde ich klar die bessere Lösung, weil man mit dem generischen Pin-Interface wieder keine logische Abstraktion hat. "An welchem Pin hing gleich noch mal der Motor? Und schaltet man den mit 1 ein oder mit 0?". Das läuft dann darauf hinaus, eine weitere Zwischenschicht einzuziehen. Am Ende landet man bei API-Türmen wie in Java, wo ein Stacktrace in einer Fehlermeldung gleich mal über zwei Bildschirmseiten geht.
>Damit hat man 'weiter oben' in der Firmware eine einheitliche >Schnittstelle.. Nur, sobald eine einheitliche Schnittstelle da ist / genommen wird, ist es vorbei mit speziellen Funktionen, die diese Peripherie im Vergleich zu anderen bietet (mann müsste diese speziellen Funktionen dann 1:1 nach unten durchreichen, da kann man es womöglich auch gleich ganz sein lassen)
>Am Ende landet man bei API-Türmen wie in Java, ...
die meist noch sehr viel Leistung fressen
Schau dir mal Rust Embedded an, da wird genau das (sinnvoll) erreicht: - Es gibt Traits (ähnlich den Interfaces in Java), z.B. für TWI, PWM, UART,... - Die HAL eines mikrocontroller implementiert diese Interfaces. D.h. die HAL kann durchaus mehr genutzt werden als nur mit den Funktionen des Interface, aber dadurch können Treiber (z.B. für TWI) einmal geschrieben werden und überall genutzt werden, da die Funktionen write und read durch das Interface vorgegeben sind.
MCUA schrieb: > Nur, sobald eine einheitliche Schnittstelle da ist / genommen wird, ist > es vorbei mit speziellen Funktionen nein. Es ist nicht verboten ohne das OS auf Peripherie zuzugreifen. Entweder schreibt man Funktionen/Klassen im Stile des OS um es zu erweitern, oder schreibt direkt in die Register. Ein µC OS ist ein PC der alles abschottet und virtualisiert, da habe ich die volle Kontrolle. Die Funktionalität im Sinne des OS zu erweitern ist natürlich die saubere Lösung. Wenn ein anderer µC die Funktion nicht unterstützt, dann ist das so. Das sollte einfach keinen Compilerfehler geben bzw. einen Fehler mit Klartext das diese Plattform nicht unterstützt wird. Beim STM habe ich z.B. die Einstellungen für die GPIO Frequenz gebraucht, das ist kein allgemeines Feature im OS. Ist aber kein Problem, ich leite meine eigene DigitalOut Klasse ab und füge die zusätzliche Initialisierung hinzu. Das ist kein Performanceverlust und hat nix mit überfrachtetem Framework zu tun.
>Es ist nicht verboten ohne das OS auf Peripherie zuzugreifen. ..... (man müsste diese speziellen Funktionen dann 1:1 nach unten durchreichen, da kann man es womöglich auch gleich ganz sein lassen) >Ein µC OS ist ein PC der alles abschottet und virtualisiert Du meinst wohl ..ist kein PC.. (Und selbst beim PC kann man auch bis auf Registerebene programmieren), den kannst du auch BareMetal programmieren. >ist kein Performanceverlust.. Doch, in den Meisten Fällen ist weiterer Progr-Code aufm uC nötig! Selbst wenn es angenommen nicht so wäre, bleibt die Frage, ob man so ein OS benutzen sollte, bei dem man an allen Ecken und Kanten weitere Teile einflicken muss.
>aber dadurch können Treiber (z.B. für TWI) einmal geschrieben >werden und überall genutzt werden.. Die kannst du herkömmlich genauso nutzen.
Johannes S. schrieb: > . Es ist nicht verboten ohne das OS auf Peripherie zuzugreifen. Entweder > schreibt man Funktionen/Klassen im Stile des OS um es zu erweitern, oder > schreibt direkt in die Register Du hast keine Ahnung. Nicht mal Arduino-Niveau. Wenn man einen Hardware-Abstraktionslayer schreibt, nutzt man Ressourcen. Beispielsweise für Beep einen Timer. Bloss sieht man der Beep-Funktion nicht an, welchen Timer. Eventuell ist das sogar je nach Pin ein anderer. Da darfst du dann nicht in den Steuerregistern des Timers rumpfuschen um ihn für deine Zwecke zu nutzen. Das macht die Funktion der abstrakten Funktionen sofort kaputt. Beim Arduino sieht man schön, wo das hinführt: dort werden die von Funktionen benutzten Ressourcen nicht mal dokumentiert. Das darfst du alles auf die harte Tour lernen. Entweder weil dein Programm einfach nicht mehr funktioniert, oder weil du den Quellcode der Shield-Libraries durchsuchst. Nur damit beim nächszen Versionsupdate wieder alles anders ist. Der üblich uC hat viel zu wenig Resourcen, um die unabhängig von anderen zu benutzen.
STK500-Besitzer schrieb: > und ich habe > sogar schon in einer origial Keil-MDK-Library einen supderdämlichen > Fehler entdeckt - und der Kram kostet wirklich Geld Interessant, einen solchen Fehler habe ich ebenfalls schon in der Keil-MDK entdeckt. W.S. schrieb: > Nein, so eine General-C-Lib wird es nie geben. > Aber im Detail geht da schon einiges. Dein Beispiel mit dem ADC ist da > grad recht daneben, aber für solche Dinge wie serielle Kanäle (UART und > USB als VCP) geht so etwas durchaus. > > Das nennt sich dann Lowlevel-Treiber und die Vereinheitlichung besteht > eben NICHT darin, eine einheitliche C-Lib haben zu wollen, SONDERN > sie besteht darin, daß die jeweiligen Lowlevel-Treiber intern zwar > chipspezifisch sind, nach außen hin jedoch eine einheitliche > Schnittstelle zum Benutzen bieten. Genau das meine ich doch. Ich will keine einheitliche Lib sondern eine Schnittstellendefinition die die generischen Modulfunktionalitäten abstrahiert. Ein AVR hat wie ein STM wie ein MSP einen ADC, mit einer Abtastrate und einer Auflösung, die sich durch eine einheitliche Schnittstelle ansteuern lassen können sollten. Nur selten habe ich bisher die wirklich mikrocontrollerspezifischen Feinheiten der Peripheriemodule ausnutzen müssen, was mich zu der Überlegung brachte im Zweifelsfall lieber einen EUR 1 teureren Controller zu verwenden, wenn ich mir bei der Entwicklung dann 1 Tag spare weil ich nicht das ganze ADC-Kapitel im DB durchlesen muss, oder noch schlimmer, eine HAL vom Hersteller verwenden muss. Wenn wirklich Optimierung gefordert ist, kann dies immernoch durch einen separaten Treiber geschehen. Ich denke mir das der Ansatz nicht neu sein kann und dass es doch ein Framework/Schnittstelle zwischen Arduino und Hersteller-HAL geben muss. Lothar J. schrieb: > "... möglichst niederschwellig ...". > Genau das willst Du doch mit Deiner gewünschten "Universalität". Nein, ich will nicht bei jedem Controllerwechsel wieder 20 Seiten Datenblatt durchlesen um rauszufinden wie der ADC denn nochmal anzusteuern war. Schorschi schrieb: > Schau dir mal Rust Embedded an, da wird genau das (sinnvoll) erreicht: > - Es gibt Traits (ähnlich den Interfaces in Java), z.B. für TWI, PWM, > UART,... > - Die HAL eines mikrocontroller implementiert diese Interfaces. D.h. die > HAL kann durchaus mehr genutzt werden als nur mit den Funktionen des > Interface, aber dadurch können Treiber (z.B. für TWI) einmal geschrieben > werden und überall genutzt werden, da die Funktionen write und read > durch das Interface vorgegeben sind. Das finde ich hochinteressant, gerade weil auch mein embedded Dozent ganz angetan von Rust war. Sind die Traits denn in der Sprache eingebaut? Ich hätte die Frage spezifizieren sollen zu: Gibt es solche Frameworks die auch im professionellen Umfeld eingesetzt werden? Auf Bastlerlösungen habe ich keine Lust.
MCUA schrieb: > Du meinst wohl ..ist kein PC.. ja, kleiner Typo. Schon mal ein OS auf dem µC benutzt? Das sind hier immer wieder gleich die üblichen Vorurteile die schon tausende Male vorgebracht wurden. Für mich überwiegen die Vorteile bei weitem und es ist nicht unflexibler wenn etwas erweitert werden muss. Ich habe mir z.B. gerade einen Debugadapter aus BMP und Mbed gebaut um den über Ethernet anzusprechen. Das war wenige Tage Arbeit, das Ethernet ist einfach fertig und die Arbeit war das BMP zu verstehen und möglichst minimal invasiv den C-Code in C++ zu nutzen. Das läuft auf einem F407, kann aber jetzt auch für andere µC mit Ethernet kompiliert werden. Das Bitbanging für SWD mit den IO Klassen war immer noch zu schnell und musste nicht optimiert sondern noch gebremst werden.
MaWin schrieb: > Beispielsweise für Beep einen Timer. Bloss sieht man der Beep-Funktion > nicht an, welchen Timer. Eventuell ist das sogar je nach Pin ein > anderer. Auch darum mag ich Mbed weil da keine Timer übermässig verbraten werden, es gibt nicht mal eine Hardware Timer Klasse. Alles läuft über einen Timer.
MaWin schrieb: > Du hast keine Ahnung. und was hat sowas in einer Diskussion zu suchen? Ich habe ein paar Jahre Programmiererfahrung, glaube es mir.
Vor einigen Monaten hatten wir hier jemanden, der auch so einen Abstraktionslayer wollte. Er schlug als Beispiel eine I²C Klasse vor, die solche Methoden hatte:
1 | send_start(); |
2 | send_stop(); |
3 | read_ack(); |
4 | send_byte(); |
5 | receive_byte(); |
6 | set_bitrate(); |
Das wäre generisch genug, um auf allen Mikrocontrollern funktionieren zu können, dachte er. Aber sämtliche STM32 Modelle passen nicht dazu. Bei ihnen muss man zu beginn einer Transaktion angeben, wie lang sie sein wird. Start/Stop und Datenübertragung sind dort eine zusammenhängende Einheit. Danach brachten andere Leute weitere Beispiele für andere Schnittstellen, wo es ebenfalls an den Fähigkeiten der Hardware scheiterte. Selbst innerhalb der STM32 Produktreihe sind die Controller trotz Cube HAL nicht einfach austauschbar. Wenn die das schon nicht hin bekommen, wer dann?
I2C ist in Mbed abstrahiert und Standard auf allen Targets. Wenn etwas nicht oder schlecht oder langsam in HAL war, dann wurde das über passende Funktionen gelöst. Und der ganze Kram durchläuft zig Testcases und wird auch auf einer grossen Rechnerfarm in echter Hardware getestet. Da wurden schon viele Fehler gefunden die aus HAL oder anderen Frameworks kamen und dann wieder da korrigiert wurden. Seit der STM HAL public auf github liegt wurden da auch schon einige Issues gesammelt und behoben.
Stefan ⛄ F. schrieb: > Aber sämtliche STM32 Modelle passen nicht dazu. Bei > ihnen muss man zu beginn einer Transaktion angeben, wie lang sie sein > wird. Tja - und genau DAS ist für einen Lowlevel-Treiber die absolute Krätze. Ein Treiber soll und muß hier eigentlich nur 4 Dinge erledigen: 1. OpenSlave (adresse + rd oder wr) - also Busherrschaft bekommen, den Slave adressieren, zurückmelden, ob der ACK sagt. 2. und 3. WriteByte und ReadByte(ob mit ACK) 4. Stop und Bus freigeben Und ST hat es mal wieder total vergeigt. Jahrelang waren die I2C-Cores miserabel bis beschissen, weil sie eigentlich nur aus einem Interrupt-Erzeuger bestanden und sämtliche Aktionen in der ISR zu erledigen waren. Da war es leichter, den ganzen I2C rein per Software zu erledigen. Jetzt wird bei ST gemeint, daß man das ja alles zusammenfassen müßte und herausgekommen ist ein Core, der auf seine Weise unbenutzbar ist. Sowas wie die repeated start cond, die man oft braucht, um einem Slave erstmal nen Index zu senden und dann dort etwas zu lesen - OHNE zwischendurch den Bus freizugeben, ist mit sowas schier unmöglich. Und ein Treiber kann NIEMALS selber wissen, was und wieviel die höheren Programmschichten zu senden/empfangen geruhen. Das ist auch nicht seine Aufgabe, er soll ja nur das Senden/Empfangen erledigen. W.S.
Ja W.S., da kannst du über STM herziehen wie du willst, die Situation ändert sich dadurch nicht. Die Allgemeingültige HAL muss darauf eingehen. Aber lass und das Gedankenspiel mal weiter spinnen. Wir schießen alle STM32 aus, wegen ihren I²C Eigenarten. Wir schließen AVR aus, weil deren SPI keinen Sendepuffer haben. Wenn wir so weiter machen, bleibt nicht mehr viel übrig.
W.S. schrieb: > Sowas > wie die repeated start cond, die man oft braucht, um einem Slave erstmal > nen Index zu senden und dann dort etwas zu lesen - OHNE zwischendurch > den Bus freizugeben, ist mit sowas schier unmöglich. Das geht: https://os.mbed.com/docs/mbed-os/v6.3/mbed-os-api-doxy/classmbed_1_1_i2_c.html#aeb2e6757a3348668fa25d43f7932f78e wenn man wissen möchte wie, dann muss man in die Implementierung schauen. Ich hatte jedenfalls noch kein Problem mit verschiedenen I2C Varianten. Und von Zwangstimeouts höre ich auch zum ersten mal, gibts hier auch nicht, trotz HAL im Unterbau.
Johannes S. schrieb: > Das geht Wie es geht, steht auch im Errata. Aber er hat schon Recht, die I²C Einheit von STM32 ist gerade für solche allgemeingültigen HAL trotzdem ein nerviges Hindernis.
Andreas F. schrieb: > Lothar J. schrieb: >> "... möglichst niederschwellig ...". >> Genau das willst Du doch mit Deiner gewünschten "Universalität". > > Nein, ich will nicht bei jedem Controllerwechsel wieder 20 Seiten > Datenblatt durchlesen um rauszufinden wie der ADC denn nochmal > anzusteuern war. Was unterscheidet denn die verschiedenen Mikrocontroller? Zum Beispiel: Der eine hat einen ADC, den andere so nicht haben, mit viel mehr Features als andere. Den jetzt genau so nutzen zu wollen, wie den einfacheren ADC das anderen Mikrocontroller, macht doch keinen Sinn. Da kannst Du doch gleich beim "alten" Mikrocontroller bleiben oder in seiner "Familie" den nächsten besseren nehmen. Man wechselt doch nicht zu einem neuen Controller, weil es gerade schick ist, sondern um ein paar neue Features zu bekommen, die der alte nicht hatte. Und die mußt Du nun programmieren, nach Datenblatt. Oder erwartest Du, dass einer noch schneller ist und Dir die Arbeit abnimmt? Ich sehe den Sinn dieser Rundum-Sorglos-Universal-Libs nicht. Außerdem werden die nie fertig, nie fehlerfrei sein und immer unvollständig bleiben, da gefühlt alle halben Jahre neue Mikrocontroller mit noch anderen Features oder Erweiterungen auf den Markt kommen. Blackbird
Lothar J. schrieb: > Zum Beispiel: Der eine hat einen ADC, den andere so nicht haben, mit > viel mehr Features als andere. Das Programm wird aber aus mehr bestehen als nur einen ADC zu bedienen. Dann habe ich trotzdem schon DigitalIO, UART, SPI, I2C, USB, Ethernet, RTOS, Events uvm. Das werfe ich jetzt weg weil ein spezieller ADC nicht vom OS bedient wird? Ich erweitere mein System um die Komponente, benutze den Rest der schon unterstützt wird und habe mit Sicherheit etwas weniger Arbeit als from scratch anzufangen. Auch serielle Schnittstellen haben viele Modi die nicht von allen µC unterstützt werden, z.B. Multidrop und DMA. Um so ein Feature erweitere ich die vorhandene Serial Klasse und das passt ganz geschmeidig in das OS. Und schon können sich zwei µC mit 10,5 MBit/s unterhalten ohne CPU Last, trotz OS.
Na dann schreibe Dir doch Deine Libs, wenn es sie so nicht gibt, wie Du sie gerne haben möchtest. Sie werden dann aber immer ein Spezialfall bleiben. Blackbird PS: Von welchen OS redest Du?
:
Bearbeitet durch User
Lothar J. schrieb: > Man wechselt doch nicht zu einem neuen Controller, weil es gerade schick > ist, Na ja, oftmals wollte man aber (weg vom alten, hin zum neuen eines anderen Herstellers) weil er leichter billiger beschaffbar ist. Pinkompatibel wäre dann noch das I-Tüpfelchen.
Was ein OS ist und was nicht, ist nicht eindeutig definierbar, das ist quasi stufenlos scalierbar. Genau genommen schreibt jeder sein (mehr oder weniger kompliziertes (sinnvolles?)) eigenes OS, wenn er mittels ASM seinen uC 'irgentwie' ans Laufen bringt (und später womöglich verschiedene Hochsprachen-Componenten zusätzlich mit einbindet). >Na ja, oftmals wollte man aber (weg vom alten, hin zum neuen eines >anderen Herstellers) weil er leichter billiger beschaffbar ist. >Pinkompatibel wäre dann noch das I-Tüpfelchen. Das kannst du vergessen! (die paar Ausnahmen die es gibt (bsp v. 8051-AVR, alte X86) sind Controller, die schon uralt sind und die sowiso niemand mehr benutzen will). Die Hersteller wollen sich ja grade hins. Leistung usw unterscheiden, also werden die nicht zu Anderen noch pinkompatible uCs rausbringen.
Johannes S. schrieb: > Auch serielle Schnittstellen haben viele Modi die nicht von allen µC > unterstützt werden, z.B. Multidrop und DMA. Um so ein Feature erweitere > ich die vorhandene Serial Klasse und das passt ganz geschmeidig in das > OS. Mach das einfach Mal für eine Peripherie auf 3 Plattformen. Es ist entweder trivial (der Aufwand steckt im Drumherum), oder Schwergewichtig wie arduino oder SPS, oder ein unwartbarer und unvorhersehbarer Moloch. Du kannst das mit Erfolg für Deine Projekte oder Firma machen, weil die Anforderungen meist ähnlich sind, nur ein subset aller Anforderungen, und Du flexibel auf neue Anforderungen reagieren kannst (neuer Parameter im init) Auf der anderen Seite ist es unnötig: du kopierst Dir aus des Herstellers Beispielen dein I2C zusammen und verbiegst seine Schnittstelle dabei so, dass sie zu Deiner passt. Ohne alles neu zu machen, wenn Du nur 0/8-15 nutzt.
A. S. schrieb: > Mach das einfach Mal für eine Peripherie auf 3 Plattformen. da sehe ich nicht die Notwendigkeit das immer alles generisch für alle Plattformen zu erweitern. Erstmal gucke ich mir einen Prozessor für ein Projekt aus und implementiere das für diesen. Viele MCU haben Brüder und Schwestern die das auch können, innerhalb einer Familie sind die Anpassungen oft mit wenig Aufwand möglich. Beim umschwenken auf andere wird es aufwändiger, aber nicht unmöglich. Und wie schon geschrieben, mit den Standardschnittstellen die schon für alle Targets unterstützt werden kommt man schon sehr weit. Wenn es um komplett andere Architekturen als CM geht, dann bin ich mit Mbed raus, schrieb ich aber schon. Für ESP nehme ich dann halt die Espressiv Umgebung oder Arduino, aber ungern :) Denn wenn es ans Eingemachte geht, dann muss man schon mehr Zeit investieren als nur ein paar Beispiele umzumodeln. Und sich auch mit anderen Werkzeugen auseinandersetzen. Deshalb sind die 8 Bitter für mich schon lange out weil ich mit CM eine sehr breite Palette abdecken kann. Das darf aber jeder gerne für sich entscheiden, das predige ich nicht (mehr) und ich habe auch mit den AVR angefangen um wieder in die µC Welt zu kommen.
Stefan ⛄ F. schrieb: > Aber lass und das Gedankenspiel mal weiter spinnen. Wir schießen alle > STM32 aus, wegen ihren I²C Eigenarten. Wir schließen AVR aus, weil deren > SPI keinen Sendepuffer haben. > > Wenn wir so weiter machen, bleibt nicht mehr viel übrig. Mach die Augen auf, es gibt noch so vieles unter der Sonne. Aber die AVR habe ich schon vor 20 Jahren ausgeschlossen. Und die STM32 sind für mich auch beim I2C kein Problem, weil man den relativ gut rein per Software erledigen kann - und ob man nun auf das Fertigwerden des I2C-Cores wartet oder es selbst tut, kommt zeitmäßig auf dasselbe heraus. Es geht also und ich denke nicht mal im Traum darüber nach, mich mit ungeeigneten Peripherie-Cores herumzuärgern. Echte Portabilität ist mir weitaus wichtiger und wenn mich ein STM anödet, nehme ich einen anderen Hersteller. OK, Infineon ist auch raus. Aber sonst gibt es noch genug Andere. W.S.
W.S. schrieb: > und ob man nun auf das > Fertigwerden des I2C-Cores wartet oder es selbst tut, kommt zeitmäßig > auf dasselbe heraus. Der W.S. hat mal wieder nicht verstanden was ein DMA ist und warum die I2C der STM32 automatisch das Stopbit reinbaut. Macht die RasPi Periph übrigens auch. Daher empfehle ich dir: W.S. schrieb: > Mach die Augen auf, es gibt noch so vieles unter der Sonne.
:
Bearbeitet durch User
HALs, Frameworks, "Standard"-Libs, alle sind recht praktisch. Dennoch sollte man sie richtig einsetzen und seine Anwendung eben genau nicht von einer solchen Bibliothek abhängig machen, egal ob vom Controller-Hersteller, Plattform-Anbieter oder In-House. Statt dessen sollte man sich an die übergreifenden Grundgedanken von Dependency Injection, Hexagonal Architecture, Onion Architecture, Clean Code, Domain Driven Design, und wie die zahllosen Spielweisen auch immer heißen, orientieren. Der Kern dieser Ansätze ist immer gleich: Die Applikation (Business-Logik) unabhängig von der Umgebung zu machen. Verfolgt man diesen Ansatz auf allen Abstraktionsstufen, bekommt man quasi "automatisch" wirklich wieder verwendbare und unabhängige Module. Die Sehnsucht nach HAL, Betriebssystem, etc. löst sich damit schnell in Luft auf. Denn immer daran denken: Der wertvolle Code, in dem das Know-How sitzt, ist die Applikation/Anwendung und eben genau nicht die Anpassung an einen bestimmte Hardware.
W.S. schrieb: > nehme ich einen anderen Hersteller Ich beherrsche mehr oder weniger die AVR und die STM MCUs. Und vom letzteren nur die L und F. An die H-Serie habe ich mich noch nicht herangewagt. Liebend gerne würde ich über den Tellerrand schauen und andere Hersteller anpeilen; aber dafür fehlt mir die Zeit (und vermutlich auch die intellektuelle Power). Wenn ich so Deine Beitraege mir anschaue, scheinst Du zwischen den MCU-Herstellern wie ein Schmetterling von einer Blüte zur anderen zu flattern. Nicht, dass ich daran zweifle. Aber irgendwie fühle ich mich dann recht unterbelichtet.
HAL für ARM: CMSIS. Die Sachen aus den CMSIS-Packs (ARM, Vendor, Middleware Pakete). *CMSIS-Core*: Low Level Interface, CMSIS Headerfiles. Einheitliches Format der Peripheral Header Strukturen, und eine Hand voll NVIC / SysTick Funktionen. *CMSIS-Driver*: Einheitliche Peripheral HAL, welche von den MCU Herstellern geliefert wird und kompatibel zu Middleware ist. https://www.keil.com/pack/doc/CMSIS/Core/html/index.html https://www.keil.com/pack/doc/CMSIS/Driver/html/index.html
Mehmet K. schrieb: > Nicht, dass ich daran zweifle. Aber irgendwie fühle ich mich dann recht > unterbelichtet. aber nicht doch. Meine Kollegen setzen die STM32 in wichtigen Produkten ein die 24*7 laufen und die sind da sehr sehr konservativ. Das Wort 'Vendor lock-in' kennen die gar nicht, man hält von sich aus an guten und lieferbaren Komponenten fest so lange es geht, bis zum letzten Tag der Lieferbarkeit. Es geht viel mehr Zeit drauf sich in neue Controller, Architekturen oder Werkzeuge einzuarbeiten als man mit tollen Features einsparen könnte. Als Freelancer, der sich nach Kundenwünschen richten muss, hat man vielleicht eine andere Sicht. Aber bei den immer komplexeren Controllern kostet es verdammt viel Zeit wenn man 'alles' können will.
W.S. schrieb: > und ob man nun auf das > Fertigwerden des I2C-Cores wartet oder es selbst tut Schonmal was von DMA gehört? Ach ich vergaß, dass geht in einem universellen Framework ja auch wieder nicht, weil DMA bei jedem Controller anders funktioniert - wenn überhaupt.
Allgemeinen DMA support gibt es in Mbed zwar auch nicht, ich habe aber schonmal drüber nachgedacht und halte es schon für abstrahierbar. Prinzipiell macht DMA ja immer das Gleiche, es gibt Quelle und Ziel, Anzahl Wörter, Wortgrösse, Schrittweite und evtl. weitere als gemeinsame Parameter. Das kann man schon in ein Interface packen und dann für die verschiedenen Controller implementieren. Quelle und Ziel sind zwar auch Hardwareabhängig, aber trotzdem wäre so eine Klasse/Treiber schon hilfreich. Mit DMA2D oder anderen gibt es sicher noch komplexere Varianten, aber das kriegt man sicher auch hin. DMA wird einmal konfiguriert und läuft dann selbsttätig, da gibt es also auch keinen nennenswerten OS Overhead.
Ich nutze einen eigenen Abstraktionslayer schon seit mehreren Jahren. Natürlich lassen sich über verschiedene Mikrocontrollerfamilien nur Grundfunktionen abbilden und meist wird nur ein Teil der existierenden Typen genutzt. Zudem ziehe ich neue Funktionen nicht sofort bei allen (derzeit 18) verschiedenen unterstützten Controllerfamilien nach, das bekomme ich von der Zeit her gar nicht hin. Und natürlich gibt es Einschränkungen, bei den festen Pin-Funktionen, die ich auf minimale Überschneidung hin ausgewählt habe, bei den Quarzfrequenzen, wo ich meist nur 8 und 16MHz unterstütze, das Fehlen von DMA-Unterstützung... Aber das Ganze hat einen grossen Vorteil: da die Low-Level Routinen eine identische Schnittstelle haben, lassen sich darauf komfortabel Highlevel-Routinen aufsetzen. Und das geht soweit, dass die Highlevel-Routinen nur als Symlinks in die Source-Trees der einzelnen Bibliotheken eingebunden sind. Und ein neues Projekt ist schnell aufgesetzt, denn die Kombination aus Bibliothek, Header-Files, Linkerscript und Makefile lasse ich mir automatisch generieren und mit meinem Universalprogrammer reicht ein "make prog" und der Code ist im Controller gelandet. Jörg
Johannes S. schrieb: > Prinzipiell macht DMA ja immer das Gleiche, es gibt Quelle und Ziel, > Anzahl Wörter, Wortgrösse, Schrittweite und evtl. weitere als gemeinsame > Parameter Oje, relevant ist, wann der Transfer getriggert wird, da möchte man 'Ende der A/D Wandlung beim ADC Register', '2us nach PinChange rising edge irgendeines PortPins beim Portzugriff', 'TimerCompareMatch bei kopieren in den Displayspeicher', und was noch alles. Ebenso wann DMA das Ende signalisieren soll: gar nicht, nach x Transfers, nach Transfer des Wertes 0xFF, bei leerem SPI Register obwohl der Timer einen Transfer angestossen hat' und die wenigsten uC können das alles. Klar, stumpf von A nach B kopieren kann jede DMA.
die Trigger werden aber nicht im DMA, sondern in der Peripherieeinheit konfiguriert. Sicher ist DMA mit vielen Features eine anspruchsvollere Aufgabe. In z.B. ChibiOS finde ich sowas auch nicht, aber trotzdem gibt es da Teillösungen.
>Denn immer daran denken: Der wertvolle Code, in dem das Know-How sitzt, >ist die Applikation/Anwendung und eben genau nicht die Anpassung an >einen bestimmte Hardware. Aber die Applikation bedient oft ganz spezielle Hardware(Peripherie) (die mit Standard-Funktionen nicht bedient werden kann), also sitzt da das Know-How ja genauso drin. >Aber das Ganze hat einen grossen Vorteil: da die Low-Level Routinen eine >identische Schnittstelle haben, Periph.Register innerhalb einer MCU-Familie haben meist (jedenfalls was Grundfunktionen betrifft) auch gleiche Bedeutung (Bits-Bedeutung usw sind gleich und sitzen an gleicher Stelle) > Prinzipiell macht DMA ja immer das Gleiche, es gibt Quelle und Ziel, > Anzahl Wörter, Wortgrösse, Schrittweite und evtl. weitere als gemeinsame > Parameter Wie oben schon genannt gibt es etliche Spezial-Einstellungen dazu. Zudem hängen diese (zusätzl. zum DMA) auch noch von den Periph.Einheiten ab, was die Sache nochmals umfangreicher macht. Das sind wohl 1000e Varianten, um das DMA zu bedienen, die man fakt. nicht alle abstrahieren kann; es ist einfach zu speziell (und grade hier gibt/gäbe es extrem grosse Fehlermöglichkeiten).
Selbst innerhalb der STM32 Serien gibts ja schon verschiedene DMA und ein STM32H7 hat 3 unterschiedliche gleichzeitig! (dazu zähle ich jetzt nicht integrierte DMA wie bei Ethernet und USB) Auf Arbeit haben wir das mit C++ gelöst und einem DMA Interface. Das wird dann pro DMA Ausprägung implementiert (viel ist das nicht). Es kann auch vorkommen, dass zB eine UART Periph (die neuere mit den 32Bit Registern) und 2 STM32 Serien verbaut wird mit unterschiedlichen DMA. Auf dickeren MCUs ala Cortex-A läuft das auch.
Experte schrieb: > Denn immer daran denken: Der wertvolle Code, in dem das Know-How sitzt, > ist die Applikation/Anwendung und eben genau nicht die Anpassung an > einen bestimmte Hardware. Dein Wort nicht nur in Gottes Ohr, sondern in möglichst alle Ohren all der Leute, die einmal Ingenieure werden wollen. Ich predige das hier schon seit gefühlten 100 Jahren und es gibt noch immer Leute, die genau dieses partout nicht verstehen wollen oder können. Und dann gibt's noch Leute, die rein garnichts verstehen: Mw E. schrieb: > Der W.S. hat mal wieder nicht verstanden was ein DMA ist und warum die > I2C der STM32 automatisch das Stopbit reinbaut. Ein I2C-Core per DMA. GRÖHL... Du bist ein Depp. Punkt. Der Knackpunkt ist, daß besagter Core VORHER wissen will, wieviele Bytes man zu übertragen gedenkt, was einer Software-Architektur mit Lowlevel-Treibern und darüber sitzenden "HiLevel"-Algorithmen komplett in die Quere kommt. Einen Treiber geht es grundsätzlich nichts an, wieviele Bytes man zu senden oder zu empfangen gedenkt. Das ist alleinige Obliegenheit der Algorithmen. Dieser Anspruch des I2C-Cores ist ein Showstopper. Und Stefan hat es auch nicht geschnallt, allerdings aus anderen Gründen: Stefan ⛄ F. schrieb: > Schonmal was von DMA gehört? Ach ich vergaß, dass geht in einem > universellen Framework ja auch wieder nicht, weil DMA bei jedem > Controller anders funktioniert - wenn überhaupt. Wozu DMA, wenn der Treiber nicht wissen kann, welcher Algorithmus ihn gerade benutzen will, um mit einem der Geräte am I2C irgend etwas anzustellen und wieviele Bytes dafür zu übertragen sein werden? Mehmet K. schrieb: > Wenn ich so Deine Beitraege mir anschaue, scheinst Du zwischen den > MCU-Herstellern wie ein Schmetterling von einer Blüte zur anderen zu > flattern. Nein, so ist das nicht. Aber ich als Geräteentwickler tue das nun schon seit langer Zeit und eben mit den unterschiedlichsten Plattformen. Das ist geräteabhängig - und wenn man seine Brötchen damit verdienen will, sind Scheuklappen das falscheste was man sich antun kann. OK, manche Plattform ist im Laufe der Zeit obsolet geworden, z.B. die µC von NEC, später dann auch die µC von Fujitsu, aber das ist ja nur ein Teilaspekt ohne Berücksichtigung aller anderen Dinge wie Gehäuse, Spezialteile, Analogtechnik, Displays und und und. Das Bild vom Schmetterling mißfällt mir da sehr, denn es unterstellt, daß man nur aus Lust und Laune herumflattert. Nee, das ist alles ernste Arbeit für jemanden, der Investgüter entwickelt, die auch nach 10 Jahren noch gepflegt sein wollen. Und eines weiß ich: gerade verfahrenstechnische Algorithmen sind das, was den Wert ausmacht - die Rechentechnik dazu, ob nun Z80, embeddedPC, 78K4 oder FR30 oder ARM7TDMI oder Cortex-M oder sonstwas ist nur quasi der Fußabtreter, auf dem das Ganze funktionieren muß. Das sollten sich die Programmierer unter uns mal merken. Und die jeweilige chipinterne Peripherie ist ebenso zweitrangig, denn die Elektronik rings herum um den µC ist das, wo die eigentliche Musike spielt - von solchen Dingen wie Mechanik und Optik ganz abgesehen. W.S.
W.S. schrieb: > Und dann gibt's noch Leute, die rein garnichts verstehen: > Mw E. schrieb: >> Der W.S. hat mal wieder nicht verstanden was ein DMA ist und warum die >> I2C der STM32 automatisch das Stopbit reinbaut. > > Ein I2C-Core per DMA. GRÖHL... Du bist ein Depp. Punkt. I2C ist ein Paradebeispiel für DMA ;) Selbst mit 400kHz doch recht langsam und braucht ne Statemachine. Könnt man jetzt mit IRQs machen, aber ein gewisser W.S. flennt ja schon rumm wenn man Tastenentprellung mit ein paar 100Hz IRQ veranstaltet. 400kHz sind ne IRQ Freqenz von mal eben so 44kHz, also schon recht anspruchsvoll. Mit pollen is dann direkt ne Weile dicht. Mit DMA: fire and forget. Btw: Wenn du nicht weist wie lang ein Transfer ist, dann ist dein Bufferhandling für die Tonne, nichts anderes ;) Das führt dann immermal zu netten Bufferoverflows wenn man nicht weis wies geht. Aber ja sicher, alles Geisterfahrer auf der Autobahn, nur du nicht ;) Wer Funktionen schreibt wie "uart1_init", "uart2_init", "uart3_init" und das auf MCUs mit 6 UARTS+ sowie mit Magic Numbers auf Registern rumklimpert anstatt mal ordentliche defines/enums/CMSIS zu nutzen. Ja der ist ganz weit weg auch überhaupt ein Wort über Softwarearchitektur reden zu DÜRFEN. Die Sache mit der libc Verteufelung ist auch göttlich, das setzt dem Ganzen noch den Hut auf. W.S. schrieb: > Ich predige das hier schon seit gefühlten 100 Jahren und es gibt noch > immer Leute, die genau dieses partout nicht verstehen wollen oder > können. Ja predigen triffts gut. Du spamst hier seit Ewigkeiten das Forum mit immer derselben Grütze zu, die schon X-Mal widerlegt wurde! Viele deiner Texte sind offensichtlich Kopierpaste. -> Hau einfach mal ab ;)
:
Bearbeitet durch User
Bezüglich "serielle Schnittstellen" war doch mal was... printf(...) scanf(...) welche auf filehandles operieren, also komplett wegabstrahiert von ttys. Auch streams werden egal was sie darstellen immer mit den Operatoren << und >> beackert. Ob dann darunter noch DMA, TCP or whatnot werkelt ist schoen gekapselt. Könnte also alles auch über I2C, SPI, TWI & co gestülpt werden. Das waer doch was in uCs... Letztlich hatten PDP10 und PDP11, wodrauf Unix entwickelt wurde, doch nicht nennenswert andere Ressourcheneinschränkungen wie so ein heutiger Arduino (gerne auch ein 8bitterer, jedenfalls deutlich weniger Ressourcen als so ein 32bittiger) Fuzix, vllt.?
I2C ist schnarch-langsam, was regt man sich drüber auf? (muss da immer an ne Grossmutter denken, die am Stricken ist) >400kHz sind ne IRQ Freqenz von mal eben so 44kHz, also schon recht >anspruchsvoll. Ja bei ein paar zig us INT-Cycl kann man schon überlegen, die CPU zu entlasten. (Kommt aber auf den Controller an, manche (ev. mit 2. Reg.Bank) können INT u. Context-Switch mit nur wenigen Takten) >Btw: Wenn du nicht weist wie lang ein Transfer ist, dann ist dein >Bufferhandling für die Tonne, nichts anderes ;) HEHE. Dann kann mans auch nicht mittels CPU programmieren. >Mit DMA: fire and forget. Ui, das stimmt nicht ganz. Auch DMA frisst eine gewisse CPU-Leistung.
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.