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.
newcomer schrieb: > Zur Verfügung stehende Zeit: ca. 4 Wochen. Je nach Umfang würde ich >4 Mannjahre ansetzen. Schreib erstmal auf, was alles unterstützt werden soll, z.B.: - digital I/O (in, out, tristate, pullup, pulldown, open drain,...) - Busse (SPI, I2C, USB, Ethernet,CAN,...) - interne Einheiten (Reset, Sleepmodes, Clock, PLL,...) - interne Peripherie (Timer, ADC, PWM, Pulsmessung,...) - externe Peripherie (ADC, DAC, 1-Wire, LCD, GLCD,...) - irgendwelche Protokolle (UDP, CANOPEN,...)
>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: > Es ist viel Arbeit wie ich es sehe, oder? Ja, und noch dazu reichlich weltfremd. :-(
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.
W.S. schrieb: > Richte deinem Prof mal nen schönen Gruß von mir aus und daß er ein Esel > ist. Darauf wird er bestimmt großen Wert legen …
Andere Ideen: Si32Library von SiLabs für deren Cortex-M3 bzw. das HAL ansehen http://www.silabs.com/products/mcu/Pages/32-bit-mcu-software.aspx#library http://www.silabs.com/Support%20Documents/TechnicalDocs/AN672.pdf eCos, FreeRTOS oder vielleicht auch NetBSD ansehen p.s. ist das Besäufnis nicht schon bei Erhalt solcher "Aufgaben" obligatorisch ;)
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.php https://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.
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.