Hallo zusammen,
nach drei Tagen von recherchieren und googeln habe ich immer noch kein
klares Bild zur Lösung meiner Aufgabe und möchte mich mit der Frage an
euch wenden.
Ich habe in UNI eine Aufgabe bekommen und zwar eine HAL (Hardware
Abstraction Layer) für LPC17xx und STM32F1xx zu schreiben.
Zur Verfügung stehende Zeit: ca. 4 Wochen.
Es muss also eine Schicht geschrieben werden mit einem für Application
zur Verfügung stehenden Befehlssatz (API). API ist nicht fest definiert,
kann also von mir gestaltet werden. Die Schicht "spricht" also mit
Peripherie und mit API, leitet die Anweisungen die durch API kommen an
die Peripherie weiter. Eigentliche Aufgabe ist es: unterschiedliche CPUs
sollen sich gleich nach "oben" zur Application verhalten. Zweck des
Layers ist klar, Vereinfachung bei Portierung auf andere HW.
Ich habe mir schon CMSIS angeschaut, bin aber nicht sicher, dass es das
ist.
Ich glaube nicht, dass ich der erster bin, der so was machen soll. Komme
aber ohne Unterstützung von erfahrenen SW-Entwickler nicht weiter.
Ich brauche paar Hinweise, wie man es gestalten kann bzw. ob es ein Bsp.
gibt.
Vielen Dank im Voraus.
Dave
na. du kapselst die cpu funktionalitaet in eine library. also alles was
die Compiler library nicht kann. zB das ansteuern eines portes. zb uart
send/receive, zB SPI send/receive, ADC konfig und start und auslesen.,
zB einen Variablen LCD port und darauf schreiben. zB einen TimerTick.
newcomer schrieb:> Ich glaube nicht, dass ich der erster bin, der so was machen soll. Komme> aber ohne Unterstützung von erfahrenen SW-Entwickler nicht weiter.
Du musst zuerst einmal aufschreiben, was du alles kapseln willst.
Das ist eine Anforderung, die im Wesentlichen „von oben“ kommen muss,
also von der Applikation, die dann mal auf dem HAL aufsetzen soll.
>zB das ansteuern eines portes. zb uart>send/receive, zB SPI send/receive, ADC konfig und start und auslesen
Erstmal danke für die Antwort.
Aber ist es nicht so, dass z.B. in StdPeriph_Driver von ST die
Funktionen schon implementiert sind?
z.B.: void SPI_Init(SPI_TypeDef* SPIx, SPI_InitTypeDef*
SPI_InitStruct);
oder void SPI_Cmd(SPI_TypeDef* SPIx, FunctionalState NewState);
sind aber wie du geschrieben hast keine Send und Get Befehle, also keine
„aktive“ Befehle implementiert, nur Initialisierungen. Ist das der
Unterschied zum HAL?
Gruß
Dave
Jörg Wunsch schrieb:> Du musst zuerst einmal aufschreiben, was du alles kapseln willst.> Das ist eine Anforderung, die im Wesentlichen „von oben“ kommen muss,> also von der Applikation, die dann mal auf dem HAL aufsetzen soll.
Danke für die Antwort Jörg.
Die Aussage vom Prof war: es müssen alle vom jew. Prozessor zur
Verfügung stehende Peripherie auch der Application zur Verfügung stehen.
Es ist viel Arbeit wie ich es sehe, oder?
Aber es wird schon einiges von StdPeriphLib abgedeckt, oder sehe ich es
falsch?
Gruß
Dave
Peter Dannegger schrieb:> Je nach Umfang würde ich >4 Mannjahre ansetzen.
Hallo Peter und danke,
meinst du wirklich, dass es so viel Arbeit ist, ich dachte, dass es
schon einiges im Net zum Kopieren gibt. Zimindest ansatzweise.
Gruß
Dave
newcomer schrieb:> Die Aussage vom Prof war: es müssen alle vom jew. Prozessor zur> Verfügung stehende Peripherie auch der Application zur Verfügung stehen.
Möglicherweise hat der liebe Prof in seinem Elfenbeinturm ein wenig aus
dem Auge verloren, was so ein moderner uC alles an Peripherie und
Funktionen bietet.
ase schrieb:> Möglicherweise hat der liebe Prof in seinem Elfenbeinturm ein wenig aus> dem Auge verloren, was so ein moderner uC alles an Peripherie und> Funktionen bietet.
wenn er noch die alten PICs oder 8051 kennt .... scheint das so ^^
CMSIS ist ja ein anfang ...
da kann man glaube ansetzen was gerade die Cortexe angeht
dann scheibst du dir generelle I/O routinen.
- open(*device,....)
- read(*device,....)
- write(*device,....)
- close(*device,....)
schau dir mal sowas aus älteren unix systemen an
zu jeder CPU brauchst du dann ein BSP
in diesem file wird das open/read/write/close zu dem jeweiligen HW teil
umgesetzt
da drin kann auch gleich die bufferverwaltung sein ..
zB eine UART bekommt ihren FIFO usw ...
somit ist zwar je CPU immer ein BSP von nöten was aber einfacher ist
als eine lib mit zig #defines zu basteln
newcomer schrieb:> Die Aussage vom Prof war: es müssen alle vom jew. Prozessor zur> Verfügung stehende Peripherie auch der Application zur Verfügung stehen.
Oh je.
Die 4 Wochen brauchts Du bestimmt, um überhaupt die Peripherie eines MC
ganz ohne HAL zu verstehen.
Dann das ganze für alle anderen MCs wiederholen.
Und dann versuchen, diese vielen Varianten irgendwie auf einen Nenner zu
bringen.
Wenn ich mal zurück denke, in etwa 4 Wochen hatte ich die Peripherie des
8051 so einigermaßen drauf.
Ein 32Bit Bolide ist aber ne ganz andere Hausnummer.
8051 - Fahrrad
ARM - Boeing 777
newcomer schrieb:> Aber ist es nicht so, dass z.B. in StdPeriph_Driver von ST die> Funktionen schon implementiert sind?>> z.B.: void SPI_Init(SPI_TypeDef* SPIx, SPI_InitTypeDef*> SPI_InitStruct);> oder void SPI_Cmd(SPI_TypeDef* SPIx, FunctionalState NewState);
Da hast Du recht. Aber genau das soll die HAL ja vereinheitlichen. Die
HAL hat die Aufgabe, daß diese Fuktionalität für verschiedene Hardware
sowohl in der Art und Form des Methodenaufrufes als auch in der exakten
Umsetzung/Wirkung bzw. dem Resultat 100% identisch ist.
Es reicht nicht daß für jede Hardware eine Methode das SPI zu
initialisieren und zu nutzen vorhanden ist. Es geht darum, daß sie für
den Programmierer und die Software nach außen hin völlig identisch sind.
newcomer schrieb:> meinst du wirklich, dass es so viel Arbeit ist, ich dachte, dass es> schon einiges im Net zum Kopieren gibt. Zimindest ansatzweise.
In der gegenwärtigen Formulierung ist das beliebig viel Arbeit. Die
Frage ist also mit "ja" zu beantworten.
newcomer schrieb:> Die Aussage vom Prof war: es müssen alle vom jew. Prozessor zur> Verfügung stehende Peripherie auch der Application zur Verfügung stehen.newcomer schrieb:> Ich habe in UNI eine Aufgabe bekommen und zwar eine HAL (Hardware> Abstraction Layer) für LPC17xx und STM32F1xx zu schreiben.> Zur Verfügung stehende Zeit: ca. 4 Wochen.newcomer schrieb:> API ist nicht fest definiert,> kann also von mir gestaltet werden.
Darin liegt nun der Trick. Es geht darum ganz genau zu definieren was
die HAL könen soll. Jetzt ist auch die Frage was exakt die
Aufgabenstellung ist. Eventuell sind auch ein zwei Silben und Worte auf
dem Weg vom Prof bis hierher verloren gegangen. So wie es jetzt aussieht
ist die Erstellung der Spezifikation der API der größte Block. Ohne
genaue Aufgabenstellung kann man sich sehr sehr viel Arbeit machen. Eine
Aufgabenstellung a la "mach mal" ist viel zu schwammig. Selbst wenn das
erstellen der API bestandteil der Aufgabe ist, so muß wenigstens
definiert sein was genau sie können muß. Wie sie dann exakt aussieht
und implementiert wird mag dann deine Aufgabe sein, aber das was ist
genau festzulegen vom "Kunden".
Die Anforderung: LPC17xx und STM32FLxx ist Mist weil man nicht weiß was
zukünftig noch für Modelle die mit diesen Zeichen beginnen herauskommen.
Was man machen kann: Alle aktuellen Prozessoren die unter diese
Bezeichnung fallen auflisten und für diese und nur diese eine HAL
schreiben. Zukünftige Modelle können dann eventuell nachträglich
hinzugefügt werden.
Dann sollte auch festgelegt werden welche Peripherie unterstützt werden
soll. Die Peripheriekonstellationen sind sehr produktspezifisch. Wie
will man eine API schreiben die beispielsweise den Zugriff auf die UARTS
vereinheitlicht, wenn Chip A einen UART hat und Chip B hat zwei davon?
Wie weit soll da die Abstraktion gehen. Soll die API hinter den
Kullissen dann für Chip A einen Soft-UART nachbilden? Soll die API nur
die Zugriffe der Hardware vereinheitlichen die auch bei allen Chips
vorhanden ist? Soll fehlende Hardware durch Emulation nachgerüstet
werden? Stickwort: Soft-UART, Coprozessorunterstützung wie seinerzeit in
den ersten zig Jahren der PC-Ära...
Im Moment sieht es eher so aus als solltest Du nicht nur die Aufgaben
lösen, sondern die Aufgaben auch selber stellen. Wenn das wirklich der
Fall ist, und dannn ur 4 Wochen da sind, lege die API so aus, daß das
Ziel auch in der Zeit erreicht werden kann, also einfach, schlank, ohne
Emulation...
-Liste der Unterstützten Chips erstellen (nicht nur irgendetwasxxx
sondern genaue Bezeichnung)
-Liste der Hardware/Pripherie erstellen die in allen Chips vorhanden
ist. Nur diese wird uterstützt. Verfügt ein Chip über zwei SPI Kananäle
und der andere nur über einen, so deckt die API nur Kanal 1 ab.
Schritt drei wäre nun bedingt durch,
newcomer schrieb:> Die Aussage vom Prof war: es müssen alle vom jew. Prozessor zur> Verfügung stehende Peripherie auch der Application zur Verfügung stehen.
daß man die modellspezifische Hardware und ihren Zugriff in die API
einfügt. Hier kommt nun eine Emulation zum Zuge oder eine Fehlermeldung
wenn die bestimmte Hardware nicht im aktuellen Chip vorhanden ist.
Steht die API dann mit allen Headern, so ist der Rest zum großen Teil
nur noch Fleißarbeit.
Wow! Das hört sich nach richtig viel Arbeit an! Freue mich schon!;)
Ich danke euch allen! Super Feed back!
Ich habe zwar vermutet, dass es viel Arbeit ist, wollte aber noch die
Meinung von Profis hören.
Ich werde die Schnittstelle (API) schlank definieren, mit
Peripherie-Schnittmenge von zwei ähnlichen Bausteinen und versuche die
HAL von „unten“ (Peripherie) aufzuziehen.
Wie ist es in SW-Entwicklung im Alltag? Ich vermute, dass man sich da
auch eine HW Abstr. Schicht schreibt und die dann immer wieder einsetzt,
oder? Oder wie macht Ihr das, wenn bei laufenden Projekten CPU sich
gelegentlich ändert?
Vielen Dank noch mal.
Gruß
Dave
in der Praxis hat man da meistens keine Zeit für, der Kunde muss das ja
auch später bezahlen und man muss auch mal fertig werden
Wenn das in 4 Wochen zu machen wäre hätten NXP und STM sowas längst für
Ihre Kunden zur Verfügung gestellt. Selbst 4 Monate halte ich für
unrealistisch wenn alle Peripherie mit allen Einstellungsmöglichlkeiten
unterstützt werden soll
Ich würde zuerst versuchen die Aufgabenstellung weiter zu präzisieren.
In der Regel geht man anders vor wenn man einen HAL baut, der nicht nur
akademischen Zwecken dienen soll. Man hat irgendwelche Hardware die
angesprochen werden soll. z.B. über SPI I2C oder einen einfachen Pin wie
bei Onewire. Angenommen es sollen DS18S20 ueber Onewire angesprochen
werden, dann wird sinnvollerweise das ganze Modul abstahiert. Vorher
kann man ja noch was gemeinsames für die GPIOs machen. Es macht aber
keinen Sinn die Datenblätter von 5 verschiedenen Controllern zu nehmen
und dann alle Featchers zu implementieren. Selbst bei den GPIOs gibts
soviele Unterschiede, dass ich mir schwer vorstellen kann da eine
gemeinsame HAL zu haben die alles abdeckt. Grundfunktionen machen
natürlich Sinn. Sowas wie Pin an/aus/togglen. Bei Geschwindigkeit,
Opendrain, Portremapping, Switchmatrix wirst du wohl wenig
Gemeinsamkeiten finden.
Oder bei den Timern. Hier gibts noch viel mehr Unterschiede. Was man
aber machen kann, ist sowas was häufig gebraucht wird wie PWM z.B. in
den HAL zu packen. Standard SPI ist auch noch denkbar. Wenn dann aber
noch DMA mit ins Spiel kommt wird's wieder komplexer. Von einem
USB-Host/Device-Stack wollen wir dabei garnicht reden. Da reicht deine
Zeit gerade mal zum Literatur beschaffen. Wer ein abschreckendes
Beispiel sucht, kann sich ja mal die LpcUsbLib von NXP zu Gemüte führen.
Da wird nur versucht die Controller aus dem eigenen Haus abzudecken. Um
da nur durch die verschachtelten Verzeichnisse, Header und Codefragmente
durchzusteigen um zu ermitteln was für was gebraucht wird, muss man wohl
ein paar Jahre bei denen beschäftigt gewesen sein.
Alles in allem mache ich dir wenig Hoffnung, dass bei den derzeitigen
Rahmenbedingungen egal ob in 4 Wochen oder 4 Jahren was vernünftiges
rauskommt.
Und wenn du es doch angehst, dann kopiere bitte nicht die Lib vom STM32.
Und noch ein Layer über diese Lib zu stülpen ist auch nicht sinnvoll.
Wenn du dir aber die Arbeit machst, während der Anwendungsentwicklung
einen Layer über der von dir bevorzugten Hardware zu legen, dann hast du
in ein paar Jahren so nebenbei eine schicke kleine Lib die zu dir und
deinen Aufgaben passt. Und die ist dann auch getestet. Oder wie willst
du die ganze Hardware der verschiedenen Controller mit deinem Code
testen?
Ich finde, der Ansatz den mbed macht z.B. auch nicht schlecht obwohl ich
es noch nicht benutzt habe. Hier werden auch mehr oder weniger Module
die häufig Verwendung finden anwendergerecht in c++ Klassen gepackt. Den
Code kannst du komplett runterladen:
http://mbed.org/users/mbed_official/code/mbed-src/
Da stecken aber auch ehr Mannjahre wie Mannmonate Arbeit drin. Wie da
die Hardware in der HAL steckt kannst du für Freescale und NXP-Chips
sehen. Mach dafür einen HAL für STM32 und gibs der Welt zurück. Das wäre
eine Aufgabe mit wesentlich weniger Unbekannten..
Lagere Deine Aufgabe aus: Das heißt, schicke Dein Problem nach Indien
oder China und laß Dir das Ergebnis zuschicken. Die machen das für
kleines Geld in 3 Tagen und Du hast Deine Ruhe. Der Professor merkt
sowieso nichts, so wie er die Aufgabe beschrieben hat ;)
Eine HAL ist meistens dann relevant wenn ein Betriebssystem zum Einsatz
kommt, also bei ausgewachsenen Embedded-Lösungen. Viele der
Kleinprojekte, das können auch große und komplexe Sachen sein, die aber
von Softwaresicht gesehen mit einem bezüglich der Ressourcen kleinen
Mikrocontroller erledigt werden, verwenden kein eigenes Betriebssystem,
oftmals weil dafür kein "Platz" da ist. Mit dem Betriebssystem entfällt
oftmals auch der HAL, auch wenn HAL ohne Betriebssystem prinzipiell
möglich ist.
Die Frage ist nun was man eigentlich beabsichtigt mit dieser Aufgabe.
Geht es darum zu lernen wie man eine API entwickelt? Geht es darum wie
man eine HAL entwickelt? Geht es darum wie man ein bestimmtest Produkt
in eine HAL einbindet? Geht es darum wie man eine ganze Produktlinie in
eine HAL einbindet? Geht es darum wie man heterogene Hardware unter
einen Softwarhut bekommt? Damit meine ich nicht unterschiedliche
Hardwareimplementierungen die aber prinzipiell die gleiche Funktion
bieten per Software zu vereinheitlichen, sondern unterschiedlich
umfangreich ausgestattete Hardware unter einen Softwarehut zu bekommen.
Denn dann muß man nicht nur den Zugriff vereinheitlichen, sondern auch
Mechanismen bieten die Rücksicht darauf nehmen ob eine Funktionalität
überhaupt vorhanden ist.
Jede dieser Aufgaben für sich ist schon ein großes Lernziel!
Selbst wenn man "nur" eine HAL schreiben würde die nur für einen
bestimmten ATMega ausgelegt ist, sind 4 wochen knapp bemessen wenn es
darum geht eine saubere HAL zu entwerfen und aufzusetzen, besonders wenn
man mit diesem noch ncht vertraut sein sollte.
Wenn es nun darum geht nicht nur zwei Produkte, sondern gleich zwei
komplette Produktlinien unterschiedlicher Herstellen zusammenzufassen
ist das eine ziemliche Hausnummer, zumal ich nicht den Eindruck habe,
daß Du in der Welt von ARM wirklich zuhause bist, sondern dich noch erst
einarbeiten mußt. An dieser Stelle frage ich mich ob Du jemals eine API,
geschweige denn eine HAL implementiert hast. Das ist gleich ein ganzer
Wust an Neulandbaustellen.
Wie stellt er sich das vor? Oder hattet ihr da schon massive Vorarbeit
geleistet und umfangreiche Erfahrungen mit ARM, API-Erstellung und der
Erstellung einer HAL so wie Treiberentwicklung. Ok die "Treiber" für
einen UART eines bestimmten Mikrocontrolers kann man relativ schnell
schreiben, wenn man die Plattform kennt. Aber wenn es so abstrakt sein
soll, daß man mehrere Treiber für unterschiedliche Hardware für
unterschiedliche Aufgaben einheitlich unter einen Hut bekommen will,
dann Bedarf es einer sinnvollen Strukturierung, einer Art Framework für
Treiber im allgemeinen.
Komplette IDE und Entwicklungsumgebung für diese Aufgabe so wie die
völlige Vertrautheit mit dieser Software wird vorausgesetzt. Die
komplette Hardware in allen Konstellationen sind vorhanden oder
zumindest leicht, schnell und perfekt simulierbar. Die Notwendige
Software für die Simulation ist für beide Hersteller vorhanden und man
ist perfekt damit vertraut, so daß man in annehmbarer Zeit jede
Hardwarekonstellation testen kann.
Woche 1
Tag 1: Einarbeitung in die ARM Architektur allgemein
Tag 2: Einarbeitung in die Produktlinie von Hersteller A allgemein
Tag 3: Einarbeitung in alle spezifischen Eigenarten aller Produkte der
jeweiligen Linie
Tag 4: Einarbeitung in die Produktlinie von Hersteller A allgemein
Tag 5: Einarbeitung in alle spezifischen Eigenarten aller Produkte der
jeweiligen Linie
Am Wochenende erfolgt dann so nebenher die Zusammenstellung der
Gemeinsamkeiten so wie die Strukturierung der produktspezifischen
Eigenarten.
Ein Routinierter Umgang beim erstellen von HALs und APIs wird als
selbstverständlichkeit vorausgesetzt. Das es sich hierbei um
hardwarenahe Programmierug handelt kann ignoriert werden. Wir müssen uns
nie Gedanken darum machen eine API/HAL-weite Struktur aufzubauen, die es
uns in irgendeiner Form strukturiert erleichter zu entscheiden auf
welcher Hardware wir gerade arbeiten. Ferner ist uns im voraus natürlich
völlig klar wie die API/HAL nacher aussehen soll und wir können am
Montag sofort beginnen mit:
Woche 2
Tag 1: Erstellen eines erweiterbaren strukturierten API-Frameworks
Tag 2: Erstellen der Core-API die alle gemeisam unterstützten Funktionen
umfaßt.
Tag 3: Erstellen der API die alle Produktspezialitäten von Hersteller A
umfaßt.
Tag 4: Erstellen der API die alle Produktspezialitäten von Hersteller B
umfaßt.
Tag 5: Spezifikation und Definition für alle denkbaren Konstellationen
wenn spezielle API-Funktionen auf einer anderen Hardware, eventuell der
des anderen Herstellers, aufgerufen wird.
Am wochenende frischen wir so nebeher unser Wissen über die
produktspezifischen Register auf, so daß wir in der folgenden Woche gar
nicht darüber nachdenken müssen wie wir welche Register zu konfigurieren
haben, ganz gleich welches Produkt wir gerade bearbeiten.
Woche 3
Tag 1: Implementierung des HAL-Frameworks
Tag 2: Implementierung der Core-Funktionen für alle Produkte von
Hersteller A. Wir schreiben alle hierfür benötigten Treiber an diesem
Tag.
Tag 3: Implementierung der Core-Funktionen für alle Produkte von
Hersteller B. Wir schreiben alle hierfür benötigten Treiber an diesem
Tag.
Tag 4: Implementierung der Sonder-Funktionen für alle Produkte von
Hersteller A. Wir schreiben alle hierfür benötigten Treiber an diesem
Tag.
Tag 5: Implementierung der Sonder-Funktionen für alle Produkte von
Hersteller A. Wir schreiben alle hierfür benötigten Treiber an diesem
Tag.
Am Wochenende erledigen wir so nebenher den restlichen Kleinkram. Das
heißt wir kümmern uns unter anderem darum, das alle Sonderfunktionen auf
jeder Hardware zur Verfügung stehen, indem wir jeweils entweder eine
Emulation schreiben oder diesen Funktionsaufruf auf nicht unsterstützter
Hardware erkennen und als Sonderfall abfangen. Das dabei jede
erdenkliche Kreuzkombination berücksichtigt wird ist natürlich eine
Selbstverständlichkeit. Nach diesem kernentspannten Wochenende können
wir direkt durchstarten zu...
Woche 4
Tag 1: Test, Simulation und Debugging der Grundfunktionen die von allen
Produkten bereitgestellt werden für alle Produkte von Hersteller A. Der
Test hat selbstverständlich auf allen Hardwarekonstellationen zu
erfolgen.
Tag 2: Test, Simulation und Debugging der Grundfunktionen die von allen
Produkten bereitgestellt werden für alle Produkte von Hersteller B. Der
Test hat selbstverständlich auf allen Hardwarekonstellationen zu
erfolgen.
Tag 3: Test, Simulation und Debugging der Spezialfunktionen die von
einzelnen Produkten von Hersteller A zur Verfügung gestellt werden. Der
Test hat selbstverständlich auf allen Hardwarekonstellationen zu
erfolgen, um sicherzustellen, daß die Funktionen bei der entsprechenden
Hardware korrekt umgesetzt werden und in allen anderen Fällen entweder
korrekt emuliert werden bzw. die API sauber und korrekt auf nicht
vorhandene Hardware reagiert.
Tag 4: Test, Simulation und Debugging der Spezialfunktionen die von
einzelnen Produkten von Hersteller B zur Verfügung gestellt werden. Der
Test hat selbstverständlich auf allen Hardwarekonstellationen zu
erfolgen, um sicherzustellen, daß die Funktionen bei der entsprechenden
Hardware korrekt umgesetzt werden und in allen anderen Fällen entweder
korrekt emuliert werden bzw. die API sauber und korrekt auf nicht
vorhandene Hardware reagiert.
Tag 5: Zusammenstellung aller Unterlagen ud Dateien und Abgabe der
perfekten Lösung
Das folgende Wochenende machen wir nun was wir immer tun. Da
Softwareentwicklung keine Arbeit ist und KnowHow als reine Kopfsache
eine reine Selbstverständlichkeit ist und nicht durch Arbeit erworben
werden muß, so haben wir die letzten 4 Wochen eigentlich nichts getan
und fahren daher fort mit dem obligatorischen Besäufnis.
newcomer schrieb:> meinst du wirklich, dass es so viel Arbeit ist, ich dachte, dass es> schon einiges im Net zum Kopieren gibt
Da hast du was übersehen: die mitgelieferten Libraries dienen dazu, dass
man die Peripherie überhaupt ansprechen kann, von einer
Vereinheitlichung für verschiedene Prozessoren kann da kein Rede sein.
Wahrscheinlich kannst du keine einzige Funktion nutzen, du musst alle
neu schreiben.
Aber zuerst musst du mal einen Plan haben: wie spreche ich überhaupt
alle UARTs einheitlich an, so dass auch möglichst die Leitungsfähigkeit
ausgenutzt wird? usw.
Gruss Reinhard
newcomer schrieb:> Es muss also eine Schicht geschrieben werden mit einem für Application> zur Verfügung stehenden Befehlssatz (API). API ist nicht fest definiert,> kann also von mir gestaltet werden.
Richte deinem Prof mal nen schönen Gruß von mir aus und daß er ein Esel
ist.
Also: du (und dein Prof) verwechseln da was ganz gewaltig.
Das API ist die Schnittstelle zwischen einem Betriebssystem (egal ob
groß oder winzig) und einem Applikationsprogramm.
Eine HAL ist hingegen eine Treiberschicht, die zwischen dem
Betriebssystem und der Hardware liegt.
Der überall so toll beworbene CMSIS Kram ist keine HAL. Das sollte man
mal klar sagen.
Ich geb dir mal ein Beispiel, hier der Einfachheit halber das Holen
eines Char's von einer Art serieller Schnittstelle:
API-Funktion:
#define idCOM1 0
#define idCOM2 1
#define idUSB 2
#define idSPI 3
#define idFile 4
...usw.
char GetChar(int idPort);
Damit kann man dann seinen char von einer vom Betriebssystem
unterstützten Schnittstelle abholen. Die Betriebssystem-Funktion sieht
dann etwa so aus:
char GetChar(int idPort)
{ switch (idPort)
{ case idCOM1: return GetCharFromCOM1();
case idUSB: return GetCharFromUSB_CDC();
... usw.
}
return -1;
}
Diese Funktion greift nun auf Hardware-Treiber, also HAL-Funktionen
zurück, die (egal welcher µC dahinter steckt) gegen das BS eine eigene
abgeschlossenen Ansicht bieten. Was also hinter
char GetCharFromUSB_CDC(void)
steckt und wie das für die unterschiedlichen Cores verschiedener µC
treiberintern gelöst ist, das ist dem BS egal. DAS ist die HAL-Schicht.
Praktisch sieht das so aus, daß die zum Treiber gehörige Headerdatei
eben nur das enthält, was vom aufrufenden Programm wirklich benötigt
wird UND NICHT MEHR ud daß deselbe Headerdatei für ALLE
unterschiedlichen µC benutzt wird.
W.S.
Jörg Wunsch schrieb:> Darauf wird er bestimmt...
Manchmal wünch ich mir jemanden, der hingeht und solchen Prof's die
Ohren langzieht.
Mich bringt sowas auf die Palme. Nicht so sehr, daß da ein junger
unerfahrener Mensch mit SOWAS über seinen eigenen Nuckel geschubst wird,
sondern daß es unter den von mir bezahlten Professoren solche gibt, die
entweder sowas sehenden Auges (und insgeheim grinsend) verzapfen oder
(schlimmer) selbst zu doof sind, um die Sache zu überblicken.
W.S.
Hallo,
Arc Net schrieb:> eCos, FreeRTOS oder vielleicht auch NetBSD ansehen
ich kann noch ChibiOS empfehlen.
http://www.chibios.org/dokuwiki/doku.phphttps://github.com/mabl/ChibiOS
Dieses System basiert auf einer Hall mit einem recht hohen
Abstrahierungsgrad, wie ich finde.
Es werden auch eine große Anzahl von verschiedenen Prozessoren
unterstützt. Unter anderem den STM. Der LPC ist noch nicht dabei, aber
andere.
Nur mal als Anregung.
Viele Gruße
Christian
Es ist doch offensichtlich, was das Ziel ist.
Der Prof hat ein Dutzend Chips rumliegen und will nun, für spätere,
hypothetische Projekte eine universelle Bibliothek haben, damit alle
späteren Studenten ihr ach so wichtiges Projekt gleich "für alle
Prozessoren" machen können.
Und natürlich sind 4 Wochen die Grenze, weil der Student nur so viel
Zeit im Semester für solche Zwecke hat. So eine Entwicklung fällt auch
nicht unter Forschung (= Papers produzieren), kann also nicht von einem
Mitarbeiter entwickelt und (langfristig) gewartet werden.
Kurz: Da kommt was für Ablage P, rund raus.
> Es ist viel Arbeit wie ich es sehe, oder?
Jep. In 4 Wochen nicht zu schaffen.
Ich habe in der Firma für den STM32F103 mit USB und ohne CAN ca. 4
Monate gebraucht. LPC1768 habe ich daheim immer wieder mal was gemacht.
Liegt Fulltime wahrscheinlich in derselben Größenordnung.
Ergo: Prof. ist vollkommen weltfremd. Aber deswegen ist er ja auch Prof
:-(
Ich nehme an er hat den Gedanken der Aufgabenstellung im Vorfeld einfach
nicht eingehend vertieft. Ich bin mir sicher daß er, wenn man ihn auf
die hier genannten konkreten Probleme anspricht, die Aufgabe präziser
einschränken wird oder in Teilaufgaben splittet damit es in 4 Wochen
machbar wird. Dann kann er mit den Teilaufgaben gleich andere Studenten
versorgen.
Einer erstellt ein HAL-Konzept oder zumindest einen Teil. Die Anderen
pflegen die unterschiedlichen Produkte ein.
