Forum: Mikrocontroller und Digitale Elektronik BIOS für Mikrocontroller


You were forwarded to this site from EmbDev.net. Back to EmbDev.net
von chris (Gast)


Lesenswert?

Hallo Alle,

schon einige Zeit mache ich mir Gedanken zu einem BIOS für 
Mikrocontroller.
Ich verwende immer wieder andere MC-Architekturen, auf die ich aber ein 
großteil meiner alten Software und Testprogramme mit umziehen will. 
Deshalb versuche ich, Schnittstellenfunktionen zu definieren, die für 
die meisten Architekturen einheitlich sind.

Folgende Peripheriefunktionen sollte das BIOS beinhalten:

serielle Schnittstelle: putch, getch
2 Test-Leds: setLED1,2
2 DA-Wandler ( könne auch durch PWM-Kanäle realisiert sein)
32 Bit IO-Port: read, write, setDir
16 AD-Wandler ( müssen nicht alle vorhanden sein ): readADC(n)
Timingfunktionen: getSysTime( uint32_t in_us), msleep(uint16_t ms), 
wait_until_msmultiple(uint16_t n)

Wer möchte gerne mit überlegen, welche Funktionen sinnvoll sind?

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

chris schrieb:
> Wer möchte gerne mit überlegen, welche Funktionen sinnvoll sind?
Die PC-Historie lehrt uns: ein BIOS an sich ist nicht sinnvoll.
Denn es ist nie fertig und hat immer Fehler.
Und das meine ich jetzt ganz und gar ohne Witz!

15 Millionen Google-Einträge zeichen ein Bild davon...
http://lmgtfy.com/?q=BIOS+problem

Und wenn schon:
mir fehlt in deiner Definition komplett die User-Schnittstelle. Keine 
Displayfunktionen und keine Tastatur...

von chris (Gast)


Lesenswert?

>mir fehlt in deiner Definition komplett die User-Schnittstelle. Keine
>Displayfunktionen und keine Tastatur...

Hallo Lothar,
die Frage wäre hier, wo zieht man die Grenze zwischen Betriebssystem und 
Bios?
An viele Mikrocontroller ist nicht unbedingt eine Tastatur und ein 
Display angeschlossen. Aber fast alle haben eine serielle Schnittstelle.
Bei der Frage nach einem Mikrocontroller-BIOS geht es sich auch darum zu 
entscheiden, welche Leitungsklasse von Mikrocontrollern angesprochen 
werden sollen. Meine Vorstellung geht hier von Atmega8 aufwärts. Das 
BIOS sollte also nicht so viele Resourcen verbrauchen, dass kein 
Userprogramm mehr in den Prozessor passt.

von Olaf (Gast)


Lesenswert?

> schon einige Zeit mache ich mir Gedanken zu einem BIOS für
> Mikrocontroller.

Leider nicht genug.

> Wer möchte gerne mit überlegen, welche Funktionen sinnvoll sind?

Das ganze Konzept ist nicht sinnvoll.

Und zwar gerade nicht weil es Fehler enthalten koennte! Denn dann 
wuerdest du diese Fehler irgendwann finden, beheben und dananch wuerden 
viele deiner Programme viel besser laufen.
Das Problem ist das so ein Bios irgendwann total fett ist weil ja immer 
mehr tolle Funktionen reinkommen die du bei einem bestimmten Project 
gebraucht hast. Irgendwann passen dann an sich kleine Programme nicht 
mehr in den Flash eines kleinen Controllers.

Allerdings hat der programmierende Teil der Menschheit schon vor vielen 
Jahren Libaries erfunden. Damit ginge das eleganter.

Trotzdem wirst du ab und an noch auf Probleme stossen. Ein ernstes 
Problem ist z.B die passende Libaryversion zu deinem Programm. Was 
machst du wenn du irgendwann einen Fehler in deiner Libary findest und 
ersetzt, sich aber andere alte Programme an die du garnicht mehr denkst 
sich auf den Fehler verlassen? Blinkt dein Controller dann mit der 
Libary-LED? :-)

> An viele Mikrocontroller ist nicht unbedingt eine Tastatur und ein
> Display angeschlossen. Aber fast alle haben eine serielle Schnittstelle.

Ja, meiner hier sogar neun Stueck. Aber was ist eine serielle 
Schnittstelle? Ist das etwas mit IRQ? Oder Polling? Welche Baudrate? 
Extra Funktion um die Parameter einzustellen obwohl sie nur einmal 
gebraucht wird? (Platz) Gibt es eine Steuerleitung fuer RS485 Treiber? 
Braucht man in manchen Projekten, in anderen aber nicht. Welche 
Portleitung wird verwendet? Gibt es einen FIFO Buffer? Wie gross ist 
der? Sicher nicht bei jedem Project gleich gross. Wo liegt er im 
Speicher?
Du siehst aus dem notwendigen Code in einem herkoemmlichen Project der 
vielleicht 1-2Seiten gross ist werden schnell 10-20Seiten wenn du alles 
erfassen willst was in der Praxis auftritt.

Olaf

von chris (Gast)


Lesenswert?

>Die PC-Historie lehrt uns: ein BIOS an sich ist nicht sinnvoll.
>Denn es ist nie fertig und hat immer Fehler.

Man könnte ja umgekehrt fragen: Wieso hat jeder PC ein BIOS, wenn es 
nicht sinnvoll ist?

von Karl H. (kbuchegg)


Lesenswert?

Aus historischen Gründen.
Das hat der PC vom CP/M geerbt.

von Karl H. (kbuchegg)


Lesenswert?

Das andere Problem, das mich immer wieder von derartigen 
Mini-Betriebssystemen bzw Komponenten in Maschinencode abhält, ist die 
Notwendigkeit, die Komponenten zur Laufzeit konfigurieren zu können.

Mach ich einen Source Code include, kann ich die Konfiguration mit ein 
paar #define erledigen.
Hab ich aber eine Object-Library geht das so nicht mehr. Und dann landet 
man dabei, dass man sich relativ viel Code aufzwirbelt, weil man dem 
Compiler keine Konstanten zum optimieren geben kann, sonden alles über 
Konfigurationsvariablen abwickeln muss.

von Oliver J. (skriptkiddy)


Lesenswert?

chris schrieb:
> Man könnte ja umgekehrt fragen: Wieso hat jeder PC ein BIOS, wenn es
> nicht sinnvoll ist?

Weil man dem PC erst mal beibringen muss, von der Festplatte zu booten. 
Ein µC weiß auch ohne BIOS, wo die addresse 0x00000000 im Flash ist.

von chris (Gast)


Lesenswert?

Karl heinz Buchegger schrieb
>Das andere Problem, das mich immer wieder von derartigen
>Mini-Betriebssystemen bzw Komponenten in Maschinencode abhält, ist die
>Notwendigkeit, die Komponenten zur Laufzeit konfigurieren zu können.

>Mach ich einen Source Code include, kann ich die Konfiguration mit ein
>paar #define erledigen.
>Hab ich aber eine Object-Library geht das so nicht mehr.

Hmm, ich bin mir nicht ganz sicher, ob der Begriff "BIOS" hier für 
Verwirrung sorgt. Wenn Du von einer Objekt-Library ausgehst, ist es 
schwierig, da was zu konfigurieren.
Das "BIOS" könnte meiner Meinung nach auch als Source-Code zur Verfügung 
stehen. Dann kann man z.B. die Geschwindigkeit der seriellen 
Schnittstelle vor dem Kompilieren mit #define definieren und dann 
während des Betriebs einfach ohne weiter Einstellung auf die serielle 
Schnittstelle via putch(c) zugreifen.

Meiner Meinung nach beinhaltet C ja schon einige Funktionen, die einem 
"BIOS" zugeordnet werden könnten: putch, getch, printf, fprintf, fopen

Wobei die File-Funktionen wie fopen eher dem Ursprung von C in der 
PC-Ära geschuldet sind und für die meisten Mikrocontroller eher 
unpraktisch sind.

Aus diesem Grunde benötigt es meiner Meinung nach ein paar 
standardisierte Mikrocontroller spezifische Funktionen die auf die 
spezifischen Peripheriekomponenten der Mikrocontroller zugeschnitten 
sind.
Da wären Ports, AD-Wandler, DA-Wandler und Timing Funktionen für 
definierte Zeitabläufe ( Oder wie sollte man in Standard C eine LED 
korrekt mit 1Hz blinken lassen ).

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

chris schrieb:
>>Die PC-Historie lehrt uns: ein BIOS an sich ist nicht sinnvoll.
>>Denn es ist nie fertig und hat immer Fehler.
> Man könnte ja umgekehrt fragen: Wieso hat jeder PC ein BIOS, wenn es
> nicht sinnvoll ist?
Es sollte schon längst abgeschafft sein (Stichwort EFI), aber leider 
hängen die ganzen Flash-Programmiergeräte-Hersteller noch so dran...
http://www.chip.de/artikel/EFI-Der-Nachfolger-des-BIOS_31716144.html

von TManiac (Gast)


Lesenswert?

Der eine oder andere hier wird bestimmt schon mal über AUTOSAR 
gestolpert sein. Das was der Themeneröffner hier sucht, wird da komplett 
beschrieben. Da die Spezifikationen offen legen kann sich jeder daran 
halten (man darf nur kein Geld damit verdienen). Es verbietet einem 
niemand die Ideen die da beschrieben sind in eigene Projekte zu 
übernehmen.
Wie mächtig oder schlank das System wird liegt vollkommen in den Händen 
des Software-Schreiberlings. Und wenn man will (und fähig ist) bekommt 
man auch eine volle Konfigurierbarkeit hin, welche wahlweise zur 
Compile-Zeit oder während des Aufstarten des Systems aktiv wird.

Aber zur Beruhigung kann man sage, dass selbst die großen Fische noch 
nicht den vollen Umfang haben.

von Karl H. (kbuchegg)


Lesenswert?

chris schrieb:

> Hmm, ich bin mir nicht ganz sicher, ob der Begriff "BIOS" hier für
> Verwirrung sorgt.

Das könnte sein, denn ....

> Wenn Du von einer Objekt-Library ausgehst, ist es
> schwierig, da was zu konfigurieren.
> Das "BIOS" könnte meiner Meinung nach auch als Source-Code zur Verfügung
> stehen. Dann kann man z.B. die Geschwindigkeit der seriellen
> Schnittstelle vor dem Kompilieren mit #define definieren und dann
> während des Betriebs einfach ohne weiter Einstellung auf die serielle
> Schnittstelle via putch(c) zugreifen.

Das sehe ich eher als Modulbibliothek an. Also Komponenten die in Source 
Code Form fertig vorhanden in irgendwelchen Verzeichnissen liegen und 
die ich bei Bedarf in mein Projekt mit einbinde.

Ein BIOS sehe ich mehr als Black Box an, die bereits auf dem µC vorliegt 
(wie auch immer die dort hin gekommen sein mag) und die mir Services zur 
Verfügung stellt.

> Meiner Meinung nach beinhaltet C ja schon einige Funktionen, die einem
> "BIOS" zugeordnet werden könnten: putch, getch, printf, fprintf, fopen

Die sind schon zu High-Level. Das ist minmal auf BDOS Level. BIOS wäre: 
Sektor lesen, Sektor schreiben. Also das was tatsächlich 
hardwarespezifisch zugeschnitten sein muss und als Grundbaustein für 
höhere Funktionen dient.

> Aus diesem Grunde benötigt es meiner Meinung nach ein paar
> standardisierte Mikrocontroller spezifische Funktionen die auf die
> spezifischen Peripheriekomponenten der Mikrocontroller zugeschnitten
> sind.
> Da wären Ports, AD-Wandler, DA-Wandler und Timing Funktionen für
> definierte Zeitabläufe ( Oder wie sollte man in Standard C eine LED
> korrekt mit 1Hz blinken lassen ).

Gerade bei Timern entsteht das Problem. Da gibt es einfach zu viele 
Möglichkeiten.

von chris (Gast)


Lesenswert?

>Gerade bei Timern entsteht das Problem. Da gibt es einfach zu
>viele Möglichkeiten.

Bei den Timern gibt es auf jeden Fall viele Möglichkeiten.
Allerdings sind es ein paar Grundfunktionen, die immer wider auftauchen:
msleep(n), usleep()?; uint32_t getSystime();
Diese Funktionen ließen sich standardisieren und in einem im Hintergrund 
laufenden Prozess aktualisieren.

Mir ist schon klar, dass man mit solchen standardisierten Funktionen 
immer auch einen Performance Verlust gegenüber direkt für das System 
gemachten Funktionen hat.

Was meisten fehlt ist eine Zeitfunktion mit konstanter Bremswirkung wie 
wait_for_next_msMultiple. Diese Funktion gibt es z.B. in Labview. Sie 
ermöglicht es, eine Schleife mit exaktem Timing laufen zu lassen, indem 
sie eine Schleife so lange bremst, bis eine bestimmte Zeitmarke erreicht 
wird.

TManiac (Gast) schrieb
>Der eine oder andere hier wird bestimmt schon mal über AUTOSAR
>gestolpert sein. Das was der Themeneröffner hier sucht, wird da
>komplett beschrieben.

Wie man daraus entnehmen kann ist die Einführung eines normierten 
Abstraktionslayers also durchaus in der Automobilindustrie üblich.

Allerdings weiß ich von solchen Normierungen, dass sie meist aus einer 
Interessengemeinschaft entstehen, bei der jedes einzelne Mitglied 
bestimmte Lobbyinteressen verfolgt und das Ergebnis meisten nicht 
optimal und überladen ist.

Deshalb plädiere ich für den Entwurf eines eigenen Standards, der für 
die MC-Netz Nutzer eher passt.

von Frank K. (fchk)


Lesenswert?

TI hat für seine DSPs ein DSP/BIOS.

www.ece.cmu.edu/~ee551/spru303.pdf

Kannst ja mal schauen, ob da was für Dich dabei ist.

fchk

von Karl H. (kbuchegg)


Lesenswert?

chris schrieb:

> Was meisten fehlt ist eine Zeitfunktion mit konstanter Bremswirkung wie
> wait_for_next_msMultiple. Diese Funktion gibt es z.B. in Labview. Sie
> ermöglicht es, eine Schleife mit exaktem Timing laufen zu lassen, indem
> sie eine Schleife so lange bremst, bis eine bestimmte Zeitmarke erreicht
> wird.

Tja.
Das Problem ist, dass so eine Funktionalität in Wirklichkeit selten 
zielführend ist. Exakte Timings, solange man sich nicht im einstelligen 
ns Bereich bewegt, macht man mit Interrupts und nicht mit 
Warteschleifen.

Und da siehst man dann auch schon das Dilemma.
Vernünftige Lösungen sind selten die 08/15 Lösungen die man in fertigen 
Code pressen könnte. Sie haben zwar immer wieder den gleichen logischen 
Aufbau, aber die Details sind verschieden.

von Reinhard Kern (Gast)


Lesenswert?

chris schrieb:
> Man könnte ja umgekehrt fragen: Wieso hat jeder PC ein BIOS, wenn es
> nicht sinnvoll ist?

damit er was Sinnvolles starten kann. Das BIOS ist vom Startup abgesehen 
längst kein BIOS mehr, da es nach dem Start von keinem heutigen System 
mehr benutzt wird; das was der Fragesteller machen will, ist eher ein 
HAL (Hardware Abstraction Layer).

Der Rest des sogenannten PC-BIOS ist eine systemunabhängige 
Hardware-Konfigurations-Software. Die ist aber nur deshalb sinnvoll, 
weil PCs immer noch sehr einheitlich sind, z.B. kann man Tastatur und 
eine relativ leistungsfähige Anzeige (VGA) voraussetzen. Für irgendein 
µP-System macht sowas keinen Sinn.

Gruss Reinhard

von chris (Gast)


Lesenswert?

>Die ist aber nur deshalb sinnvoll,
>weil PCs immer noch sehr einheitlich sind, z.B. kann man Tastatur und
>eine relativ leistungsfähige Anzeige (VGA) voraussetzen. Für irgendein
>µP-System macht sowas keinen Sinn.

An diesem Punkt bin ich genau anderer Meinung. Mir geht es gerade darum, 
Gemeinsamkeiten viele Mikrocontrollersysteme zu finden.

Dazu habe ich ganz am Anfang ein paar Funktionen vorgeschlagen:
>serielle Schnittstelle: putch, getch
>2 Test-Leds: setLED1,2
>2 DA-Wandler ( könne auch durch PWM-Kanäle realisiert sein)
>32 Bit IO-Port: read, write, setDir
>16 AD-Wandler ( müssen nicht alle vorhanden sein ): readADC(n)
>Timingfunktionen: getSysTime( uint32_t in_us), msleep(uint16_t ms),
>wait_until_msmultiple(uint16_t n)

Einige wichtige Ansätze sind im Film zu Autosar zu sehen ( nur bis zur 
Hälfte, der Rest ist Werbung der Firma ):
http://www.eb-tresos-blog.com/technologies/autosar/

von chris (Gast)


Lesenswert?

Ein gutes Beispiel für die Nützlichkeit eines 
Software-Abstraktions-Layers ist das Arduino-System.
Dazu folgender Code aus einem der Beispiele:
1
int sensorPin = A0;    // select the input pin for the potentiometer
2
int ledPin = 13;      // select the pin for the LED
3
int sensorValue = 0;  // variable to store the value coming from the sensor
4
5
void setup() {
6
  // declare the ledPin as an OUTPUT:
7
  pinMode(ledPin, OUTPUT);  
8
}
9
10
void loop() {
11
  // read the value from the sensor:
12
  sensorValue = analogRead(sensorPin);    
13
  // turn the ledPin on
14
  digitalWrite(ledPin, HIGH);  
15
  // stop the program for <sensorValue> milliseconds:
16
  delay(sensorValue);          
17
  // turn the ledPin off:        
18
  digitalWrite(ledPin, LOW);   
19
  // stop the program for for <sensorValue> milliseconds:
20
  delay(sensorValue);                  
21
}
Die Port Pins werden hier über Funktionen angesteuert. Der Vorteil ist, 
dass auf jedem Arduino-Board, sei es eine Decimilla oder eine Megaduino 
die selbe Software läuft.

von Reinhard Kern (Gast)


Lesenswert?

chris schrieb:
>>Die ist aber nur deshalb sinnvoll,
>>weil PCs immer noch sehr einheitlich sind, z.B. kann man Tastatur und
>>eine relativ leistungsfähige Anzeige (VGA) voraussetzen. Für irgendein
>>µP-System macht sowas keinen Sinn.
>
> An diesem Punkt bin ich genau anderer Meinung. Mir geht es gerade darum,
> Gemeinsamkeiten viele Mikrocontrollersysteme zu finden.
>
> Dazu habe ich ganz am Anfang ein paar Funktionen vorgeschlagen:
>>serielle Schnittstelle: putch, getch
>>2 Test-Leds: setLED1,2
>>2 DA-Wandler ( könne auch durch PWM-Kanäle realisiert sein)
>>32 Bit IO-Port: read, write, setDir
>>16 AD-Wandler ( müssen nicht alle vorhanden sein ): readADC(n)
>>Timingfunktionen: getSysTime( uint32_t in_us), msleep(uint16_t ms),
>>wait_until_msmultiple(uint16_t n)
>
> Einige wichtige Ansätze sind im Film zu Autosar zu sehen ( nur bis zur
> Hälfte, der Rest ist Werbung der Firma ):
> http://www.eb-tresos-blog.com/technologies/autosar/

Missverständnis: das nicht sinnvoll bezog sich auf das Hardware-Setup, 
nicht auf Hardware-Interfaces. Du kannst mir aber gern erklären, wie du 
dir eine interaktive Setup-Software vorstellst, die auf einer 8stelligen 
7-Segmentanzeige mit 5 Tasten ebenso läuft wie auf einem Bildschirm mit 
Farbgraphik und Windows-Tastatur.

Gruss Reinhard

von Karl H. (kbuchegg)


Lesenswert?

chris schrieb:

> Die Port Pins werden hier über Funktionen angesteuert. Der Vorteil ist,
> dass auf jedem Arduino-Board, sei es eine Decimilla oder eine Megaduino
> die selbe Software läuft.

Damit bist du nicht weit von dem entfernt, was BASCOM auch kann und was 
es so populär macht.
Und du läufst auch in das BASCOM Dilemma rein
Für 08/15 Sachen ist das völlig in Ordnung
Sobald es aber davon weg geht, bleibt dir wieder nichts anderes übrig 
als selbst Hand anzulegen. Und dann wird plötzlich der Segen zum Fluch. 
Denn du musst genau wissen, die die fertigen Komponenten die Hardware 
einsetzen. Eine Software USART, die einen Timer benutzt, wird dir deine 
ganze schöne Software-PWM über den Haufen schmeissen, die auf denselben 
Timer angewiesen ist.

von Christoph H. (mc-entwickler)


Lesenswert?

>Damit bist du nicht weit von dem entfernt, was BASCOM auch kann und
>was es so populär macht.
>Und du läufst auch in das BASCOM Dilemma rein
>Für 08/15 Sachen ist das völlig in Ordnung

Ja, und warum sollte eine C-Library standardisierte C-Library nicht die 
selbe Wertschätzung erfahren.

>Sobald es aber davon weg geht, bleibt dir wieder nichts anderes übrig
>als selbst Hand anzulegen. Und dann wird plötzlich der Segen zum Fluch.

Mit der selben Argumentation habe sicherlich viele Leute gegen die 
Einführung von Java argumentiert, weil es durch seine virtuelle Maschine 
die Performance eines Systems senkt. Aber siehe da: Java ist 
Milliardenfach verbreitet und hat seine Berechtigung.

>Denn du musst genau wissen, die die fertigen Komponenten die Hardware
>einsetzen. Eine Software USART, die einen Timer benutzt, wird dir deine
>ganze schöne Software-PWM über den Haufen schmeissen, die auf denselben
>Timer angewiesen ist.

Wenn wir jetzt mal einen Atmega8 als kleinsten Controller nehmen, sehe 
ich da jetzt kein Problem.
Im Arduino wird das nämlich genau so verwendet.

chris
>> Was meisten fehlt ist eine Zeitfunktion mit konstanter Bremswirkung wie
>> wait_for_next_msMultiple. Diese Funktion gibt es z.B. in Labview. Sie
>> ermöglicht es, eine Schleife mit exaktem Timing laufen zu lassen, indem
>> sie eine Schleife so lange bremst, bis eine bestimmte Zeitmarke erreicht
>> wird.

>Tja.
>Das Problem ist, dass so eine Funktionalität in Wirklichkeit selten
>zielführend ist. Exakte Timings, solange man sich nicht im einstelligen
>ns Bereich bewegt, macht man mit Interrupts und nicht mit
>Warteschleifen.

Sätze mit "man macht das so" sind immer etwas konservativ. Manchmal 
macht "man" Dinge nämlich anders.

folgendes Beispiel
1
...
2
...
3
code ...
4
toogleLed(0);
5
wait_for_next_msMultiple(500);
6
}
lässt eine LED mit 1Hz blinken.

von Chris M. (shortie)


Lesenswert?

Christoph H. schrieb:
> ...
> lässt eine LED mit 1Hz blinken.

Cool - genau sowas brauch ich - äh wie oft ?

Da hast du nacher in deinem "BIOS" 25 Funktionen, von denen man 
vielleicht 2-3 in einem Projekt braucht. Man liefert also mit dem 
Quellcode über 20 Funktionen mit die nicht genutzt werden - sowas sorgt 
für Verwirrung.

Bei einem PC ist das was anderes, da wird kaum ein Programmierer (die 
Anzahl von Treiberprogrammierern ist im Verhältnis zu 
Anwendungsprogrammierern sehr gering) soweit auf Hardwareebene gehen. Da 
wird auch nicht die Hardware speziell auf ein Projekt angepasst.

von chris (Gast)


Lesenswert?

>Da hast du nacher in deinem "BIOS" 25 Funktionen, von denen man
>vielleicht 2-3 in einem Projekt braucht. Man liefert also mit dem
>Quellcode über 20 Funktionen mit die nicht genutzt werden - sowas sorgt
>für Verwirrung.

Das sehe ich anders. Nimm z.B. die Libraries des AVR-GCC. Da finden sich 
ziemlich viele Funktionen wie z.B. EEPROM Zugriff oder die Funktionen 
zum Ansprechen des Watchdogs. Man könnte hier auch argumentieren, dass 
es zu viele Funktionen sind. Es stimmt, es gibt viele Funktionen, diese 
erleichtern den Benutzern aber das Leben.

>> lässt eine LED mit 1Hz blinken.
>Cool - genau sowas brauch ich - äh wie oft ?

Gut, ein wenig Abstraktionsfähigkeit ist zum Folgen dieses Threads schon 
notwendig.
Man kann relativ viele Aufgaben mit einer bestimmten Softwarestruktur 
erschlagen.
Eine etwas langsamere Haupt-While Schleife, die aber mit konstanter 
Zyklusrate läuft wozu eben oben genannter Bremsbefehl notwendig ist. 
Zusätzlich noch eine schelle zyklische Interruptroutine, in der schnelle 
kurze Funktionen bearbeitet werden.

von Purzel H. (hacky)


Lesenswert?

> serielle Schnittstelle: putch, getch
> 2 Test-Leds: set LED 1,2

Ist schon falsch. Blockierendes Senden und Empfangen ? Das kann's nicht 
sein. Und die Led's sind schrecklich trivial.

Zum glueck gibt's kein bios fuer einfach controller. Da bin ich froh 
allen code selbst begutachten zu koennen.

von chris (Gast)


Lesenswert?

>Blockierendes Senden und Empfangen ?
Nein, eigentlich nicht. Das kann man mit einer Funktion wie 
isCharReady() vermeiden.

von Spess53 (Gast)


Lesenswert?

Hi

chris schrieb:
>>Blockierendes Senden und Empfangen ?
> Nein, eigentlich nicht. Das kann man mit einer Funktion wie
> isCharReady() vermeiden.

Lustig, würde das auch eine Funktion wie isHeinBlöd() nicht auch können?

MfG Spess

von Karl H. (kbuchegg)


Lesenswert?

chris schrieb:
>>Blockierendes Senden und Empfangen ?
> Nein, eigentlich nicht. Das kann man mit einer Funktion wie
> isCharReady() vermeiden.

Ah. ja
Und eien längere Berechnung spicke ich dann laufend mit derartigen 
Abfragen und UART auslesen, damit ich kein Zeichen auf der UART verpasse 
:-)
Gut UART ist jetzt nicht das große Problem. Mit einer FIFO und Interrupt 
Steuerung ist das kein Thema und auch als Fertig-Modul gut handhabbar.

Du kannst es drehen wie du willst. Ohne Interrupts in irgendeiner Form 
kommt kein vernünftiges Programm aus. Das ist nun mal so, und das ist 
auch nicht weiter schwer.
Aber: Da gibt es das Problem, dass man für jeden Interrupt immer nur 1 
Handler hat. D.h. alle Funktionalitäten, die über denselben Interrupt 
abgehandelt werden sollen, müssen sich irgendwie in diese eine ISR 
einschmuggeln.

Dein LED Beispiel ist doch unterste Schublade. Denn genau das ist die 
Technik, die zwar für die ersten paar Programme ausreicht, für ein 
einigermassen praxistaugliches Beispiel taugt es eben nicht. Schon die 
simple Abfrage einer Taste im Programm wird dann zum Albtraum für den 
Benutzer. Die Tasten, bzw. die Programmreaktion auf einen Tastendruck 
fühlt sich dann schon so schwammig an, dass die Mehrzahl der Benutzer so 
ein Gerät am liebsten an die Wand schmeissen würden.

von chris (Gast)


Lesenswert?

>Dein LED Beispiel ist doch unterste Schublade. Denn genau das ist die
>Technik, die zwar für die ersten paar Programme ausreicht, für ein
>einigermassen praxistaugliches Beispiel taugt es eben nicht.

Wie man im Autosar-Video sehen kann, geht es bei der Frage der 
Standardisierung auch um die Frage nach Software Strukturen.

Zunächst einmal: Jeder Abstraktionslayer in der Software bringt auf die 
ein oder andere Art Leistungsverlust ins System.
So kann man Assembler sicherlich Speicher und Resourcenschonender 
Programmieren als C, C schneller als Java, und Java schneller als 
Python. Ebenfalls werden in der Industrie bei größeren Projekten 
Codegeneratoren eingesetzt, die aus Matlab-Simulink-Modellen C-Code 
erzeugen.
C lässt sich auf dem AVR sicherlich performanter programmieren als 
BASCOM. Und trotzdem wird BASCOM von vielen verwendet.
Der entscheidende Punkt für den Einsatz einer weniger performanten 
Technik ist die Zeitersparnis, die man erreicht, wenn man solche 
fertigen Tools einsetzt.
Obwohl ich schon mehr als 20 Jahre programmiere, verwende ich bisweilen 
das Arduino System. Einfach dann, wenn ich z.B. innerhalb von 3 Minuten 
ein Programm zum Auslesen eines AD-Wandlers brauche und das noch schnell 
an bestimmte Randbedingungen anpassen will.

Die avr-libc bietet hier ja schon ein ganze Menge an Funktionen, die 
standardisiert sind:
http://avr-libc.nongnu.org/user-manual/modules.html
Und eben im selben Stil sollte man weitere Funktionen einführen.

von TManiac (Gast)


Lesenswert?

Moin,

chris schrieb:
> Zunächst einmal: Jeder Abstraktionslayer in der Software bringt auf die
> ein oder andere Art Leistungsverlust ins System.

Damit meinst du aber nicht zwingend AUTOSAR?
Weil bei AUTOSAR wäre es zu mindestens von der Theorie her möglich, dass 
das fertig compilierte und gelinkte Program eben keine 
Laufzeitreduzierung gegenüber einem direkt umgesetzten C-Programm hat 
(AUTOSAR Code ist immer nur C oder ASM).
Um einfach mal das LED-Beispiel zu bringen:
Wenn die Applikation bei AUTOSAR ein LED einschalten will so sind 
mindestens die Module SWC (die eigentliche Applikation), RTE, und DIO 
beteiligt. Jedes Modul ruft eine entsprechende Funktion in dem darunter 
liegenden Modul auf (SWC->RTE->DIO).
Aber AUTOSAR verbietet es nicht, die "Funktionsaufrufe" zu mappen. 
Sprich man kann mit etwas Geschick, das ganze durch Makros lösen. Somit 
hat man im Sourcecode seine gewollte Abstraktionsschichten (die man 
normaler Weise nur noch konfiguriert und nicht mehr editiert) und das 
fertige Program greift dann "direkt" auf die Register zu.

Aber wie ich schrieb ist es "nur" möglich. Ich habe noch keine Umsetzung 
gesehen die eben so effizient ist.

Ich denke aber auch, dass man nie alles erschlagen werden kann, was so 
hier im Forum gemacht wird. Für den einen oder anderen kann die 
Abstraktion und Modularisierung Vorteile bringen. Andere werden eher an 
Minimallösungen ihrer Aufgaben festhalten.
Ich selber nutze in meinen Projekten relativ viel von AUTOSAR Gedanken 
(auch weil ich beruflich damit zutun habe). Es schreibt mir keiner vor, 
das ich für die Konfiguration meiner Module eine tolle graphische 
Oberfläsche nutzen muss.

von chris (Gast)


Lesenswert?

>Ich selber nutze in meinen Projekten relativ viel von AUTOSAR Gedanken

Hallo TMainac,

das klingt sehr interessant. Vielleicht könntest Du kurz eines Deiner 
Projekte beschreiben und welchen ganz konkreten Gedanken Du aus der 
Autosar-Philosophie da eingearbeitet hast.

von Olaf (Gast)


Lesenswert?

> Ich denke aber auch, dass man nie alles erschlagen werden kann, was so
> hier im Forum gemacht wird. Für den einen oder anderen kann die
> Abstraktion und Modularisierung Vorteile bringen. Andere werden eher an
> Minimallösungen ihrer Aufgaben festhalten.

Das Problem sehe ich darin das solche Sachen das Leben fuer Anfaenger 
einfacher machen und sagen wir mal Profis oder bessere erfahrenen Usern 
wird das Leben schwerer gemacht. Das fuehrt dann dazu das der Uebergang 
vom Anfaenger zum Profi viel schwieriger wird.
Und es hat dann teilweise unschoene Nebeneffekte. Wenn der Anfaenger 
merkt das eine an sich einfache Sachen, z.b die schnelle Reaktion auf 
einen Tastendruck, schwierig wird, dann wird er dazu neigen das Problem 
einfach zu loesen. Also einen Prozessor zu nehmen der schneller ist, 
mehr Strom verbraucht, einen dickeren Akku erfordert oder aehnliches. 
Aber es wird keine eleganten Loesungen geben die irgendwo auch den Spass 
am programmieren ausmachen.

Olaf

von Karl H. (kbuchegg)


Lesenswert?

Olaf schrieb:

> einen Tastendruck, schwierig wird, dann wird er dazu neigen das Problem
> einfach zu loesen. Also einen Prozessor zu nehmen der schneller ist,
> mehr Strom verbraucht, einen dickeren Akku erfordert oder aehnliches.

Ich nenne das gerne das PC-Syndrom.
Denn genau das ist in den letzten 15 Jahren auf dem PC-Sektor passiert.

Wen wundert es da, dass nicht wenige Anfänger glauben mit einem 
Prozessor unter 1GHz und weniger als 100MByte RAM kann man nichts 
Vernünftiges machen. Das muss man sich auf der Zunge zergehen lassen. 
Ein heutiger Standard-PC vom Aldi hat mehr Rechenleistung, mehr 
Speicher, mehr externen Speicher als die meisten Rechenzentren in den 70 
oder 80-er Jahren. OK. Bischen übertrieben, aber auch nicht so weit von 
der Wahrheit entfernt.

Zurück zum Thema:
Nicht falsch verstehen chris. Ich wäre sehr dafür, wenn es gelingen 
würde eine Art Standard-Modul-Bibliothek auf die Beine zu stellen, die 
in einer Art Standard-Framework eingebunden wird. Ev. ein kleiner 
Konfigurationswizard dazu, der eine Standardapplikation zur Welt bringen 
kann (aber bitte nicht so, wie das IAR macht. Deren Hex-Zahlen bei den 
Konfigurationsregistern verursachen bei mir Brechreiz)

Probiers. Aber sei nicht enttäuscht, wenn das dann so wird, das es 
ausser dir keiner benutzt.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Olaf schrieb:
> Das Problem sehe ich darin das solche Sachen das Leben fuer Anfaenger
> einfacher machen und sagen wir mal Profis oder bessere erfahrenen Usern
> wird das Leben schwerer gemacht.
Damit passiert dann das, was heute in jedem Windows-PC passiert: erst 
kommt mal das BIOS, initialisiert die ganzen Schnittstellen und lädt 
Windows. Das wiederum hat eigene Treiber und initialisiert die ganzen 
Schnittstellen nochmal.

von chris (Gast)


Lesenswert?

>Nicht falsch verstehen chris. Ich wäre sehr dafür, wenn es gelingen
>würde eine Art Standard-Modul-Bibliothek auf die Beine zu stellen, die
>in einer Art Standard-Framework eingebunden wird.

Hallo Karl heinz,
es freut mich, dass Du die Idee einigermaßen OK findest. Meine bisherige 
Erkenntnis aus diesem Thread ist, dass die Hauptschwierigkeit des 
Unterfangens darin besteht, den Rahmen festzulegen. D.h. herauszufinden, 
welche Anforderungen die Leute so im Schnitt an ihre Systeme haben.

Ich persöhnlich hätte gerne ein Framwork, welches ich auf den 
AVR-Prozessoren, Arm-Prozessoren und PC kompilieren kann. Wenn man den 
GCC und inttypes verwendet, hat man ja den Vorteil, dass man den Code 
auf jedem dieser System 1:1 kompilieren kann.

Vielleicht wären folgende Funktionen nützlich:
- LED Funktionen
- Taster Funktionen
- LCD ansteuerun
- I2C
- Timer Funktionen
- DA-Wandler Schnittstellen
- AD-Wandler Schnittstellen
- Kommunikationsroutinen zum Datenaustausch zwischen den Systemen, z.B. 
PC u. Mikrocontroller

Um das ganze von vorne herein auf Praxistauglichkeit abzuschätzen, wäre 
es vielleicht nützlich, sich ein paar Beispielprojekte auszudenken. So 
in etwa wie der Bau eines DCF Weckers mit LCD Display.

>Probiers. Aber sei nicht enttäuscht, wenn das dann so wird, das es
>ausser dir keiner benutzt.

Ich für mich selber habe schon einige Ansätze dazu gemacht. Mir scheint 
es aber sehr nützlich, wenn viele Leute sich für diese Idee begeistern 
könnten.

von Olaf (Gast)


Lesenswert?

> Ich nenne das gerne das PC-Syndrom.
> Denn genau das ist in den letzten 15 Jahren auf dem PC-Sektor passiert.

Seufz, ich bin leider auch schon alt genug um mich darueber immer 
aufzuregen. Es ist geradezu unglaublich wie langsam heute selbst 
einfache Dinge ablaufen weil sie so schlecht programmiert sind.

> Ich für mich selber habe schon einige Ansätze dazu gemacht. Mir scheint
> es aber sehr nützlich, wenn viele Leute sich für diese Idee begeistern
> könnten.

Begeistern koennen wir uns da alle fuer. Bloss haben wir halt schon die 
Erfahrung gemacht das es nicht viel bringt.

Ich habe das was du da willst vor Jahren mal fuer GrafikLCDs gemacht.
Das waren im Prinzip unterschiedliche Basislibaries fuer LCDs mit 
unterschiedlichen Controllern und unterschiedlichen Aufloesungen.
Am ende gibt es dann eine Funktione set_pixel.

Darauf baut dann eine Libary auf welche Linien, Kreise und aehnliches 
macht. Und darauf baut dann wieder eine Libary auf die mir printf zur 
Verfuegung stellt. Und darauf dann wieder eine widgetlibary mit 
Auswahlboxen und aehnlichem.

Klingt super oder? Ich kann einfach ein Display umstecken, aendere ein 
define und alles laeuft.

Nachteile: Es wird langsam. Jedes Pixel muss durch alle Routinen. Zur 
ausgaben eines Zeichens muessen viele Pixel gesetzt und addressiert 
werden.
Irgendwann kommt der Wunsch nach etwas neuen auf. Sagen wir mal die 
Funktion get_pixel. Nicht alle Display unterstuetzen das aber. Also 
Schattenram. Aber hat die Anwendung an der du gerade programmierst noch 
genug freien Ram auf den Prozessor? Oder aber das Display unterstuetzt 
ein auslesen seines Rams, aber du hast genug Ram im Prozessor. 
Vielleicht willst du dann entgegen deiner Libarievorgabe doch wieder 
Schattenram benutzen weil der Zugriff darauf viel schneller ist?
Du siehst, es wird wieder kompliziert.

Aber wir halten dich nicht ab eigene Erfahrungen zu sammeln!

Olaf

von chris (Gast)


Lesenswert?

>Klingt super oder? Ich kann einfach ein Display umstecken, aendere ein
>define und alles laeuft.

Ja, klingt gut.

>Irgendwann kommt der Wunsch nach etwas neuen auf.

So ist es, das Leben ist Veränderung.
Es ist wie weiter oben schon erwähnt immer so, dass ein bestimmtes 
Systemdesign bestimmte Einschränkungen macht.
Aber nimm z.B. Bascom. Dort gibt es einfach viele vorgefertigte 
Funktionen, die sich einfach benutzen lassen. Um die Leute benutzen es. 
Es bietet eben mit all seinen Einschränkungen doch eben auch enorme 
Erleichterungen bei der Softwareerstellung.

von chris (Gast)


Lesenswert?

So wie es scheint, hat ARM eine allgemeine Softwareschnittstelle für 
seine Controller definiert:

http://www.arm.com/products/processors/cortex-m/cortex-microcontroller-software-interface-standard.php

So etwas könnte man für die AVR-Prozessoren auch einführen.

von Ziff (Gast)


Lesenswert?

>Dann kann man z.B. die Geschwindigkeit der seriellen
Schnittstelle vor dem Kompilieren mit #define definieren und dann
während des Betriebs einfach ohne weiter Einstellung auf die serielle
Schnittstelle via putch(c) zugreifen.

Meiner Meinung nach beinhaltet C ja schon einige Funktionen, die einem
"BIOS" zugeordnet werden könnten: putch, getch, printf, fprintf, fopen

----

Das Duemmste das ich seit langem hoerte. Einen Filezugriff auf die 
serielle Schnittstelle stuelpen... das der PC dieses Konzept auch hat 
macht es nicht besser. So macht man jedes Protokoll kaputt. Es gibt 
Protokolle, die haben einen Timeout auf den Meldungen, dann gibt es 
Protokolle, die aendern die Baudrate zwischen den Meldungen. Zuden ist 
blockierend zu programmieren schlechter Stil, schwer zu debuggen.

von Stefan (Gast)


Lesenswert?

Es ist doch immer wieder erstaunlich, besonders wenn man diesen Thread 
durchliest, wie kurzsichtig viele Leute sind, die im MC-Netz posten.

Und wie diese dann einige Jahre später von der realen Entwicklung 
eingeholt werden:
Beitrag "C++ auf einem µC - im WIKI?"

Ich finde, der Link zeigt sehr schön, wie es heute gang und gäbe ist 
eine Hardware-Abstraktionsschicht auf Mikrocontrollern einzuführen.

von Tulsa (Gast)


Lesenswert?

Stefan schrieb:
> wie kurzsichtig viele Leute sind,

Wie weit kannst Du blicken? Auf das Datum zum Beispiel.

von Stefan (Gast)


Lesenswert?

>Wie weit kannst Du blicken? Auf das Datum zum Beispiel.

Das ist ja genau der Punkt. Die Entwicklung war vor fünf Jahren schon 
abzusehen, wie der Eingangspost zeigt.
Allerdings, nicht für den Durchschnitt des MC-Netz. Die hinken der 
Entwicklung eher 5 Jahre hinterher.

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
Noch kein Account? Hier anmelden.