hallo
"und wieder ein neuer"
ich beschäftige mich seit kurzem mit der Programmierung von
Mikrokontrollern.
mein erstes Großprojekt soll eine Uhr mit dcf empfang werden
"schon wieder gibt es doch schon tausende"
Mit PHP konnte ich bereits einige Programmiererfahrungen sammeln, so
dass ich mich in die Programmierung mit Assembler gut reingefunden
habe.
Die Programmierung der Uhr möchte ich auch weitestgehend alleine
hinbekommen.
Jedoch könntet ihr mir bei einer Verständnisfrage weiterhelfen:
Meine Uhr soll möglichst aus dem Kontroller, Leeds, einem Widerstand
für den Reset und einem Kondensator um Stromschwankungen abzufangen
bestehen. Ich möchte möglichst wenig Peri-pheriegeräte verwenden. Also
auch keinen externen Quarz oder Oszillator.
Programmiert wird ein atmega16 in Assembler.
zum ersten wisst ihr, inwieweit ich die Ausgänge des Kontroller
belasten kann?
und zum zweiten und das ist wohl mein hauptsächliches Problem:
Können verschiedene Programme zeitgleich abgearbeitet werden?
Zur Verdeutlichung meiner Frage... bis jetzt nutze ich eine 3 bit
Countdown zur Erzeugung eines 1Hz Signals mit dem ich meine Uhr
vorwärts treibe. Wenn ich nun aber diese Schleife verlasse, um ein
Unterprogramm aufzurufen (Stundenton, Tastendruck, DCF Empfang usw.)
würde der Zähler meiner Uhr stehen bleiben und die Uhr genau um die
Zeit des ausgeführten Programms nachgehen. Kann ich also irgendwie
meinem 3 bit Countdown im Hintergrund laufen lassen, ohne das dieser
durch meine anderen Programme unterbrochen wird?
vielen Dank für eure Bemühungen
Gruß ich
Ausgangsbelastung: -> Datenblatt paralleles Arbeiten: -> nicht auf einem 8-Bit Controller Die Lösung für dein Problem könnten z.B. Interrupts sein. Nimm eines der diversen verfügbaren Codebeispiele und orientiere dich daran. Es gibt verschiedene Lösungsansätze.
Hallo, also für erstens gibt es im Datenblatt Hinweise, daher kann ich das aus dem Stehgreif auch nicht sagen. Bei zweitens gibt es wohl meherere Möglichkeiten : 1. Wenn die Bearbeitung eines Zeitgeberereignisses nur wenig Zeit in Anspruch nimmt und/oder die restlichen Aufgaben auch mal dmit klarkommen kurz zu warten, dann bietet sich die Bearbeitung eines Zeitgeberereignisses mit einem Interrupt an. Im Klartext : Zähler löst einen Interrupt aus - Programm bearbeitet das Ereignis (z.B. nächsten Sekundenwert auf dem Display anzeigen) und dann geht deer Rest weiter. 2. Ein Echtzeitbetriebssystem (klingt hart, ist aber bei AVR möglich). Als lohnender Hinguckpunkt kann man sich mal freeRTOS (www.freeRTOS.org) anschauen. Es ist nicht soo schwer dafür Appliaktionen zu entwickeln und gut als Einstieg in Betriebssysteme zu gebrauchen. Da es auch ganz gut skaliert, ist es auch für low-end Mikrocontroller (AVRs gehören da nun mal dazu) ganz gut zu gebrauchen. MfG, Daniel.
Nimm nen Timer für deine Uhr und nen externen 32,768kHz Quarz. So brauchst du nicht ständig auf DCF zu synchronisieren und hast trotz internem Haupttakt nen anständig genauen Sekundentakt. Guck im Datenblatt nach asynchronem Timer.
Man kann mit 8-Bittern sehr wohl sehr viele Prozesse parallel abarbeiten. Der Trick ist eine Main-Loop, in der alle Prozesse schnell hintereinander ablaufen. Dadurch entsteht der Eindruck, daß sie quasi gleichzeitig ausgeführt werden. Dabei sind die Prozesse so zu programmieren, daß sie nicht stopppen dürfen (Delay oder warten auf ein Signal) sondern dann für die ungenutzte Rechenzeit wieder zum Main zurück kehren. Hier mal ein Beispiel: http://www.mikrocontroller.net/forum/read-4-23408.html#new Peter
ok ich danke euch. ich werd mich mal in alle richtungen durchprobieren. und mal schauen ob ich eines davon verwenden kann. bei der belastung der ausgänge wollte ich es mir leicht machen (ich bin faul ich weiß) und schauen ob es jemand von euch sofort parat hat. nungut ich werde ins datenblatt schauen. vieln dank für eure hilfe gruß ich
"Man kann mit 8-Bittern sehr wohl sehr viele Prozesse parallel abarbeiten." "alle Prozesse schnell hintereinander ablaufen" Du bestätigst mich :-)
Wie soll es auch gehen, dass ein Prozessor sich gleichzeitig mit mehreren Sachen beschäftigen kann? Multitasking ist immer mit einem zeitlichen Versatz behaftet. Bei vernünftigen Systemen ist dieser zeitliche Versatz als konstant festgelegt (Zeitfenster für jede Aufgabe). Windows arbeitet nach einem anderen Prinzip...
Hallo schon wieder : "Multitasking ist immer mit einem zeitlichen Versatz behaftet." Stimmt nicht, wenn ein explizit multitaskingfähiger Prozessor verwendet wird, oder die Prozesse aufeinander synchronisiert sind. "Bei vernünftigen Systemen ist dieser zeitliche Versatz als konstant festgelegt (Zeitfenster für jede Aufgabe)." Stimmt leider überhaupt nicht, das Zeitscheibenverfahren wird nur in einer Unterklasse von Multitaskingsystemen verwendet. Zum Beispiel müssen Echtzeitbetriebssysteme nach einem anderen Prinzip arbeiten, bei dem höherpriorisierte Prozesse so lange areiten, wie sie wollen und dann erst wieder die niedriger priorisierten Prozesse drankommen, sonst kann das Zeitverhalten nur schwer kontrolliert werden (oder ist eben starr). "Windows arbeitet nach einem anderen Prinzip..." Da muss ich die vollkommen zustimmen :-) MfG, Daniel
jetzt weiß ich auch wieder, was da noch gefehlt hat. Das mit den Prioritäten...
Auch bei Multitasking läuft alles auf einer CPU nacheinander ab. Nur ein Multiprozessorsystem kann echt parallel arbeiten. Multitaskingsysteme können Prozesse an beliebiger Stelle unterbrechen, d.h. auch, wenn sie auf etwas warten. Der große Nachteil ist dabei, sie können die Programme im ungünstigsten Zeitpunkt unterbrechen, d.h. wenn sie gerade die größte Menge an Reccourcen (SRAM) belegt haben. Es muß also für jeden Prozess das Maximum an SRAM freigehalten werden. Der 2. Große Nachteil ist, daß auch die Aktualisierung von Parametern unterbrochen werden kann, d.h. ungültige Daten an einen anderen Prozeß übergeben werden. Daher ist es auf µCs deutlich einfacher und sicherer die Prozesse nacheinander in der Main-Loop auszuführen. Peter
Hallo Peter, ich muss Dir im Bezug auf die Aussage : "Parallelität ist nur auf Multiprozessorsystemen möglich" wirdersprechen. Es exsitieren definitiv Mikroprozessoren und auch Controller, welche explizit mehrere Kontrollfäden gleichzeitig ausführen. Keine Unterbrechungen der Einzelprozesse findet dabei statt. Man kann des Weiteren auch die anderen Probleme, welche Du angesprochen hast lösen. Dafür existieren in Betriebssystemen schließlich Synchronisationsobjekte. Sogar das kooperative, geschützte und exhtzeitfähige Zugreifen auf Peripherie, welche man mal nicht so eben umschalten kann, ist definitiv möglich und wird auch eingesetzt. Ich stimme Dir aber sofort zu, wenn Du sagst, dass dies natürlich zu einem gewissen Eigenresourcenverbrauch führt. Es gibt selbstverständlich keinen Grund in einer Wetterstation für den Wohnzimmerschrank Echtzeitbetriebssysteme einzusetzen, bei der zunehmenden Komplexität von Autromatisierungsgeräten ist dies ein Trend der nicht wegzuleugnen ist. Man kann selbstverständlich beide Wege beschreiten (also einerseits alles durch Überlegung im Vorfeld und eine geschickte zeitliche Steuerung erledigen oder andererseits ein Betribessystem und Tasksysnchronisierung verwenden), die Abwägung , was zu Einsatzt kommt, wird wahrscheinlich in jedem Einzelfall nötig sein. MfG, Daniel
@Daniel " mehrere Kontrollfäden gleichzeitig ausführen" Da wäre ich an einem konkreten Beispiel interessiert.
Könnte hier von Intels "Hyperthreading" die Rede sein? Ein P4 ist weit entfernt von einem µC, aber ein Prozessor soll das Teil ja angeblich sein. Ich hielte es eher für eine Art datenverarbeitende Kochplatte, aber das tut hier nichts zur Sache.
Hyperthreading emuliert ja nur einen zweiten Rechenkern, quasi als Zwischenschritt zu Prozessoren mit mehreren Kernen.
Meiner Meinung nach können DSPs zumindestens in gewissem Umfang Beehle parallel abarbeiten. Wobei das natürlich nciht bei allen Befehlen klappt, also keine echte Parallelität.
Die DSPs können nur mehrere Befehle einer Befehlssequenz einlesen und dann parallel ausführen, d.h. die Befehle gehören alle zu einem einzigen Prozeß. Für echte Parallelität zweier Prozesse ohne Taskumschaltung müßte die CPU ja 2 Programmcounter haben. Peter
"Echtzeitbetriebssysteme" klingt riesig. Kann sein es ist nicht anderes als ein Satz von Routinen zur Verwaltung von Prozessen, Timern, Semaphoren und Messages. Beispiel AvrX: unter 1,5KB. Unterscheiden muss man zwei Varianten: (1) preemtives Multitasking und (2) kooperatives Multitasking. AvrX kann nur (1), FreeRTOS beides. Bei (1) können Prozesse an beliebiger Stelle unterbrochen werden. Was einserseits schnelle Reaktionen ermöglicht, andererseits die von Peter erwähnten Probleme im Umgang mit gemeinsam benutzten Daten zur Folge hat. Freilich: Das sind exakt die gleichen Probleme die man auch mit von Interrupts benutzten Daten und Ports hat. Nichts neues also, nur mehr davon. In (2) findet die Umschaltung zwischen Prozessen ausschliesslich an dafür vorgesehenen Stellen statt. Probleme mit gemeinsamen Variablen entstehen also nicht. Zum Ausgleich muss der Programmierer dafür sorgen, dass die häufig genug auftreten, sonst leidet die Reaktionsfähigkeit. Die Programmierung ist durchaus etwas komplexer - schon weil man das erst einmal lernen muss. Andererseits können die entstehenden Programme übersichtlicher und insbesondere lesbarer sein. Denn in der klassischen µC-Programmierung verteilt sich der Code einer Teilaufgabe auf diverse zunächst zusammenhanglose Häppchen, in Hauptprogramm und Interrupts. In welcher Reihenfolge das abgearbeitet wird, erschliesst sich dem Leser (oder Programmierer der sich den eigenen Mist nach Jahren wieder ansehen muss) dabei allenfalls durch die i.d.R. nicht vorhandenen Doku. In RTOS bleibt der Programmablauf geschlossen am Stück im jeweiligen Hauptprogramm. In Interrupts passiert wenig, idealerweise wird dort nur der betroffene Prozess wieder aufgeweckt. Ein weiterer Vorteil: Man ist schon grundstzlich vorbereitet auf die PC-Programmiertechnik der kommenden Jahre und Jahrzehnte. Denn was heute mit P4-Hyperthreading schon akut ist - mit den neuen Multicores wird es mehr und mehr selbstverständlich: in einem einzigen Progeamm mehreren Prozessoren auslasten zu können.
Echte Parallelität gibt es nur mit mehreren unabhängigen Rechenwerken und eigentlich auch Speichern. Denn was macht der eine wenn der andere auf den SPeicher zugreift?!?! WARTEN... und das spricht eindeutig gegen Parallelität. Zu Echtzeitbetriebsystemen: Ein Merkmal ist die definierte Zeit, die jedem Proßess eingeräumt wird und eine definierte Zeit wann er abgearbeitet wird. Nimmt man jetzt Priorisierung, dann ist ein System nicht mehr Echtzeitfähig, weil Prozesse höherer Priorität die niedrigerer Priorität verdrängen können.
Ich nehme an, Du gibst wichtigen Prozessen immer die niedrigste Priorität, damit sie möglichst leicht von unwichtigen Prozessen mit hoher Priorität verdrängt werden können? Im Ernst: Du kannst in jeden noch so echtzeitfähigen System Programme schreiben, die kein bischen echtzeitfähig sind. Priortäten dienen natürlich umgekehrt dazu, echtzeitrelevante Programmteile (hohe Prio) von den anderen (niedrige Prio) unterschieden zu können. Meist gibt's nämlich beide.
@A.K. EIn echtes Echtzeitbetriebsystem garantiert den Proßessen zu einer bestimmten Zeit eine bestimmte Mindestrechenzeit zu bekommen. Was der Benutzer dann mit den Einzelnen Proßessen anfängt ist seine Sachen. Gibt es aber eine Priorisierung kann ich "mir" als Prozess nicht mehr sicher sein und bin vom gut dünken der "anderen" abhängig. Denn die können sich ja selber als "total wichtig" bezeichnen.
"Was der Benutzer dann mit den Einzelnen Proßessen anfängt ist seine Sachen." "Denn die können sich ja selber als "total wichtig" bezeichnen." Wovon bitte reden wir hier? Echtzeitsysteme sind doch keine Timesharing-Systeme wie in den 70ern. Da war es essentiell, dass nicht ein Anwender alle anderen Anwender rauswerfen konnte. Aber hier geht es um Microcontroller. Um Programme deren Teile immer miteinander kooperieren können. Oder benutzt man bei dir die Heizungssteuerung nebenbei auch fürs Homebanking? Natürlich kann der Prozess sich als wichtig deklarieren und damit elle lahmlegen. Der Prozess, beispielsweise eine Analogdatenerfassung, kann auch nur so zum Spass auch mal ganz was anderes machen. Er kann wenn er will auch mal so eben im Flash rumlöschen. Macht diese Möglichkeit jeden AVR,MSP430,ARM7 prinziell nicht echtzeitfähig?
"Um Programme deren Teile immer miteinander kooperieren können." Sollte heissen: ... immer miteinander kooperieren müssen.
ich weiß: ich habe gefragt... aber ich bin maßlos überfordert muß ich nen neuen thread anfangen oder kann mir einer von euch noch sagen wie dieses problem sonst üblicherweise gelöst wird. ich könnte mir noch vorstelle, am ende jeden unterprogrammes den zähler meines contdown genau um die takte zu verkürzen die mein unterprogramm braucht. aber wie mache ich das bei programmen, die länger als eine sekunde sind bzw die genau die schaltzeit einer sekunde erwischen. dann steht meine uhr wieder. viele grüße ich
"muß ich nen neuen thread anfangen" Und gib ihm einen harmloseren und mehr dem Problem zugewandten Titel.
@A.K. Ich wollte zur Begriffsbestimmung beitragen. Mit Begriffen wie "RTOS" wird immer leicht durch die Gegend geworfen. Multiproßessfähigkeit ist ja was anderes. Die Echtzeitfähigkeit eines Betriebssystemes hat mit dem Prozessor nix zu tun. Hab ich auch nicht behauptet. Es ist eine Eigenschaft des Betriebssystems. Echtzeit heisst auch nicht schnell. Kannst ja dein Echtzeitbetriebssystem auch spezifizieren mit "Jeder Proßess bekommt in der jeder Minute mindestens 10 ms. Es muss nur garantieren, dass dieses passiert.
"Die Echtzeitfähigkeit eines Betriebssystemes hat mit dem Prozessor nix zu tun. Hab ich auch nicht behauptet." Indirekt schon. Wenn bei dir ein Prozess nicht das Recht haben darf, sich die höchste Priorität zu geben, dann darf er analog auch nicht das Recht haben, den Controller umzuprogrammieren. Und der Prozessor brauch dann eine Rechteverwaltung (MMU, User/Supervisor-Mode). Denn kein Programm/Prozess, keine Funktion in einem Microcontroller darf sich daneben benehmen. Darf nicht, auch wenn's technisch ginge. Also darf er auch die Prio nur ändern, wenn es der Anforderung entspricht. Und dann ist es ok. Aber Du verwechselst ohnehin Echtzeit- mit Mehrbenutzersystemen. Zumindest im hier üblichen Kontext. Die Echtzeitsysteme, von denen hier die Rede ist, sind prinzipiell keine Mehrbenutzersysteme, sondern für solche Microcontroller. Hier ist auch nicht die Rede von der berüchtigten Frage, inwieweit Windows oder Linux echtzeitfähig sind. Das ist eine gänzlich andere Grössenordnung.
@all "muß ich nen neuen thread anfangen" "Und gib ihm einen harmloseren und mehr dem Problem zugewandten Titel." ich hoffe das ist nur die meinung eines einzelne. wer nicht zur lösung eines problemes beitragen kann, ist teil von diesem.
@Michael, vergiß alles außer die ersten 6 Postings und mach für weitere Fragen nen neuen Thread auf. Das passiert manchmal, daß ein Thread gehijackt wird, mach Dir nichts draus. Peter
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.