Überblick über APIs und Bibliotheken

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.

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.