mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Entwicklung eines HAL


Autor: ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

ich bin gerade am überlegen wie ich meine Software am besten so
gestalte, dass ich sie leicht von einem Controller auf den nächsten
portieren kann. Modular und gekapselt habe ich bisher schon
programmiert, aber bei der Hardware hört es bisher immer auf. Jeder
Controller hat ja unterschiedlich viel Funktionalität. Nun habe ich
schon an verschiedenen Stellen etwas über HALs gelesen. Allerdings war
dies nur sehr oberflächlich. Ich habe also nichts darüber gefunden, wie
man an so eine Sache herangehen kann. Vor allem habe ich noch keine
genaue Vorstellung wie man einen HAL optimal programmieren kann, dabei
meine ich zum Beispiel die Verwendung von Interrupts usw.. Wie Schaffe
ich es, die unterschiedlichen Strukturen verschiedener Controller durch
eine einheitliche Schnittstelle zu beschreiben? Hat vielleicht einer ein
paar Tips bzgl. Literatur oder Websites wo etwas zu diesem Thema zu
finden ist? Über Tips aus der Praxis würde ich mich auch freuen.
Zunächst möchte ich sowas auf einem ATMEGA zusammen mit dem GCC
umsetzen.

Viele Grüße,

Ralf

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein HAL ist erstmal nur eine Schnittstellen-definition, mehr nicht. Sie
sollte natürlich möglichst portierbar und einheitlich zur
unterschiedlichen Hardware sein, was ja auch der Unterschied zu anderen
Schnittstellen ist. Allerdings lohnt sich ein HAL nur für große CPU's.
Im Falle eines AVR's oder PIC's wäre er softwaretechnische
"überdimensioniert" bzw. viel zu umständlich. Der HAL vom PalmOS zb.
übernimmt einiges an intelligenter Funktion nebst eigenem ausführbarem
Code. Das macht dort auch Sinn da man dort normalerweise keine
Interruptroutinen oder System-Link-Bibliotheken selber programmieren
wird oder kann. Auf einem AVR würde das aber bedeuten das man keine
"Echtzeit-Systeme" mehr programmieren kann. Denn nun würde der HAL
mit einer ziemlich komplizierten IRQ Logik verhindern das man zb. die
Timerspezifischen PWM Eigenschaften der AVR's wirklich ausnutzen kann.
Bedenke der HAL ist ein Abstractionlayer in Software der sich auf einem
gemeinsammen Nenner an Funktionalität einigien muß. D.h. er ist zwar
portable aber auch unspezifisch. Er kann also spezielle Unterschiede
zwischen AVR, PIC oder ARM's nicht eingehen.

Deshalb mache ich sowas immer anders. Alles was HW abhängig ist wird in
einen Mini-HAL als Headerdatei ausgelagert. Je nach Hardware sind dann
nur wenige Sourcedateien betroffen die geändert werden müssen. Ergo,
ist es kein eigenständiger HAL mehr sondern nur noch eine einheitliche
Schnittstellendefinition zur Hardware.

Die HAL's die ich bisher gesehen habe, besonders der vom PalmOS, kann
man sich vorstellen als Library die vergleichbar zum PC das BIOS +
Windows Treiber repräsentieren. Also die unterste Ebene zur Hardware.
Der restliche Programcode muß dann immer über das HAL arbeiten damit er
auch in Punkto Portabilität überhaupt Sinn macht. Damit das funktioniort
kann der HAL aber keine Platformspezifischen Funktionen enthalten und
diese dürfen dann aber auch nicht am HAL vorbei zusätzlich benutzt
werden. Ergo: auf Echtzeitsystemen ist ein HAL eher störend als
sinnvoll.

Nur meine 10 Cent Meinung :=)

Gruß Hagen

Autor: Heinz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du könntest in deinem Hauptprogramm eine Variable CPU erstellen und dort
 z.B. über einen int Wert einstellen welchen uC du verwendest.
Dann könntest du in einer oder mehrerer Header Datei/en den
hardwarenahen Code für die jeweiligen uCs schreiben und jeweils in
einer  if(CPU == XYZ) Abfrage kapseln.

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn Du etwas portabel machen möchtest, dann gibt es dazu im Prinzip
zwei Ansätze:
a) Man beschränkt sich auf die Gemeinsamkeiten - und verliert dadurch
viel Funktionalität
b) Man bildet fehlene Funktionalität nach - und schleppt einen riesigen
Overhead mit.

Ich schließe mich da Hagen an: Für einen richtigen HAL sind die
üblichen 8-Bit-Microcontroller zu klein.

Markus

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

danke für eure Tips!

@ Heinz:
So in der Art habe ich es bisher gemacht. Der Nachteil den ich darin
sehe ist, dass mit steigender Anzahl von Funktionen und Controller der
Code immer unübersichtlicher und schwer wartbar wird. Aus diesem Grund
möchte ich solche Compilerschalter möglichst auf ein Minimum
reduzieren. Teilweise habe ich dann ja auch noch Schalter für
Debugzwecke im Programm.

@all:
Bei der Ansteuerung der Interrupts und der verschiedenen Timer von
Controllern hatte ich auch die eigentlichen Probleme gesehen. Ich habe
schonmal einen HAL für kleinere Controller gesehen. Dabei gab es
allerdings das Problem, dass verschiedene Routinen zur
Interruptsteuerung relativ lange dauerten wodurch es nicht mehr möglich
war Zeiten sehr genau zu messen. Ich denke mal, dass es bei
Schnittstellen wie CAN oder der seriellen einfacher sein wird eine
gewisse Standardisierung zu erreichen.
Gibt es vielleicht irgentwelche Konzepte wie man am besten festlegt wo
man den Schnitt zwischen hardwarenahem, controllerspezifischem und
allgemeinem Teil der Software macht?
Was mich halt stört ist, dass man immer gezwungen ist relativ viel zu
ändern wenn der Controller gewechselt wird. Wenn man bei den AVRs
bleibt geht das ja noch, aber wenn es dann ein Wechsel auf eine andere
Controllerfamilie ist, dann wird es schon aufwändiger.

Viele Grüße,
Ralf

Autor: OldBug (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schau Dir mal zB FreeRTOS an, die Mischen die ganze Sache ein wenig.
Es gibt Abstrakte #defines, ISRs werden für jeden Controller neu
geschrieben und halten sich an einen bestimmten Standard. Für die UART
hat man Beispielsweise einfach nur den "Funktionsrumpf" bestimmt,
wodurch gewährleistet ist, daß die aufrufende Funktion überhaupt nichts
von der darunterliegenden, hardwarenahen Funktion wissen muss, ausser
den Parametern, die sie zurückgibt und erwartet.

Wenn man sich da strikt dran hält, kann man das Ganze dann später
wirklich mit nur einem einzigen Symbol beim Compileraufruf für eine
Architektur/CPU oder vielleicht sogar nur ein "Application-Board"
Kompilieren...

Autor: OldBug (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ausserdem kann man so auch "Testsuites" auf dem PC Programmieren und
die Grundsätzliche Fufnktion einer Applikation nachweisen. Ganz einfach
indem man sich "Ersatzfunktionen", welche die Hardware "Simulieren",
erstellt.

Kann oft sehr hilfreich sein...

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
FreeRTOS habe ich mir auch schonmal runtergeladen (allerdings noch nicht
richtig angeschaut)
Wie sieht es denn bei einem RTOS mit den Reaktionszeiten auf Interrupts
aus. Ich meine wenn ich z.B. Zeiten im Bereich von etwa 200us messen
muss und kein Capture mehr frei habe? Bekommt man damit noch gute
Zeiten hin oder ist dann eine Sonderlösung doch besser?

Autor: Ratber (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Ralf


>Was mich halt stört ist, dass man immer gezwungen ist relativ viel zu
>ändern wenn der Controller gewechselt wird. Wenn man bei den AVRs
>bleibt geht das ja noch, aber wenn es dann ein Wechsel auf eine
andere
>Controllerfamilie ist, dann wird es schon aufwändiger.



Verständlich aber irgendwie doch ein Wiederspruch in sich.

Um einen guten HAL zu schreiben muß man sich schon recht gut mit dem
entsprechenden Controller auskennen.

Hat man diese Kenntnisse dann ist der HAL aber wieder überflüssig weil
man dann ,aufgrund der guten Kentnisse,auch gleich die Anwendung
anpassen kann.


Normalerweise bleibt man bei einer Familie aber das will ich hier nicht
breittreten.

Eine HAL macht im Grunde keinen Sinn da sie die Effektivität eines
jeden Systems nur vermindern kann.

Sie dient nur der Bequemlichkeit der Programierer.

In zeiten wo jeder PC Speicher und Plattenplatz satt hat,wo
Rechenleistung en Mass bereitsteht kann ich nur erahnen zu welchen
Leistungen er eigentlich fäghig wäre wenn man sich seine Software mal
nicht aus bauklötzen zusammenstecken würde.

Den Vorteil der direkten effektiven Programierung willst du wirklich
freiwillig aufgeben ?

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

@Ratber
Ich habe natürlich nicht vor die flexible Programmierung aufzugeben,
aber ich hatte halt schon ein paar mal das Problem (jobtechnisch), dass
der Controllertyp gewechselt werden soll. Dabei ging es dann darum
möglichst schnell zu entscheiden mit welchem neuen Typ eine Portierung
möglich ist und wie lange eine Portierung braucht bis sie auf dem neuen
Controller läuft. Sowas kommt irgentwie halt schonmal häufiger vor wenn
andere Controller billiger sind. Meine Probleme sind dabei vor allem,
dass ich relativ viele zeitkritische Funktionen in meinem Programm habe
(Motorregelung, d.h. z.B. Drehzahl- Positionserfassung, PWM-Berechnung
usw.) was also eigentlich ein Widerspruch zu einem HAL ist. Ich bin nun
auf der Suche nach Möglichkeiten, diese möglichen Wechsel durch eine
gute Programmierung in Zukunft zu vereinfachen. Dabei bin ich nun auf
HALs gestoßen. Erste Erfahrungen wollte ich nun z.B. auf einem AVR
sammeln (Hobby, vielleicht lässt sich das ganze ja auch hier nutzen
:-)). Ich möchte also in erster Linie Erfahrung sammeln, wie ich an
soetwas herangehe, wie ich die Schnittstellen gestalten muss, wo die
Nachteile sind (da habe ich ja hier schon was erfahren :-)), usw. Im
Moment habe ich nicht so wirklich eine richtige Vorstellung davon wie
sowas in der Realität aussieht (vieleicht habe ich ja schon was
ähnliches in meinem Programm und weiß nicht das es dafür so tolle
Begriffe wie HAL gibt). Ich bin also auf der Suche nach verständlichen
Erklärungen am besten mit Praxisbeispielen. Sowas wie HALs für Dummys
oder so. In den Linux Quelltext zu gucken ist denke ich für eine
Einarbeitung etwas aufwändig.

Trotzdem danke für eure Hinweise!

Bis denne,

Ralf

Autor: OldBug (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Trennt euch doch BITTE von dem Gedanken, einen PC-ähnlichen HAL zu
stricken!

Das kann ja gar nicht Sinn der Sache sein. Eine "minimalistische"
Form eines HALs bringt auch nicht sonderlich viel Overhead mit sich!

Man kann sich ja für den Anfang auf eine Art ucHAL.h begrenzen, da
einige inline-Funktionen und #defines hineinverlagern und Feddisch!
Sowas mache ich sogar schon, wenn ich innerhalb einer Familie bleibe.
Ja, es gibt auch Unterschiede zwischen Tiny26 und Mega128! ;)
Auf letzterem arbeite ich, bis die Applikation "so gut wie Fertig"
ist, auf dem Ersten wird dann die "Release" realisiert...

Autor: Ratber (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Oldbug

Natürlich will ich das nicht mit einem HAL unter Windows vergleichen
sondern die Richtung aufzeigen.



@Ralf

Ich verstehe schon deine Gründe aber ich persönlich würde mir mal
überlegen ob die häufige Springerei zum billigsten Controller überhaupt
Sinn macht wenn du (Natürlich am Ende die Firma) damit jedesmal Arbeit
und damit auch Kosten hast und sich das überhaupt lohnt.

Es ist ja nunmal so das man sich mit der Zeit auf eine Familie
einschießt und dort erweiterte Kenntnisse erwirbt.
Das macht man sich mit einem Wechsel dann wieder zunichte und artet
instress aus.

Gut,ich weiß nicht wie das bei euch ist aber wir müssten bei jedem
Wechsel das komplete Produkt neu beim Kunden zulassen und das kostet
dann richtig Zeit und Geld.

So,das wars von mir.

Ich kann dir bei deiner Kernfrage leider nicht viel weiterhelfen und
ziehe mich mal wieder zurück aber ich lese noch etwas mit und Fragen
deinerseits beantworte ich auch gerne soweit möglich.

Ratber

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich dachte das dies oben schon erklärt wurde.

Also man kann sagen das es zwei Formen von HAL's gibt. Den
durchimplementierten HAL der wie zb. im PalmOS oder Windows aus eigenen
Treibern, ergo eigenem lauffähigem Code besteht. Und den virtuellen HAL
der im Grunde nur aus wenigen Header Dateien mit allerhöchstens par
Makro's besteht.

Der erstere soll den direkten Zugriff auf die Hardwareresourcen durch
Anwendungsprogrammierer möglichst komplett unterbinden und somit
benötigt man für jede neuere Hardware auch einen Treiber der zum HAL
hinzugefügt wird.

Der zweitere Typ ist auf einen einzige Software bezogen nur eine
Sammlung von Schnittstellen und Funktionen die die spezifische Hardware
ansteuert. Wenn, dann würde ich für MCU's nur diesen HAL empfehlen.
Praktisch bedeutet das eine Software zb. aus 50 Quelltextdateien
besteht wovon 1 oder 2 den HAL darstellen. Die restlichen Quelltexte
greifen immer über diesen HAL zu. Dieser HAL ist spezifisch auf ein
Board auf dem eine MCU sitzt. Zb. hat das Board 3 LED's und 1 PWM
gesteuerten Motor und einen AVR. Im HAL sitzt nun der Code um diese
LED's und den Motor zusteuern. Dabei steuert er dann direkt den AVR
an. Wird nun der AVR durch einen PIC ausgetauscht so wird NUR der
Quelltext des HAL's an den PIC angepasst, die restlichen 48
Quelltextdateien deiner Software bleiben unberührt da sie losgelösst
von der eigentlichen Hardware sind.

Im Grunde arbeiten wir tagtäglich mit einem "HAL", zb. die Runtime
Libraries von WinAVR wäre so ein HAL. Das einheitliche Interface dieses
HAL's sind die standardisierten C-Funktionen, wie printf() usw.
Oder, wie es guter Programmierstil ist, benutzen clevere Programmierer
ihre Includes und Header Dateien die in ihrer Funktion ausschließlich
hardware-/nichthardware bezogen sind. Man unterteilt also sauber die
komplette Software in verschiedene Teile wobei eben ein Teil der HAL
ist.

Ein HAL -> Hardware Abstraction Layer -> ist also nur eine
Schnittstelle, eine Definitionssache. Ob diese nun mit eigenen Treibern
oder aus einfachen Header-/Includedateien besteht ist erstmal nicht
entscheidend. In beiden Fällen soll er den Rest der Software oder eben
ganze Programme unabhängig von der Hardware machen.

Ich handhabe es am liebsten so das zu jeder Bibliothek es immer eine
Header/Include Datei gibt die den kompletten HW-nahen Code enthält. Der
Dateiname enthält dann das Kürzel "HW_" oder meinetwegen auch
"HAL_". Will man nun die Software anpassen konzentriert man sich nur
auf diese Dateien.

Gruß Hagen

Autor: OldBug (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke, Hagen!
Du sprichs mir wieder mal aus der Seele ;-)

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Hagen:
Aber auch bei einem minimalistischen Hal bist Du doch darauf
angewiesen, daß die MC gleich mächtig sind. Klar, wenn zwei
verschiedene MC jeweils einen Hardware-UART haben, dann kann man dessen
Benutzung schön in ein Headerfile packen. Aber was, wenn einer (weil er
billiger ist) keinen UART hat? Packst Du dann den Software-UART
ebenfalls in den HAL?
Das ganze Spiel gilt natürlich auch für Interruptprioritäten, Anzahl
Timer usw. usf.

Deswegen bringt ein kleiner HAL meiner Meinung nach nicht so furchtbar
viel.

Markus

Autor: Ratber (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Hagen

Schön,dann hab ich ja mit Bascom mein Hal schon.

LCD-ausgaben erledige ich auch nur per "LCD ........"


Nur hilft mir das bei anderen Sprachen recht wenig da es den Befehl LCD
nicht gibt.

Ich nüßte ihn als Prozedur definieren die den Befehl nur durchreicht
aber da fängt der spaß mit der Zeitverschwendnug schon an und die will
Ralf ja vermeiden.

Eine effektive Programierung ist immernoch "Direkt"

Die Hersteller müßten sich schon im Groben auf einen festen
Grundwortschatz einigen und wie Chancen für diesen Fall stehen brauche
ich ja nicht zu schreiben. gg



Meine  Frage an Ralf wäre dann sowas in der richtung wie
"Wieviel Performance und Reaktionszeit bist du freiwillig bereit
abzutreten ?"

Ohne Kompromiss ist da ja nun wirklich nix zu machen.


Nur mal so als Anmerkung oder so.

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>billiger ist) keinen UART hat?
>> Packst Du dann den Software-UART ebenfalls in den HAL?

Nein eben nicht. Es würde drei Sourcem geben, Header + C Source für die
UART Funktionen und 1 Header mit Makros die die Hardware anspricht
speziell für die UART Funktionen.

In den UART Source stünde also zb. sowas drinnen:

void UART_Put(char c) {
  UART_DATA_REG = c;
}

und UART_DATA_REG ist in der HAL-Header Datei als Makro/Define etc.
definiert -> #define UART_DATA_REG UDR -> für einen AVR.

Wird nun ein Softare UART draus ist das auch kein Problem, denn nun
würde man den HAL-Header mit anderen Makros/Defines umschreiben.

Der Compiler linkt diese Sachen ja direkt in das Program ein, ergo ist
die Frage von Ratber ebenfalls beantwortet, es wäre genauso effizient
wie eine "direkte" Programmierung.

Wie gesagt es ist doch reine Definitions- bzw. besser
Organsiations-Frage. Nämlich wie sauber und strukturiert man
programmiert. Wichtig ist doch nur das sich die Schnittstellen zur
Hardware namentlich und funktionstechnisch nicht unterscheiden, egal ob
der HAL für den AVR oder den PIC benutzt wird.

Wir alle arbeiten doch "meistens" schon so. Alle Ports/Pins/Register
sind doch schon in separate Dateien gepackt worden und mit diesen
arbeiten wir. Das muß man nur noch konsequenter in seiner täglichen
Arbeit umsetzen, zb. auch die Namensgebung dieser Dateien, und schwups
könnte man sagen alle Dateien die mit "HAL_" beginnen sind die
einzigsten Dateien in meinem Projekt die die Hardwarespezifischen
Sachen enthalten, ergo diese Dateien SIND unser HAL.

Der Sinn eines HAL's ist doch nur eine Verbesserung der Arbeitsabläufe
bei der Programmierung. Einerseits um eine Software schneller portieren
zu können und/oder andererseits damit ein DAU-Programmierer mit unserer
Software arbeiten kann, sozusagen ein Baukastenprogrammierer damit
zurecht kommt.

Gruß Hagen

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin moin,

ich denke jetzt habe ich mal wieder etwas mehr verstanden. Bisher habe
ich immer so programmiert, dass ich zum Beispiel ein UART-Modul hatte
das nur in der Lage war einzelne Bytes zu übertragen. Bei der PWM sieht
es ähnlich aus. Das PWM-Modul stellt eigentlich immer nur den Dutycycle
ein und erledigt die Basisinitialisierung der PWM-Timer. Also hatte ich
ja prinzipiell schon einen HAL und wusste nicht, dass es da so tolle
Begriffe für gibt :-). Ich hatte mir da wohl eine größere Sache drunter
vorgestellt (was es auf dem PC ja wahrscheinlich auch ist).
In meiner Software muss ich teilweise auch verschachtelte Interrupts
verwenden da mein Controller diese nicht unterstützt, d.h. ich
deaktiviere zunächst alle nicht benötigten Interrupts und aktiviere
dann die anderen global. Aber ich denke mal, dass ich an dieser Stelle
wohl nichts verbessern kann, sodass dieser Teil allgemeingültiger wird.
Man müsste dann ja grundsätzlich immer alle möglich Interruptquellen
behandeln auch wenn diese in der jew. Software garnicht verwendet
werden was dann wohl eine große Verzögerungszeit mit sich bringt. Ich
habe im Moment die Anforderung, dass ich optimalerweise nur
Verzögerungszeiten von etwa <5us in Kauf nehmen kann, da sonst meine
Zeitmessung nicht genau genug ist was dann wieder andere Nachteile für
mich hat.
@Markus:
>> Aber auch bei einem minimalistischen Hal bist Du doch darauf
>> angewiesen, daß die MC gleich mächtig sind.
Da ist wohl was dran und für mich dann wohl auch ein 'nein' für die
Programmierung eines richtigen HALs. Wenn bei uns der Controller
gewechselt wird, dann ist das im Moment eigentlich nur der Fall, wenn
der andere billiger ist. Dann hat der neue meist auch noch weniger
Funktionen sodass sich da eigentlich nicht so viele Gemeinsamkeiten
feststellen lassen (bei mir war es z.B. der Fall dass ich von einem
C164 auf einen H8Tiny wechseln musste).

Bis denne und viele Grüße,

Ralf

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.