mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik zeitgleicher Abarbeitung mehrerer Programme


Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: ERDI - Soft (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Man kann mit 8-Bittern sehr wohl sehr viele Prozesse parallel
abarbeiten."

"alle Prozesse schnell hintereinander ablaufen"

Du bestätigst mich :-)

Autor: Rahul (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rahul (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
jetzt weiß ich auch wieder, was da noch gefehlt hat.
Das mit den Prioritäten...

Autor: Peter Dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Daniel

" mehrere Kontrollfäden gleichzeitig ausführen"

Da wäre ich an einem konkreten Beispiel interessiert.

Autor: Rufus T. Firefly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hyperthreading emuliert ja nur einen zweiten Rechenkern, quasi als
Zwischenschritt zu Prozessoren mit mehreren Kernen.

Autor: Mike (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"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.

Autor: Andreas Siebel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas Siebel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"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?

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Um Programme deren Teile immer miteinander kooperieren können."

Sollte heissen: ... immer miteinander kooperieren müssen.

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"muß ich nen neuen thread anfangen"

Und gib ihm einen harmloseren und mehr dem Problem zugewandten Titel.

Autor: Andreas Siebel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"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.

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.