BIOS für Mikrocontroller

>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.

> 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

>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?

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 ).

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.

>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.

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

>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/

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.

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

>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.

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

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

>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.

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.

>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.

> 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

>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.

> 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

>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.

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.

>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.

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.

Stefan schrieb:
> wie kurzsichtig viele Leute sind,

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

>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.