Hallo, ich habe schon ein paar Projekte mit STM32er Controllern durchgeführt, bin aber kein Profi. Da die es für manche Prozessoren keine Std.lib mehr gibt und ich gerade etwas Zeit habe, wollte ich generell auf CubeMx und HAL umsteigen (bitte keine Diskusionen). Ich fand bzgl. der Std.lib http://www.diller-technologies.de/stm32.html super für den Einstieg und habe aber leider kein ähnliches Tutorial für HAL gefunden. - Kennt jemand so ein Tutorial, was einen relativ einfach und schnell ranführt? - Gäbe es Interesse, wenn ich selbst eins verfasse? Ich bin zwar kein Profi und muss mir alles auch erarbeiten, aber vielleicht hilft das gerade Einsteigern. Fehler könnten ja korrigiert werden. Bitte um Tipps für ein Tutorial, oder Meinungen. Grüße Jan
Die HAL User-Manuals kennst du bereits? Für F1xx: https://www.st.com/content/ccc/resource/technical/document/user_manual/72/52/cc/53/05/e3/4c/98/DM00154093.pdf/files/DM00154093.pdf/jcr:content/translations/en.DM00154093.pdf
Wozu willst du selbst ein Tutorial schreiben, wenn du bzgl. HAL von Tuten und Blasen keine Ahnung hast? Das wird sich keiner durchlesen, wobei es auch ein richtiges Manual gibt. PS: Nutzt CMSIS! Ich bin dann mal weg ;) ..
>Wozu willst du selbst ein Tutorial schreiben, wenn du bzgl. HAL von Tuten und
Blasen keine Ahnung hast
Das war sicher mehr als "Zusammenfassung/Einführung" gemeint als ein
vollwertiges Tutorial, damit sich Einsteiger beim Thema HAL nicht so
schwer tun und eine Orientierung bekommen.
Dreikommaeinsvier schrieb: > Noob hilft anderen Noobs. Das prinzipiell nicht schlecht, denn der Noob weist auch Dinge hin, die man beachten muss, welche erfahrene Entwickler für selbstverständlich halten. Der Noob findet auch heraus, was man aktuell alles machen muss, um die Software an laufen zu bringen, während der erfahrene Entwickler typischerweise auf eine mehrere Jahre altes Setting aufbaut. Für die HAL würde ich mich aber nicht abrackern Zum einen, weil ich sie doof finde und zum anderen, weil ST sie bereits Anfängertauglich dokumentiert hat. Ein Hello-World Programm klickt man sich zu 99% schnell mit Cube-MX zusammen - was will man mehr?
Stefanus F. schrieb: > weil ich sie > doof finde Sehr fundiert, sehr sachlich. Bist auch ein Noob, nicht wahr! :-[
labertaschen schrieb: > Stefanus F. schrieb: >> weil ich sie doof finde > > Sehr fundiert, sehr sachlich. Bist auch ein Noob, nicht wahr! :-[ Ich habe hier schon oft genug erklärt, wie ich zu dieser persönlichen Meinung komme. Muss ich nicht nicht schon wieder breit treten. Die Leute die das gerne ausdiskutieren, kennen meine Argumente bereits. Die anderen interessiert es nicht.
Harry L. schrieb: > Die HAL User-Manuals kennst du bereits? > > Für F1xx: > https://www.st.com/content/ccc/resource/technical/document/user_manual/72/52/cc/53/05/e3/4c/98/DM00154093.pdf/files/DM00154093.pdf/jcr:content/translations/en.DM00154093.pdf Kenne ich. Für mich ist das was zum Nachschlagen, aber ich könnte damit kein CAN ans laufen bekommen. Jens schrieb: > Wozu willst du selbst ein Tutorial schreiben, wenn du bzgl. HAL von > Tuten und Blasen keine Ahnung hast? Das wird sich keiner durchlesen, > wobei es auch ein richtiges Manual gibt. > > PS: Nutzt CMSIS! Ich bin dann mal weg ;) .. CMSIS nutzt man dann doch auch. Ich würde mir das erarbeiten und mitschreiben. Stefanus F. schrieb: > Für die HAL würde ich mich aber nicht abrackern Zum einen, weil ich sie > doof finde und zum anderen, weil ST sie bereits Anfängertauglich > dokumentiert hat. Ein Hello-World Programm klickt man sich zu 99% > schnell mit Cube-MX zusammen - was will man mehr? Ich denke zu HAL gibt es keine wirkliche Alternative, wenn es das einzige ist was zur Verfügung gestellt wird. Auf Register einzeln schubsen ist mir auch meine Hobby Zeit zu schade. Stefanus F. schrieb: > weil ST sie bereits Anfängertauglich > dokumentiert hat. Das würde mich noch interessieren, wo ich das finde. Danke für euer Feedback. Dann mache ich das nur für mich, geht dann eh schneller. Der Umgangston und Umgangsweise in diesem Forum ist eh so schlecht wie sonst nirgenwo. Eigentlich total schade, da es hier echt Leute mit Ahnung gibt. Lieben Gruß Jan
ChibiOS hat eine eigene schöne HAL die unabhängig ist. Man muss nicht das RT davon nutzen. Die HAL ist lizenztechnisch auch komplett frei.
Stefanus F. schrieb: > Die Leute > die das gerne ausdiskutieren, kennen meine Argumente bereits. Die > anderen interessiert es nicht. ... und wer nicht für mich ist, ist gegen mich! Komischer Zeitgenosse du bist.
labertaschen schrieb: > ... und wer nicht für mich ist, ist gegen mich! > Komischer Zeitgenosse du bist. Genau Gegenteil davon propagiere ich. Unterschiedliche Meinungen sind Ok, es besteht keine Notwendigkeit, zu einem gemeinsamen Konsens zu kommen. Wer die HAL mag, darf sie benutzen. Wer sie nicht mag, muss sie nicht benutzen.
habe ich schon mal erwähnt das Mbed auch sehr gut geeignet ist um die STM32 (und viele andere Cortex-M) einfach zu programmieren? Ein einheitliches objektorientiertes API für viele Cortex-M, für die STM32 wird dafür intern die HAL genutzt. Die Standardschnittstellen DigitalIn/Out, AnalogIn/Out, SPI, I2C, CAN uvm. sind als Basis vorhanden und man muss sich nicht mit dem HAL API quälen. Wenn spezielle Hardware wie FSMC, SDIO, Graphic genutzt werden möchten kann das immer noch über Cube generierten Code oder die STM Board Support Packages dazu gebaut werden. Dazu bietet Mbed ein Kommandozeileninterface über das Projekte ohne Konfigurationsaufwand angelegt, kompiliert und geflasht werden können.
Johannes S. schrieb: > habe ich schon mal erwähnt das Mbed auch sehr gut geeignet ist Noch ein weiteres Framework über dem Framework entpuppt sich schnell als Sackgasse, sobald mal etwas nicht wie gewünscht funktioniert. Dann muss man sich plötzlich intensiv mit beiden Frameworks beschäftigen, um den Code anzupassen bzw. den Fehler erst einmal zu verstehen.
Das wird aber von den Mbed Machern und auch STM exzessiv getestet. Es ist nicht wie bei Arduino.cc die mit der STM Umsetzung des API nix zu tun haben. Und die HAL ist STM und nur für diese verfügbar, das Mbed API gibt es auch für LPC, Kinetis, Nordics nRF, Atmel SAM uvm. Die Panik mit 'Framework über Framework' ist Quark. Beim PC interessiert micht auch nicht ob ein Intel oder AMD drinsteckt, die SW soll unabhängig davon laufen. Und genau das kann man heute auf einem µC auch erreichen. Ja, die Performance... Laste einen F4 mit 168 MHz erstmal aus, dann können wir weiter reden. Für meinen Heizkreisregler mit LPC1549 habe ich an einem WE den Rumpf mit RTOS, PID Regler Task mit Ni1000 RTD, Kommandointerpreter über serielle Schnittstelle und Messwertübertragung per CAN hinbekommen. Alternativ kann ich das auf einem STM laufen lassen. Das sind Vorteile die zählen.
Johannes S. schrieb: > Das Mbed API gibt es > auch für LPC, Kinetis, Nordics nRF, Atmel SAM uvm. Das ist natürlich ein starker Vorteil - solange es funktioniert.
Es funktioniert sehr gut und immer besser weil da ein professionelles Team dran arbeitet. Es werden Unmengen an Tests gemacht, angefangen mit CI für PRs, automatisierten Tests und Unittests sowie strengen Reviews für die PR. MBed ist aus einem Guss, wenn eine Änderung gemacht wird wird trotzdem für andere Targets mitgestet. Natürlich passieren da trotzdem noch Fehler, aber die werden alle Ernst behandelt, in den letzen zwei Jahren hat sich dss genial weiterentwickelt. Ich kann es immer wieder nur empfehlen.
Jan schrieb: > Harry L. schrieb: >> Die HAL User-Manuals kennst du bereits? >> Für F1xx: >> > https://www.st.com/content/ccc/resource/technical/document/user_manual/72/52/cc/53/05/e3/4c/98/DM00154093.pdf/files/DM00154093.pdf/jcr:content/translations/en.DM00154093.pdf > > Kenne ich. Für mich ist das was zum Nachschlagen, aber ich könnte damit > kein CAN ans laufen bekommen. Vielleicht keinen CAN-Bus (das kommt auf dein Vorwissen bezüglich CAN im Allgemeinen an) aber doch zumindest SPI oder einen UART. Zu jedem Peripheriebaustein gibt es einen Abschnitt "How to use this driver". Dies in den Unmengen von autogenerierter Doku zu finden ist die eigentliche Kunst ;)
https://leanpub.com/mastering-stm32 Kauf dieses Buch es ist jeden Cent wert! Viele anschauliche beispiel mit Erklärung der Prinzipien.
Johannes S. schrieb: > habe ich schon mal erwähnt das Mbed auch sehr gut geeignet ist um die > STM32 (und viele andere Cortex-M) einfach zu programmieren? Ein > einheitliches objektorientiertes API für viele Cortex-M, für die STM32 > wird dafür intern die HAL genutzt. Die Standardschnittstellen > DigitalIn/Out, AnalogIn/Out, SPI, I2C, CAN uvm. sind als Basis > vorhanden und man muss sich nicht mit dem HAL API quälen. Wenn spezielle > Hardware wie FSMC, SDIO, Graphic genutzt werden möchten kann das immer > noch über Cube generierten Code oder die STM Board Support Packages dazu > gebaut werden. > Dazu bietet Mbed ein Kommandozeileninterface über das Projekte ohne > Konfigurationsaufwand angelegt, kompiliert und geflasht werden können. Nun bin ich ja mal neugierig geworden. Folgendes Programm erzeugt auf einem LPC1549 sage und schreibe 10428 byte (DEBUG-build), wenn ich es in MCUXpresso importiere (und 10104 byte im RELEASE-build):
1 | #include "mbed.h" |
2 | |
3 | DigitalOut myled(LED1); |
4 | |
5 | int main() { |
6 | while(1) { |
7 | myled = 1; |
8 | wait(0.4); |
9 | myled = 0; |
10 | wait(0.4); |
11 | }
|
12 | }
|
Und schrittweise debuggen geht da auch nicht, weil das als libs/object-Dateien vorliegt. Mache ich da gerade einen Anfängerfehler oder ist der Gedanke eher der, daß das niemanden etwas angeht und die libs schon funktionieren und nicht debuggt werden können müssen?
Lutz schrieb: > Mache ich da gerade einen Anfängerfehler Ja, du erwartest kompakten Code auf Mikrocontrollern. Wir erleben gerade die Wende, wo das bald nicht mehr gilt. Mbed ist das neue Arduino, nur will man damit die Profis bedienen. Auch bei Android beobachte ich diesen Wechsel. Noch kann man den ganzen Ballast, den das Android Studio in deine Programme einbaut wieder entfernen. Aber ich denke, bald werden diese Komponenten zum Pflichtfaktor. Auf dem PC Markt haben wir uns längst daran gewöhnt, das selbst minimale Hello-World GUI Programme nicht mehr 15kB sondern 150kB gross sind und zusätzliche eine Laufzeitbibliothek von einigen hundert MB mit sich herum schleppt. Gerade noch gab Volkswagen öffentlich zu, dass sie keine Ahnung haben, wie ihre Software funktioniert. Ähnliches habe ich auch bereits persönlich von SAP gehört.
Lutz schrieb: > Folgendes Programm erzeugt auf > einem LPC1549 sage und schreibe 10428 byte (DEBUG-build), wenn ich es in > MCUXpresso importiere (und 10104 byte im RELEASE-build) Das liegt daran, dass im Hintergrund ein komplettes RTOS eingebunden wird, was mehrere kB benötigt. Genaueres findest du unter https://github.com/adamgreen/gcc4mbed/blob/master/notes/size_analysis.creole#analyzing-firmware-size Lutz schrieb: > Und schrittweise debuggen geht da auch nicht, weil das als > libs/object-Dateien vorliegt. Mache ich da gerade einen Anfängerfehler > oder ist der Gedanke eher der, daß das niemanden etwas angeht und die > libs schon funktionieren und nicht debuggt werden können müssen? Das liegt daran, dass du das Projekt aus der Online-IDE exportiert hast. Dann werden leider nur Objects exportiert. Warum weiß ich auch nicht und finde es auch ziemlich dämlich. Wenn du ein neues Projekt mit dem mbed-cli erstellst hast du die Source-Dateien und kannst auch debuggen.
Lutz schrieb: > Nun bin ich ja mal neugierig geworden. Folgendes Programm erzeugt auf > einem LPC1549 sage und schreibe 10428 byte (DEBUG-build) Wie hast du das Projekt erzeugt, über den Online Compiler und dann exportiert? Dann bekommst du ein Mbed2 mit vorkompilierter Lib die sich schwieriger debuggen lässt. Die Quellen zu Mbed2 findet man unter mbed-dev, ein Projekt mit dem mbed-cli anlegen geht dann so:
1 | mbed new . --mbedlib |
2 | mbed add https://os.mbed.com/users/mbed_official/code/mbed-dev/ |
3 | mbed compile -m LPC1549 -t GCC_ARM |
und der export nach MCUXpresso:
1 | mbed export -m LPC1549 -i mcuxpresso |
Mittlerweile gibt es auch wieder die Option das als zip zu exportieren mit Schalter '-z'. Da gab es nur noch einen Fehler in .tools/project.py, man kann zwei Zeilen mit 'notify.info' mit # auskommentieren und dann geht das. Beim LPC1549 war noch ein Fehler im Linkerfile, mein PR mit dem fix ist vor ein paar Tagen übernommen worden: https://github.com/ARMmbed/mbed-os/pull/8978/files Das binaray hat seine Grösse weil ein OS natürlich einen Overhead mitbringt, in deinem Beispiel die DigitalOut Klasse und der Timer der sowieso immer drin ist. Dafür ist das schon ein Stück Komfort und gerade der Timer ist da gut implementiert. Der LPC1549 hat genug Speicher um auch das mbed-os (Mbed5) zu nutzen. Das ist die aktuelle Entwicklung, die Änderungen für Mbed2 werden noch mit Verzoögerung nachgezogen aber inrgendwann wird das sicher eingestellt. Mbed2 ist für kleine µC besser und man kann die newlib-nano unter gcc verwenden, das mbedö-os enthält das RTOS und die Nanolib ist nicht threadsafe, deshalb ist da die volle newlib drin. Ich benutze den LPC1549 auch mit mbed-os, der hat 256 kB Flash und da jucken mich die +20 kB nicht. Dafür muss man in der target.json die release Einstellung anpassen:
1 | "release_versions": ["2", "5"], |
Christopher J. schrieb: > Genaueres findest du unter > https://github.com/adamgreen/gcc4mbed/blob/master/notes/size_analysis.creole#analyzing-firmware-size das gcc4mbed von Adam Green ist aber nicht mehr aktuell und scheinbar auch nicht mehr weitergepflegt, war ein abgespeckter Fork für gcc. Besser das 'originale' mbed von ARM benutzen. Wenn man in der Kommandozeile mit 'mbed compile' übersetzt bekommt man eine Statistik ausgeworfen was wieviel Speicher braucht, wird aus dem mapfile erzeugt. Da gibt es noch einen Schalter mit dem man den Level der Ausgabe detailierter stellen kann, der ist aber noch nicht dokumentiert, müsste ich raussuchen. Christopher J. schrieb: > Warum weiß ich auch nicht und > finde es auch ziemlich dämlich. Es gab die Möglichkeit mit Rechsklick in der Online IDE auf der mbed-lib die in die Quellen umzuwandeln, dann wurden die auch exportiert. Aber da das mbed so stark gewachsen ist dauerte das ewig und ist wohl rausgeflogen. Man kann aber auch im Online Compiler die lib löschen und das mbed-dev importieren. Aber mit dem mbed-cli geht das mittlwerweile alles besser, den Online Compiler benutzte ich auch nur noch in seltenen Fällen. Das ist der Keil Compiler, für Cortex-M0 erzeugt der immer noch kompakteren Code als der gcc der für M0 schlecht optimiert.
Online IDE? Das wird ja immer grauenvoller! Wo die Reise hingeht gefällt mir ganz und garnicht, wie kann ich mein Ticket umtauschen?
Mw E. schrieb: > Online IDE? > Das wird ja immer grauenvoller! Die Online IDE gibt es mittlerweile schon an die 10 Jahre und funktioniert immer noch. Mbed wurde von zwei ARM Mitarbeitern ins Leben gerufen und war als Ausbildiungssystem gedacht. Da die Schulen keine fetten Computer und spezielle Programmierhardware hatten waren die Säulen der Idee ein Online Compiler der im Browser läuft und keine lokale Installation benötigt und ein Bootloader der das binary File vom Webbrowser direkt per USB auf den Controller flashen kann. Um die leistungsfähige ARM HW zu programmieren war also nur ein USB Kabel nötig. Die Idee war leider der Zeit vorraus, die Hobbyprogrammierer hielten die AVR für völlig ausreichend und das etwas einfachere Arduino mit einem ähnlichen Ansatz wurde viel populärer. Mbed wurde weiter ausgebaut, das HDK mit dem Zusatzprozessor für die Programmierung über USB wurde offengelegt und zu dem Urvater LPC1768 kamen weitere Targets hinzu. Das dümpelte so vor sich hin bis vor zwei Jahren etwa massiv daran weitergearbeitet wurde. Einmal um es in den IoT Bereich zu pushen und jetzt auch für professionelle Anwendungen. Da gibt es jetzt eine Seite mit Anwendungen mit Mbed: https://www.mbed.com/built-with-mbed/ und ARM bietet Unterstützung für die Umsetzung mit Mbed an. Es ist aber OpenSource und unter Apache 2.0 Lizenz und darf auch kommerziell verwendet werden, da profitiere auch ich als Hobbyanwender sehr davon das es sich so gut weiterentwickelt. Und auch wenn der Online Compiler immer noch funktioniert, die aktuelle Entwicklung setzt sehr auf das mbed-cli. Einem Kommandozueilen Interface wo man mit wenigen Befehlen alles nötige machen kann. Auch die Projektdateien für eine IDE erzeugen. ARM arbeitet auch an einer eigenen IDE, aber da gibts noch nix öffentliches. Ich benutze jetzt viel VSCode und darin Tasks die das mbed-cli aufrufen und mit der Extension Cortex-Debug auch debuggen kann. Da geht die Reise hin.
Johannes S. schrieb: > Wie hast du das Projekt erzeugt, über den Online Compiler und dann > exportiert? Ja. Mit RTOS usw. ergibt die Größe dann schon einen Sinn. Wobei man das "online" nicht einstellen kann, nun ja. Und online werden nur object-files exportiert, ebenso nun ja. Wegen traffic etwas nachvollziehbar, aber dann sollte es schon eine Mechanismus geben, der bei Auswahl/wenn explizit gewünscht die Quellen aus dem offlinebereich/lokale Platte holt. > Dann bekommst du ein Mbed2 mit vorkompilierter Lib die sich > schwieriger debuggen lässt. Die Quellen zu Mbed2 findet man unter > mbed-dev, ein Projekt mit dem mbed-cli anlegen geht dann so: > mbed new . --mbedlib Jetzt habe ich plötzlich 2,8 GB mehr auf der Festplatte, vielen Dank... > mbed add https://os.mbed.com/users/mbed_official/code/mbed-dev/ Timed out, "unable to to clone repository" Auf etwas anderem Weg hatte ich heute Mittag auf die Schnelle was installiert. > mbed compile -m LPC1549 -t GCC_ARM Da kam dann "[Warning] @,: Compiler version mismatch: Have 7.3.1; expected version >= 6.0.0 and < 7.0.0". Der mag den Compiler vom mcueclipseplugin nicht, da zu neu??? Müßte 2018q2 sein. Vor 3 Tagen ist sogar 2018q4 rausgekommen. Schade, ich dachte mal auf die Schnelle eine Toolchain zum Zusammenklicken von Komponenten und Boards die ich habe, aber war wohl (zumindest so) nix.
Lutz schrieb: > Jetzt habe ich plötzlich 2,8 GB mehr auf der Festplatte, vielen Dank... Es ist das ganze Paket für alle unterstützten Targets, das ist schon recht gross geworden. Aber das sollte im Zeitalter grosser Festplatten kein Problem sein. Lutz schrieb: > Da kam dann "[Warning] @,: Compiler version mismatch: Have 7.3.1; > expected version >= 6.0.0 and < 7.0.0". es ist mit den gcc 6-7 getestet. Bei anderen Compilerversionen kann es Probleme geben, in den meisten Fällen aber nicht. Die Tests sind sehr aufwändig und werden nicht sofort mit den neuesten Versionen gemacht. Ich benutze aber auch einen neueren und habe bisher keine Probleme bekommen. Ebenso funktioniert es mit neueren C++ Standards, aber da gcc + Keil * IAR unterstützt werden ist das nicht offiziell freigegeben.
Ich empfehle ebenfalls die HAL von Chibios, die ist effizient und wirklich sauber durchgezogen, inkl. Treiber für alles was das Herz begehrt! http://www.chibios.org/dokuwiki/doku.php?id=chibios:product:hal:start Zum einsteigen am besten gleich ChibiStudio downloaaden, auf C:\ entpacken und loslegen. Hat ganz viele Beispiele, da ist fast jedes Board schon vertreten.
Johannes S. schrieb: > Lutz schrieb: >> Jetzt habe ich plötzlich 2,8 GB mehr auf der Festplatte, vielen Dank... > > Es ist das ganze Paket für alle unterstützten Targets, das ist schon > recht gross geworden. Aber das sollte im Zeitalter grosser Festplatten > kein Problem sein. Das nicht, aber es muß ja auch runtergeladen werden. Im Flatratezeitalter im Hintergrund auch fast egal, aber man sollte zumindest per Haken auswählen können, welche targets man haben will. Ich brauche von den 2,8 GB gerade mal 7,4 MB für mein target! Ich hab's gerne effektiv. Ich muß da wohl zwischen den Tagen noch mal kurz nachschauen, wo es bei mir hakt.
>> Ich empfehle ebenfalls die HAL von Chibios, > >Ist wohl fast nur für STM32. STM32 ist fast vollständig, hat aber auch Beisppielprojekte für AVR, LPC21xx, SPC5 und ARM (generic) für eigene Portierungen.
Es ging ja um STM32 und... Jan schrieb: > Ich denke zu HAL gibt es keine wirkliche Alternative, wenn es das > einzige ist was zur Verfügung gestellt wird. Auf Register einzeln > schubsen ist mir auch meine Hobby Zeit zu schade. Daher habe ich ChibiOS in den Raum geworfen. Weil ChibiOS ohne RTOS auch eine eigene alternative zur HAL hat. Ohne Balast.
Jan schrieb: > Ich denke zu HAL gibt es keine wirkliche Alternative, wenn es das > einzige ist was zur Verfügung gestellt wird. Auf Register einzeln > schubsen ist mir auch meine Hobby Zeit zu schade. Fürs Bitschubsen musst du nur as RefMan lesen. Für den HAL darfste RefMan und die gruselige HAL Doku lesen. Zudem ist die Peripherie jetzt nicht so schwer zu verstehen.
Mw E. schrieb: > Fürs Bitschubsen musst du nur as RefMan lesen. > Für den HAL darfste RefMan und die gruselige HAL Doku lesen. > Zudem ist die Peripherie jetzt nicht so schwer zu verstehen. Genau meine Meinung. Allerdings wirst du damit die Ohren der meisten nicht mehr erreichen. Es macht sich heute keiner mehr Gedanken wie viel Softwareschichten verwendet werden, hauptsache schnell zusammengenagelt. Eines der krassesten Beispiele dafür ist nodejs. Um ein Byte über die serielle Schnittstelle zu schubsen kann man wunderschön serialport verwenden. Und wie der Blitz erzeugt ein Aufruf von "npm install serialport" 587 Dateien in 129 Verzeichnissen die ab jetzt zum Projekt gehören. Das ist krank in meinen Augen. Auch wofür man für die einfachsten Sachen auf dem µC eine HAL-Schicht dazwischen braucht erschließt sich mir nicht. Was am Anfang einfach ist, ist am Ende doppelter Aufwand für Code und Verständnis. Und wenn man wirklich alle Spezialfälle der Baugruppen benutzen will, wird es sowieso nichts mehr mit der Hardwareunabhängigkeit. Die fetten Bestandteile wie z.B. USB und Ethernet lassen sich noch am ehsten auf eine gemeinsame High-Level-Schicht abbilden. Beim ADC und den Timern hört der Spaß aber auf wenn man mehr will als das was Arduino oder mbed bieten.
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.