Ich habe mir gerade mal das AVR Ada Projekt auf Sourceforge angeschaut. Aber das sieht ziemlich verlassen aus. Ist das tot? Vor 11 Monaten war der letzte Commit
Ada schön und gut, aber es fehlt der Bedarf in der realen Welt. C ist vielleicht nicht optimal, aber viel verbreiteter bei AVRs.
VHS war auch nicht optimal und hat sich verbreitet ;) Schade, dass die guten Dinge so oft unter den Tisch fallen
Hans schrieb: > Schade, dass die guten Dinge so oft unter den Tisch fallen Meistens liegt es daran, dass die vermeintlich guten Dinge andere Nachteile haben, gerne ist dass der Preis und selten akzeptieren dass die Fans der vermeintlich guten Dinge.
Hannes Jaeger schrieb: > Gab es nicht gerade erst eine neue ADA-Release für AVR? Man google mal > "GNAT GPL 2011" Jetzt wo du's sagst... Aber ist da in der GPL Version AVR Support drin? Ich finde nix. Alles was ich finde bezieht sich auf GNAT Pro. Bei den Downloads finde ich nur ein avr-elf-windows Paket. Hab aber Linux
Mal aus reiner Neugier - was sind die Vorteile von ADA ? Ich kenne die ADA-Sprache gar nicht, C dagegen relativ gut, würde mich freuen, wenn jemand schnell die + und - Punkte auflisten könnte ...
fatwombat schrieb: > Mal aus reiner Neugier - was sind die Vorteile von ADA ? Ein Vorteil steht bei Wikipedia > Ada zielte ursprünglich auf eingebettete (embedded) und Echtzeit-Systeme (real-time) und wird auch heute noch meist für diese Zwecke verwendet. Unter anderem soll die Bitmanipulation einfacher sein. Ada wird oft dort eingesetzt, wo es um sicherheitskritische Anwendungen geht. Berühmtes Beispiel ist die Ariane Rakete. Nachteile? Geringe Verbreitung
> Ada zielte ursprünglich auf eingebettete (embedded) und Echtzeit-Systeme >(real-time) und wird auch heute noch meist für diese Zwecke verwendet. Ja? Wer?
MCUA schrieb: > Ja? Wer? Steht doch oben schon. Ariane Rakete. Weiter ein Teil der Rechner der ISS auch. Je nachdem für was die Rechner zuständig sind.
> Ada zielte ursprünglich auf eingebettete (embedded) und Echtzeit-Systeme >(real-time) und wird auch heute noch meist für diese Zwecke verwendet. >> Ja? Wer? >Steht doch oben schon. Ariane Rakete. Weiter ein Teil der Rechner der >ISS auch. Und deswegen wird es MEIST für embedded-systems verwendet? Quatsch.
Schön eingebettet in der Rakete und dem International Star Ship. Warum denn nicht? ISS doch kalt da oben...
MCUA schrieb: > Und deswegen wird es MEIST für embedded-systems verwendet? > Quatsch. Mäßige mal deinen Ton. Wenn du so unpräsize Fragen stellst dann must du dich nicht wundern, wenn nicht eine dir genehme Antwort (mit belastbaren Aussagen) kommt.
MCUA schrieb: > Ich bezweifele auch, dass alle Teile der Ariane Rakete mit ADA progr. > sind. Und wo hast das gelesen, dass das so sein soll?
ADA ist eine zertifizierte Sprache. Die lebt von der Zertifizierung. Es gibt eine Suite von Standardproblemen/Standardkonstrukten, da muss man den Compiler druberlassen und zum vordefinierten Resultat kommen. Um in den Kreis der Erlauchten zu kommen, dh mal die Suite der Probleme/Konstrukte zu bekommen, muss man happig abdruecken. Die bestandene Suite drueckt sich dann in der Versionsnummer aus. Die Suite wird up-to-date gehalten, und der Compilerhersteller muss mitziehen. Da ist dann nix mit Opensource. Deswegen kostet ein Ada Compiler auf von 5kEuro aufwaerts. Ein zertifizierter Compiler bedeutet ein Compiler setzt eine Sourcecode zertifiziert um. Dh nacher muss man nur noch den programmierten Formalismus ueberpruefen. Ada ist eine ganz andere Welt. Mit einem C-Ansatz ueberprueft man die Funktionalitaet mit den Faellen, die einem in den Sinn kommen und gut ist. Mit Ada geht man viel vollstaendiger vor. Meist ist das Einsatzgebiet der Applikation so, dass man sich keinen(!) Fehler erlauben kann. zb im Spaceshuttle. Da ist ein Bootloader zum Updaten der Firmware eher unrealistisch. Als Ada Programmierer muss man sich auch um die Anpassungen der Zertifizierung kuemmern, dh die Releases der Zertifizierungskommision lesen und ueberpruefen, ob der neu entdeckte Fehler/Unklarheit zu einem Fehler fuehren kann. Ich denke das Ada-zertifizierungsframework passt schlecht zur Modellpolitik von Atmel, dauernd die Controller zu wechseln, staendig neue Typen und die Alten verschwinden... wenn ich diese Zertifizierung mal mit einem Produkt durch bin, moechte ich den selben Controller die naechsten 20 Jahre erwerben koennen. Sorry. ist leider so. Und den Compiler moechte ich auch die naechsten 20 Jahre gewartet haben. Da ist nichts mit Opensource, und der 5er fuer den Compiler ist ein Klacks bei diesem Umfeld.
Oktav, Deine ausführliche Erklärung (danke, wirklich gut!) führt mich zur Frage - was für µC/Prozessoren nehmen sie denn für die SpaceShuttle? 8052-Derivate, Pentiums ???
Ich kann mich schwach an was erinnern, dass die Nasa vor einiger Zeit mal nach alten Mikrocontrollern gesucht hat für die Spaceshuttles. Welche das genau waren weiß ich nimmer genau, aber Pentium warens nicht, eher was in die 80.. richtung. (ohne garantie, evtl. findet ja noch wer den artikel)
Oktav Oschi schrieb: > Ich denke das Ada-zertifizierungsframework passt schlecht zur > Modellpolitik von Atmel, dauernd die Controller zu wechseln, staendig > neue Typen und die Alten verschwinden... wenn ich diese Zertifizierung > mal mit einem Produkt durch bin, moechte ich den selben Controller die > naechsten 20 Jahre erwerben koennen. Dann kannst du wohl mit 8048 weiterarbeiten. Viel mehr dürfte deinen hier postulierten Kriterien kaum genügen. (Ob man mit derem miserablen ESD-Verhalten wirklich besser kommt? ;-) Aber zum Glück kann man Ada auch ohne diesen Krempel benutzen, wenn man nicht gerade Flugzeuge oder Raketen damit steuern will, und GNAT ist dafür genau der Weg, wenn man trotzdem Ada machen will. AVR-Ada hat ja auch nichts mit Atmel und seiner Bauelementepolitik zu tun: der einzige Schnittpunkt zwischen beiden sind die AVRs selbst, auf denen der generierte Code dann laufen soll. Ansonsten steht da Atmel in keiner Weise hinter dem Projekt dahinter.
Der ERC32 wurde von Temic (jetzt) ATMEL hergestellt und wird(!) in der Raumfahrt eingesetzt und unter anderem auch in Ada programmiert. Allerdings gibt es, soweit ich weiß, nur noch alte Lagerbestände davon. Wer ein paar Infos mag: http://microelectronics.esa.int/erc32/erc32.html http://en.wikipedia.org/wiki/ERC32
Eine Alternative zu ADA die wirklich angeblich für Dinge wie Airbags verwendet wird ist bewiesener Assemblercode. Da wo es nicht wirklich funktionieren muss kann man auch C verwenden.
Christian Berger schrieb: > Eine Alternative zu ADA die wirklich angeblich für Dinge wie Airbags > verwendet wird ist bewiesener Assemblercode. > > Da wo es nicht wirklich funktionieren muss kann man auch C verwenden. Wieso schliesst das C aus? Man kann ebenso den von einem C-Compiler erzeugten Code verifizieren, wird tB für Airbus so gemacht. Allerdings reicht es nicht, den Assemblercode zu betrachten, was zählt ist das fertig gelinkte und lokatierte Binary (Speicherablage, Cache-Verhalten, etc.) Oktav Oschi schrieb: > Die bestandene Suite drueckt sich dann in der Versionsnummer aus. > Die Suite wird up-to-date gehalten, und der Compilerhersteller muss > mitziehen. Da ist dann nix mit Opensource. Wenn's GCC ist, dann ist es Opensource. Was aber nicht bedeutet, daß der kostenlos sein muss wie du schon schriebst. > Ein zertifizierter Compiler bedeutet ein Compiler setzt eine Sourcecode > zertifiziert um. Was de facto dann bedeutet, daß Optimierungen obsolet sind. Man muss also eine etwas dickere Hardware vorhalten. Johannes O. schrieb: > Ich kann mich schwach an was erinnern, dass die Nasa vor einiger Zeit > mal nach alten Mikrocontrollern gesucht hat für die Spaceshuttles. > Welche das genau waren weiß ich nimmer genau, aber Pentium warens nicht, > eher was in die 80.. richtung. (ohne garantie, evtl. findet ja noch wer > den artikel) Da ist sowas wie ne Liste http://www.cpu-galaxy.at/Article/cpu_in_space_GERMAN.htm Ein HAL9000 fehlt allerdings.
Das war die Nasa Sucht Uralt... Geschichte. http://www.heise.de/newsticker/meldung/NASA-sucht-im-Internet-nach-uralten-Chips-59066.html
x86Opi schrieb: > Das war die Nasa Sucht Uralt... Geschichte. > http://www.heise.de/newsticker/meldung/NASA-sucht-... Hehe, ja das ist mir grad auch in den Sinn gekommen. Da stand vor Jahren etwas in der C't. Und um C auch im sicherheitsrelevanten Bereich einsetzten zu können gibt es z.B. http://www.splint.org/
Naja. Ada ist schon eine feine Sache, zB einhaelt es Echtzeit in der Sprache. Da muss man nicht erst einen Kernel einbinden. Legendaer ist zB das Select-Accept, was bei Windows WaitforMultipleObject heisst. Das ist Compilermaessig echt hart zu implementieren.
Oktav Oschi schrieb: > Naja. Ada ist schon eine feine Sache, zB einhaelt es Echtzeit in der > Sprache. Da muss man nicht erst einen Kernel einbinden. Dieser Teil ist meines Wissens bei AVR-Ada jedoch nicht implementiert (klar, dann hätte man ja noch ein ganzes OS mit implementieren müssen, mit Timern und allem).
Timer hat man ja sowieso. Einen Scheduler braucht man irgendwie ja auch. Oder arbeiten alle wie ich mit Zustandsmaschinen ? Ein OS unterscheidet sich von einem Kernel noch durch einem Loader.
Oktav Oschi schrieb: > Timer hat man ja sowieso. Allerdings braucht ein Laufzeitsystem wie das von Ada dann einen Timer, der dem Laufzeitsystem vorbelegt ist. Der Anwender hat also bezüglich der Hardware nicht mehr die freie Wahl. Außerdem hängt das alles wieder vom tatsächlich benutzten Takt, möglichen Schlafszenarien etc. pp. ab. Wenn man sowas implementieren will (und dann auch noch normgerecht), dann wird man sich wohl wirklich nur auf einige wenige Controllertypen beschränken können. AVR-Ada (soweit ich es verfolgt habe) scheint dagegen den Weg zu wählen, sich (wie AVR-GCC auch) um die Hardware selbst nicht zu kümmern, d. h. diese bleibt komplett in der Verwaltung des Anwenders. Es ist also eher ein Pendant zum AVR-GCC mit einer anderen Sprache als Grundlage denn das komplette Programmiersystem, das ein normgerechtes Ada gern sein möchte. > Einen Scheduler braucht man irgendwie ja auch. In vielen Fällen im AVR nicht. Dort kommt man oft genug mit einer Art kooperativem Multitasking aus, einige wenige höher priorisierte Tasks laufen direkt in der ISR, der Rest wird in der main loop anhand von Flags (oder eben als state machine) abgearbeitet. > Oder arbeiten alle wie ich mit Zustandsmaschinen ? Die deutsche Bezeichnung wäre wohl "zustandsgesteuerter Automat". > Ein OS unterscheidet > sich von einem Kernel noch durch einem Loader. Nein, ein OS soll (u. a.) die Hardware verwalten. Zumindest gehört dies zu seinen Aufgaben, die ich mal im Studium gelernt habe. (Folglich war MS-DOS beispielsweise kein richtiges OS, denn jede zweite Applikation hat die Hardware am DOS vorbei selbst verwaltet, weil das OS unfähig/-tauglich dazu war.)
Alter Falter schrieb: > Und um C auch im sicherheitsrelevanten Bereich einsetzten zu können gibt > es > z.B. http://www.splint.org/ Daß lint einen zertifizierten Compiler ersetzen kann, möchte ich bezweifeln. Der prüft den Quelltext - der Compiler bleibt unberücksichtigt und darf im Zweifelsfall den letzten Schrottcode generieren, ohne daß lint daran etwas aussetzen kann. Ursprünglich sollte lint die armselige Analyse der C-Compiler verbessern.
Uhu Uhuhu schrieb: > Ursprünglich sollte lint die armselige Analyse der C-Compiler > verbessern. Wobei das nichts mit Unfähigkeit der Compilerbauer zu tun hatte damals, sondern damit, dass man nur 64 KiB Code pro Applikation auf einer PDP-11 benutzen konnte. Daher hat man die semantische Analyse vom eigentlichen Compiler getrennt.
Na ja, das ist eigentlich nur die halbe Miete. Man hätte lint auch als Extra-Paß in den Compiler integrieren können. Generell hat man in der Zeit eben mit Gottvertrauen programmiert - Funktionen wie str*, *printf & Co. geben beredtes Zeugnis davon. Ich denke, das größere Problem war die Laufzeit auf den langsamen Riesenkisten, die gegen obigatorisches linten sprach - deswegen wurden Sprachen auch gerne mit dem Ziel der Einpaßcompilierbarkeit entworfen. Heute gibt es keinen vernünftigen Grund mehr, einen C-Compiler ohne ausführliche lint-Funktionalität zu bauen.
>Nein, ein OS soll (u. a.) die Hardware verwalten.
Selbst wenn ein OS die Hardware 'verwalten' kann, kann man immer auch am
OS vorbei programmieren.
Das sind ja nur OS-Funktionen, die man aufrufen kann aber nicht muss.
Einen (irgentwie gearteten) Scheduler hat man immer, und wenn es nur
eine MainLoop ist. Von daher ist der 'Übergang' von Nicht-OS zu OS
fliessend.
MCUA schrieb: > Selbst wenn ein OS die Hardware 'verwalten' kann, kann man immer auch am > OS vorbei programmieren. > Das sind ja nur OS-Funktionen, die man aufrufen kann aber nicht muss. So einfach ist das zumindest bei "richtigen" Betriebsystemen nicht. Das Mindeste ist, daß das OS die Kontrolle über eine Hardware-Komponente an eine andere Instanz abgibt und so die Verwaltung deligiert. Häufig handelt es sich bei diesen "Instanzen" um Treiber, die im OS-Kontext laufen und damit zu OS-Komponenten werden. Z.B. bei Windows wirst du als nichtprivilegierter Prozeß kaum die Kontrolle über irgend welche vom System verwaltete Resourcen bekommen - die sind durch das Hardware-Privilegiensystem vor Fremdzugriffen geschützt. Versucht man es trotzdem, dann ist der Prozeß ganz schnell tot, wegen "access violation".
MCUA schrieb: > Einen (irgentwie gearteten) Scheduler hat man immer, und wenn es nur > eine MainLoop ist. Der hilft dir aber für die geforderten Echtzeitfähigkeiten des Ada-Laufzeitsystems nicht. Ansonsten, siehe Uhus Antwort: in einem richtigen OS kann man nicht am System vorbei auf die Hardware zugreifen. Gerätetreiber sind natürlich formal Bestandteil des OS, denn sie implementieren einen Betriebssystemdienst für das bestimmte Gerät.
.. und Windows ist gerade das richtige Beispiel dafuer... deren Comport Treiber ist eine richtige Katastrophe.
Die Hardware Kontrolle an ein OS abzugeben macht nur Sinn, wenn auch mehrere unabhaengigen Prozesse auf die Hardware zugreifen. Wenn aber alles aus einem Guss ist, kann die Applikation auch selbst auf die Hardware zugreifen.
Oktav Oschi schrieb: > Die Hardware Kontrolle an ein OS abzugeben macht nur Sinn, wenn auch > mehrere unabhaengigen Prozesse auf die Hardware zugreifen. Wenn aber > alles aus einem Guss ist, kann die Applikation auch selbst auf die > Hardware zugreifen. Genau. MS-DOS forever. "Haben wir ja schon immer so gemacht." Das rutscht jetzt aber sehr weit von Ada weg.
Oktav Oschi schrieb: > eine UART Warum eigentlich die UART? Das ist eine Abkürzung für Universal Asynchronous Receiver Transmitter und sowohl Empfänger, als auch Sender sind im Deutschen maskulin. Mit die Art hat das auf jeden Fall noch nichtmal im Entfernten was zu tun. > Die Hardware Kontrolle an ein OS abzugeben macht nur Sinn, wenn auch > mehrere unabhaengigen Prozesse auf die Hardware zugreifen. Wenn aber > alles aus einem Guss ist, kann die Applikation auch selbst auf die > Hardware zugreifen. Hm, das ist so eine Sache, vor allem, wenn eine Software modular und pflegbar sein soll. Da ist es durchaus sinnvoll, wohldefinierte Schnittstellen einzuziehen, die zumindest äußerlich nicht all zu sehr von dem abweichen, was man von richtigen OSen kennt. Was für einen Tiny13 recht ist, ist für einen ARM nicht unbedingt billig...
Ja. Aber es sollte die Funktion erfuellen. Ich hatte das mal mit einem WinNT und einem externen Device, das im Protokol drin die Baudrate gewechselt hat. Das WinNT hat sich geschlagene 1.7 sekunden Zeit gelassen die Baudrate zu wechseln, waehrend wir alle wissen es ist effektiv nur das Baudratenregister neu zu beschreiben. Natuerlich ging's dann nicht weiter, denn die Meldung war dann schon vorbei.
Oktav Oschi schrieb: > Das WinNT hat sich geschlagene 1.7 sekunden Zeit > gelassen die Baudrate zu wechseln Nur, weil ein Betriebssystem schlecht implementiert ist, heißt das ja noch lange nicht, dass das Prinzip (die Hardwaresteuerung dem OS zu überlassen) schlecht wäre. Ganz davon abgesehen: das nehme ich dir so nicht ab. Das JTAG ICE mkII wechselt seit Jahr und Tag, wenn man es via RS-232 betreibt, zwischen initialen 19200 Bd und vollen 115200 Bd im Betrieb, ohne dass ich von jemandem gehört hätte, dass dies ein Problem bereiten würde.
Oktav Oschi schrieb: > Ich hatte das mal mit einem > WinNT und einem externen Device, das im Protokol drin die Baudrate > gewechselt hat. NT war ja schließlich der erste Versuch von M$, vom Konzept des DOS-Extenders weg zu einem richtigen Betriebsystem zu kommen... Was glaubst du, was dieses Windows 3 und seine 9x-Ausläufer bis hin zu ME für ein Krampf waren.
Das war auf einem 32MHz 386 glaub ich mich zu erinnern. Der war mit einem UART mit 19200baud schon zu 25% belastet. Und der Baudratenwechsel war nicht zwischen einem Protokol, sondern im Protokol. Dh das Command wurde geschickt, und die ACK-Antwort wurde schon auf der neuen Baudrate erwartet. Quasi innerhalb 100ms
Bitte kein Cut & Paste, insbes. nicht ohne Quellenangabe.
Oktav Oschi schrieb: > Das war auf einem 32MHz 386 glaub ich mich zu erinnern. Der war mit > einem UART mit 19200baud schon zu 25% belastet. Hmm. Windows habe ich nie gemacht, vielleicht war das ja wirklich so krückig. Bei FreeBSD's Serielltreiber waren Freaks am Werk, die es darauf angelegt haben, dass man selbst auf derartiger Hardware 115200 Bd verkraftet, und 19200 Bd ließen sich problemlos ohne flow control verarbeiten. > Und der Baudratenwechsel > war nicht zwischen einem Protokol, sondern im Protokol. Ja, das macht das JTAG ICE auch, außer dass es nicht so blöd war, bereits das ACK mit der neuen Datenrate zu senden. Dass jedoch request-response-Protokolle Mist sind und bereits zu Zeiten von Kermit und UUCP veraltet waren, hat den Machern des JTAG ICE niemand in der Schule erzählt. ;-) Aber wir bewegen uns jetzt von Ada immer weiter weg. Ich kann nur meinen Rat von oben nochmal wiederholen: wenn man am derzeitigen Stand von AVR-Ada interessiert ist, fragt man wohl am besten die Entwickler dieser Toolchain.
>Ansonsten, siehe Uhus Antwort: in einem richtigen OS kann man nicht >am System vorbei auf die Hardware zugreifen. Doch. Obwohl es nicht so gedacht ist, kann man zB auch das complette Windows oder Linux (das ja nicht echtzeitfähig ist) mit höchst prio INT complett umgehen. Das wird bei manchen Echtzeit'Zusätzen' gemacht. (wer hat schon Windows im EmbeddedSystem) Und die RTOSe, die die 'dollste' Kapselung (mit langatmiger Prozessverwaltung, MMU usw) haben (die man lt. Hersteller immer benutzen sollte), sind extrem langsam. Wie gesagt, der Übergang ist fliessend.
MCUA schrieb: > Doch. Obwohl es nicht so gedacht ist, kann man zB auch das complette > Windows oder Linux (das ja nicht echtzeitfähig ist) mit höchst prio INT > complett umgehen. Das wird bei manchen Echtzeit'Zusätzen' gemacht. Und das macht man mit einem Treiber, der per Definition OS-Komponente ist... Treiber sind häufig echtzeitfähig, wenn die betreffende Hardware das erfordert, z.B. ein UART, der eben einfach Daten verliert, wenn er nicht schnell genug bedient wird. > Wie gesagt, der Übergang ist fliessend. Klar, aber wer auf einer Hardware ohne geschützem Kernel-Mode der Versuchung nicht widerstehen kann, am OS vorbeizupfuschen, der kann sich erfahrungsgemäß ganz bös die Pfoten dabei verbrennen. Es gibt wirklich genug gute Gründe, gewisse vorgegebene Strukturen einzuhalten.
>Und das macht man mit einem Treiber, der per Definition OS-Komponente >ist... Muss nicht. Es kann eine simple ISR sein. >Es gibt wirklich genug gute Gründe, gewisse vorgegebene Strukturen >einzuhalten. Ja, manchmal. Und 'gepfuscht' ist es nur, wenn es falsch gemacht wurde.
MCUA schrieb: > Muss nicht. Es kann eine simple ISR sein. Oh je, was glaubst du wohl, wo ISRs angesiedelt sind...
Oktav Oschi schrieb: > Das war auf einem 32MHz 386 glaub ich mich zu erinnern. Der war mit > einem UART mit 19200baud schon zu 25% belastet. Dann steckten in Deinem System offenbar noch die alten 16450er ohne FIFO (statt 16550er mit FIFO). Ich habe damals auf 386ern (20 MHz) unter UNIX gearbeitet und konnte selbst bei kermit-Übertragungen mit 19200 Bd eine derartige CPU-Belastung nicht feststellen.
MCUA schrieb: > Einen (irgentwie gearteten) Scheduler hat man immer, und wenn es nur > eine MainLoop ist. Nicht notwendigerweise. Bei den meisten meiner Anwendungen sieht die Struktur so aus: rcall init_foo rcall init_bar ... sei main: rcall entersleep ;optional rjmp main Der einzige "Scheduler" ist das Auftreten von Interrupts, wobei man allenfalls die Timerinterrupts wirklich als eine Art Scheduler auffassen könnte, denn die sind immerhin vorhersagbar. Allerdings gibt es, wenn auch eher selten, Anwendungen, die nichtmal Timerinterrupts verwenden, da fällt dann auch noch dieses letzte Anzeichen eines Schedulers weg.
c-hater schrieb: > Bei den meisten meiner Anwendungen sieht die Struktur so aus: > > rcall init_foo > rcall init_bar > ... > > sei > > main: > rcall entersleep ;optional > rjmp main > > Der einzige "Scheduler" ist das Auftreten von Interrupts, Und deine Mainloop tut rein gar nichts außer schlafen? Wird dann die gesamte Arbeit in den ISRs verrichtet? > wobei man allenfalls die Timerinterrupts wirklich als eine Art Scheduler > auffassen könnte, denn die sind immerhin vorhersagbar. Allerdings gibt > es, wenn auch eher selten, Anwendungen, die nichtmal Timerinterrupts > verwenden, da fällt dann auch noch dieses letzte Anzeichen eines > Schedulers weg. Ein Scheduler hat erstmal nichts mit einem Timer-Interrupt zu tun. Seine Aufgabe ist es, die verfügbare Rechenzeit auf mehrere Aufgaben zu verteilen. Wenn dein Programm also mehrere Aufgaben zu erledigen hat, gibt es auch irgendeine Art von Scheduling. Btw: Du hast gemerkt, daß du auf ein zwei Jahre altes Posting antwortest?
Das kommt vor, wenn man keinen Scheduler hat. War halt der erste Interrupt seit zwei Jahren :-)
Rolf Magnus schrieb: > Und deine Mainloop tut rein gar nichts außer schlafen? Wird dann die > gesamte Arbeit in den ISRs verrichtet? Genau so ist das. Wobei die meisten dieser ISRs typischerweise geteilt sind, in eine kurze exklusiv laufende Sequenz und in den langen Rattenschwanz der eigentlichen Anwendung, bei dem Interrupts bereits wieder erlaubt sind. > Ein Scheduler hat erstmal nichts mit einem Timer-Interrupt zu tun. Richtig. Typischerweise wird allerdings ein Timerinterrupt verwendet, um die verfügbare Rechenzeit in Zeitscheiben für die Tasks zu zerlegen. Genau das mache ich allerdings nicht. Auch keine andere Art vorgeplanter Verteilung der Rechenzeit an die verschiedenen Tasks. Und das ist genau, was einen Scheduler ausmacht. Und das ist auch der springende Punkt: Es geht eben auch ganz gut ohne so einen Scheduler. Ein Scheduler ist eine Softwareinstanz, der nach vorgegebenen Parametern Rechenzeit zuteilt. Genau das habe ich eben nicht. Es gibt keine Softwareinstanz, die was zuteilt. Die Verteilung der Rechenzeit erfolgt rein hardwaregesteuert "on demand". > Wenn dein Programm also mehrere Aufgaben zu erledigen hat, > gibt es auch irgendeine Art von Scheduling. Das ist eben nicht notwendigerweise der Fall. Hast du das jetzt endlich begriffen?
c-hater schrieb: > Hast du das jetzt endlich begriffen? Sorry, ich hatte einfach nicht damit gerechnet, daß du tasächlich so einen Blödsinn machst: c-hater schrieb: >> Und deine Mainloop tut rein gar nichts außer schlafen? Wird dann die >> gesamte Arbeit in den ISRs verrichtet? > > Genau so ist das.
Rolf Magnus schrieb: > Sorry, ich hatte einfach nicht damit gerechnet, daß du tasächlich so > einen Blödsinn machst Das ist kein Blödsinn, sondern im Gegenteil nicht nur die effizienteste Methode zur Verteilung von Rechenzeit (nämlich ohne jeden Eigenbedarf), sondern auch die energieverbrauchsmäßig günstigste, weil keinerlei Rechenzeit für schwachsinniges Polling sinnlos verbraten wird. Aus beiden Gründen wird sie deshalb insbesondere im Bereich kleiner µC sehr häufig verwendet.
c-hater schrieb: > Aus beiden Gründen wird sie deshalb insbesondere im Bereich kleiner µC > sehr häufig verwendet. Für die weitere Diskussion über sinnvolle oder -lose Programmier- methoden öffne bitte einen eigenen, separaten Thread. Dieser hier war für AVR-Ada gedacht, und der einzige (und legitime) Zweck, warum er nach zwei Jahren wieder ausgebuddelt worden ist, ist ein neuer AVR-Ada-Release. Alles andere gehört nicht hierher.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.