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?
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...
>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?
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.
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.
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 ).
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
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.
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.
>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.
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
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.
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
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.
>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.
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.
>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.
> 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.
>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
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.
>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
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.
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.
>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.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.