Hallo. Wie mir letztens aufgefallen ist, weiß ich in Sachen Bibliotheken und API nahezu gar nicht bescheid. Ich habe nicht mal mitbekommen das es sowas wie APIs gibt :D. Wo kann man sich da schlau machen. Erstaunlicherweise konnte ich im Forum hier nichts finden. Gibt es APIs die übergreifend für mehrere Hersteller sind? Wo ist eigentlich der genaue Unterschied zwischen APIs und Bibliotheken? Wenn ich mir bei ST z.b. die HAL Bibliotheken anschaue ist das doch quasi wie ne Bibliothek. Wann wendet man HAL und Wann Low Layer API´s an? Welche Bibliotheken muss man kennen? Gibt es irgendwelche Standard-Bibliotheken? Bisher war mir nur die AVR Standard Library bekannt. Sonst nix. Ich kannte bisher nur Github um nach speziellen Bibliotheken für Arudino zu suchen. Danke Steffen.
Wenn du AVR in C/C++ programmierst, führt praktisch kein Weg an der avr-lib vorbei. Wenn du ARM Controller programmierst, solltest du die CMSIS-Core Library kennen, die ist dort von ARM als Standard vorgegeben. Darin befinden sich die Definitionen der Register und eine Hand voll Funktionen für den ARM Kern. Darauf aufbauend kommt dann die newlib Library von RedHat - die beim arm-gcc verwendet wird. Es gibt aber auch andere - Keil hat eine eigene libc, soweit ich weiß. Darauf bauen die meisten anderen Libraries auf. Ob und wann du die HAL von ST oder die ASF von Microchip verwenden möchtest, bleibt Dir selbst überlassen. Was sonst noch oft vorkommt: RTOS und lwip Ich denke, damit hast du erstmal die wichtigsten Sachen zusammen. Aber verlasse Dich nicht zu sehr darauf, denn irgendwann willst du vielleicht mal andere Mikrocontroller programmieren. Außerdem kommt da alle paar Jahre was neues heraus, insbesondere im HAL Bereich.
Steffen schrieb: > Wo ist eigentlich der genaue Unterschied zwischen APIs und Bibliotheken? Übersetzte einfach mal "application programming interface". Dann wird vielleicht klar, das API eine Softwareschnittstelle beschreibt. Eine Bibliothek ist dagegen eine Sammlung von Programmen.
Du solltest dir vielleicht erstmal ein paar Gedanken zu den von dir verwendeten Begrifflichkeiten machen. Das sind nähmlich alles solch Intergalaktische Begriffe die nur sehr grob eine allgemeine Funktionsart beschreiben aber nie etwas genaues oder gar irgendwas konkretes. Es ist oft nur von der laune des Erstellers abhängig welcher begriff verwendet wird (oder ggf. auch garkeiner davon). Es gibt keine "Vorschrift" über deren Verwendung. Z.B. Die WinApi beinhaltet Funktionen um irgendwas auf dem Bildschirm auszugeben. Somit ist sie theoretisch auch ein HAL für die Zugriffe auf die Graphikkarte - dennoch spricht hier keine von einer WinHal oder so. 1.) API = Application programming interface 2.) HAL = Hardware Abstraction Layer 3.) Die Standardbibliotheken einer Programmiersprache 1.) Vereinfacht: Eine Sammlung von beliebigen Funktionen die ein Programmieren einem anderen Programmierer zur Verwendung in seinen eigenen Programmen zur Verfügung stellt. Von der Definition her gibt es davon zig tausende, aber eben nicht "die API" für alles und jeden. Du musst hier also schon recht genau unterscheiden was du genau auf welchem System machen willst und was da so rundherum alles existiert. https://de.wikipedia.org/wiki/Programmierschnittstelle 2.) Das sagt erstmal nur aus das irgendwelche direkten zugriffe auf die Hardware durch eine dazwischenliegen Softwareschicht geleitet wird. Manche sind so aufgebaut das die darunterliegende Schicht unterschiedliche Hardware beinhalten kann und die darüberlegende Schicht davon nichts mitbekommt sondern alles immer gleich ansteuern kann. Es kann aber auch gut sein das die nur für genau eine Hardware passt und eben nur den direkten zugriff kapselt. Alles ist hier möglich und darf dennoch (muss aber nicht) HAL genannt werden. Also ist es am ende sehr ganau davon abhängig was du genau machen willst. https://de.wikipedia.org/wiki/Hardwareabstraktionsschicht 3.) Hier wird es im Gegensatz zu den beiden ersten Begriffen mal etwas konkreteres damit definiert. Etliche Programmiersprachen (wie z.b. C und C++) definieren in ihrer Standardisierung einen Pool von Funktionen bei dem recht genau vorgeschrieben ist wie sie sich verhalten sollen und diese nahezu unabhängig von der verwendeten Hardware, dem OS oder den Compilerhersteller. Hat also erstmal nichts mit den ersten beiden zu tun (diese werden sich intern in der Regel aber auch aus diesem Funktionspool bedienen, genauso wie nahezu jede Anwendung auch). https://de.wikipedia.org/wiki/C-Standard-Bibliothek http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf So ganz nebenbei eine API, HAL oder was auch immer lernt man nicht, man benutzt sie einfach wenn man eine Funktion daraus benötigen kann. sind ja ganz normale Funktionsaufrufe in der jeweiligen Programmiersprache, alles andere ist wie Telefonbuch auswendig lernen...
Irgendwer schrieb: > alles andere ist wie Telefonbuch auswendig lernen... Die Formulierung gefällt mir, passt total.
Wolfgang schrieb: > Übersetzte einfach mal "application programming interface". Dann wird > vielleicht klar, das API eine Softwareschnittstelle beschreibt. Eine > Bibliothek ist dagegen eine Sammlung von Programmen. Es wird aber beides nahezu gleich angewendet. Vielen Dank für das raussuchen der Definitionen. So wirklich klar ist es mir aber noch nicht Irgendwer schrieb: > Eine Sammlung von beliebigen Funktionen die ein > Programmieren einem anderen Programmierer zur Verwendung in seinen > eigenen Programmen zur Verfügung stellt. Das könnte man aber auch über eine Bibliothek sagen. Versteh mich nicht falsch. Ich will nicht kleinlich sein sondern einfach nur den Unterschied verstehen. Irgendwer schrieb: > 2.) Das sagt erstmal nur aus das irgendwelche direkten zugriffe auf die > Hardware durch eine dazwischenliegen Softwareschicht geleitet wird. > Manche sind so aufgebaut das die darunterliegende Schicht > unterschiedliche Hardware beinhalten kann und die darüberlegende Schicht > davon nichts mitbekommt sondern alles immer gleich ansteuern kann. Es > kann aber auch gut sein das die nur für genau eine Hardware passt und > eben nur den direkten zugriff kapselt. Alles ist hier möglich und darf > dennoch (muss aber nicht) HAL genannt werden. Also ist es am ende sehr > ganau davon abhängig was du genau machen willst. > https://de.wikipedia.org/wiki/Hardwareabstraktionsschicht https://www.st.com/content/ccc/resource/technical/document/user_manual/2f/77/25/0f/5c/38/48/80/DM00122015.pdf/files/DM00122015.pdf/jcr:content/translations/en.DM00122015.pdf So wie ich das bisher aus dem Manual entnehmen konnte arbeitet man bei HAL einfach unabhängig von der Hardware und bei LL arbeitet man wie man es kennt auf Hardwarebene und beschreibt die Register einzeln. Wobei man für die Beschreibung der Register dann wieder jeweils Funktionen zur Verfügung gestellt bekommt. So hab ich das zumindest bei dem HAL- und LL Teil für SPI verstanden. Das ist ja auch grob so wie du es beschreibst. Mit allgemeinen API´s meine ich sowas wie Autosar. Die ist ja auch plattformübergreifend damit man sich nicht immer umgewöhnen muss. Sowas suche im Endeffekt. Oder möchte wissen ob es sowas wie Autosar noch außerhalb der Automobilindustrie gibt. Kennt sich vielleicht jemand genauer mit Autosar aus? Vielen Dank für eure Beiträge.
Steffen schrieb: > arbeitet man bei > HAL einfach unabhängig von der Hardware Leider nicht. jedenfalls nicht bei der HAL von ST. Deren Funktionen musst du in Hardware spezifischer Reihenfolge kombinieren und mit Hardware spezifischen Konstanten aufrufen. Ein Programm, dass z.B. für einen Chip aus der STM32F103 Serie geschrieben wurde, lässt nicht trotz HAL nur mit erheblichen Änderungen auf STM32F303 "upgraden" - obwohl der als sogar Nachfolger zum STM32F103 gehandelt wird.
Steffen schrieb: > Wolfgang schrieb: >> Übersetzte einfach mal "application programming interface". Dann wird >> vielleicht klar, das API eine Softwareschnittstelle beschreibt. Eine >> Bibliothek ist dagegen eine Sammlung von Programmen. > > Es wird aber beides nahezu gleich angewendet. Nein. > Irgendwer schrieb: >> Eine Sammlung von beliebigen Funktionen die ein >> Programmieren einem anderen Programmierer zur Verwendung in seinen >> eigenen Programmen zur Verfügung stellt. > > Das könnte man aber auch über eine Bibliothek sagen. > Ich will nicht kleinlich sein sondern einfach nur den > Unterschied verstehen. Die "Sammlung von Funktionen" ist die Bibliothek (Library). Das API ist die Beschreibung, welche Funktionen es gibt und wie sie zu verwenden sind. Bei Programmiersprachen, die zwischen Deklaration und Definition unterscheiden (wie z.B. C) nennt man oft die Deklaration (vulgo: ein oder mehrere Headerfiles) das API und die eigentliche Implementierung (entweder Quellcode oder Objectcode) die Library. Ich persönlich würde immer noch eine menschenlesbare Dokumentation einfordern und die mit zum API zählen. > So wie ich das bisher aus dem Manual entnehmen konnte arbeitet man bei > HAL einfach unabhängig von der Hardware Nein. Nur die allerwenigsten Teile des HAL sind wirklich unabhängig von der Hardware. > und bei LL arbeitet man wie man > es kennt auf Hardwarebene und beschreibt die Register einzeln. Das ist ein Streit um Begrifflichkeiten. Ob ich eine Funktion mit magischem Namen aufrufe und der eine struct mit magischen Namen mitgebe (gefüllt mit magischen Konstanten). Oder ob ich in einer Variable mit magischem Namen ein paar Bits mit magischen Namen setze oder lösche - am Ende ist das beides nicht sonderlich abstrakt. Eine echte Abstraktion wären Funktionen wie void Error_LED_on(void) oder bool Key_Left_pressed(void). Und ganz offensichtlich sind solche Abstraktionen immer projektspezifisch. > Mit allgemeinen API So etwas gibt es nicht. API ist ein sehr weit gefasster Begriff. Vergleichbar vielleicht mit "Werkzeug" (für einen Handwerker). Oder "Einheit" (für einen Physiker). Es gibt APIs für alle möglichen Aspekte der Programmierung. Für den Zugriff auf die Hardware eines µC (das meintest du wohl). Aber auch für den Zugriff auf z.B. Files in einem Filesystem. Oder für das Zeichnen von graphischen Oberflächen. Für kryptographische Protokolle. Zum Parsen von XML-Strukturen. etc. pp. Deine Frage ist viel zu unspezifisch für eine sinnvolle Antwort.
Stefanus F. schrieb: > Ein Programm, dass z.B. für einen Chip aus der STM32F103 Serie > geschrieben wurde, lässt nicht trotz HAL nur mit erheblichen Änderungen > auf STM32F303 "upgraden" - obwohl der als sogar Nachfolger zum STM32F103 > gehandelt wird. Ja das hatte ich auch gelesen. Downgraden zwischen gewissen Serien soll laut ST aber kein Problem sein. Das hatte ich irgendwo auf deren Seite gelesen. Ich finde es gerade aber nicht wieder. Ich weiß nur noch das es nur zwischen gewissen Serien ging. Auf Wikipedia konnte ich nur finden welche Controller "pin-to-pin compatible" sind. Aber das heißt ja vermutlich auch nicht unbedingt das man genau zwischen den Serien downgraden kann. https://en.wikipedia.org/wiki/STM32 Zum Upgraden gibt es dann von St dann sowas hier https://www.st.com/content/ccc/resource/technical/document/application_note/8e/c8/8d/e3/ee/ff/44/e6/DM00073522.pdf/files/DM00073522.pdf/jcr:content/translations/en.DM00073522.pdf mit 90 Seiten natürlich schon ziemlich umfangreich. Axel S. schrieb: > Deine Frage ist viel zu unspezifisch für eine sinnvolle Antwort. Sry. Das war nicht meine Absicht. Axel S. schrieb: > Die "Sammlung von Funktionen" ist die Bibliothek (Library). Das API ist > die Beschreibung, welche Funktionen es gibt und wie sie zu verwenden > sind. Bei Programmiersprachen, die zwischen Deklaration und > Definition unterscheiden (wie z.B. C) nennt man oft die Deklaration > (vulgo: ein oder mehrere Headerfiles) das API und die eigentliche > Implementierung (entweder Quellcode oder Objectcode) die Library. Darunter kann ich mir schon wieder ein bisschen eher was vorstellen. Axel S. schrieb: > Nein. Nur die allerwenigsten Teile des HAL sind wirklich unabhängig von > der Hardware. Dann ist der Begriff aber auch irreführend. Oder ist gemeint das nach der Schicht von der Hardware abstrahiert gearbeitet werden kann. Axel S. schrieb: >> und bei LL arbeitet man wie man >> es kennt auf Hardwarebene und beschreibt die Register einzeln. > > Das ist ein Streit um Begrifflichkeiten. Ob ich eine Funktion mit > magischem Namen aufrufe und der eine struct mit magischen Namen mitgebe > (gefüllt mit magischen Konstanten). Oder ob ich in einer Variable mit > magischem Namen ein paar Bits mit magischen Namen setze oder lösche - am > Ende ist das beides nicht sonderlich abstrakt. Die Low Layer soll ja auch nicht abstrakt von der Hardware sein. Aber das was du mit den magischen Funktionen meinst ist ja im Endeffekt das was ich meint. Vorgefertigte Funktionen zum arbeiten auf Registerebene. Axel S. schrieb: > Es gibt APIs für alle möglichen Aspekte der Programmierung. Für den > Zugriff auf die Hardware eines µC (das meintest du wohl). Aber auch für > den Zugriff auf z.B. Files in einem Filesystem. Oder für das Zeichnen > von graphischen Oberflächen. Für kryptographische Protokolle. Zum Parsen > von XML-Strukturen. etc. pp. Ok. Vielen Dank das ihr euch dafür Zeit genommen habt mir die Begrifflichkeiten näher zu bringen. Vor allem weil ich mich so dumm anstelle. Ich hab es zwar noch nicht zu tausend Prozent verstanden, aber ich denke ich werde einfach mal beides nutzen wenn das Eval Board von ST da ist. Hoffentlich werden die Begrifflichkeiten dann klar. Vielen Dank!
Steffen schrieb: > Auf Wikipedia konnte ich nur finden welche Controller "pin-to-pin > compatible" sind. Pin-Kompatibilität hat ST ganz gut hinbekommen. Software-Kompatibilität eher nicht. Auch nicht mit HAL oben drüber. Die App-Note, die du da gefunden hast sagt ja schon einiges aus. Wobei sie nicht einmal konkret wird - Code Beispiele fehlen da komplett. > Ich hab es zwar noch nicht zu tausend Prozent verstanden, aber ich denke > ich werde einfach mal beides nutzen wenn das Eval Board von ST da ist. Mach das, so kannst du dir selbst ein Bild davon machen. Ob man die HAL benutzen wird, oder nicht, hängt am Ende sicher sehr stark vom persönlichen Geschmack ab.
Bitte 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.