-
Thread
mehrere Interrupts beim ATMEGA32
Aufgaben zu erledigen, sichert man nur die zeitkritischen (also die flüchtigen) Werte, setzt ein Jobflag für die Mainloop und kehrt zur Tagesordnung zurück. In der Mainloop werden dann die Jobflags geprüft und die zugehörigen Jobs ausgeführt, wobei der Job sein Jobflag wieder löscht. Einen ADC-Complete-Interrupt
zehnte mal die Uhr hochzählen und die Tasten entprellen, wenn erforderlich, dann ein Jobflag für Hundertstelsekunde setzen. Braucht man eine Wartezeit, so nimmt man statt eines Jobflags eine Variable, die in der Mainloop alle Hundertstelsekunde (oder bei Bedarf auch alle Sekunde) heruntergezählt
-
Thread
Interrupts vs. Endlosschleife
- Weitere Timer-Interrupts (OC, ICP, OVF...) diverse zeitabhängige Jobs durch setzen der Jobflags "anmelden" (erledigt Mainloop) (wird von Timern ausgelöst) - ADC-Interrupt: Messwerte einlesen und sichern, nächste Messquelle einschalten, evtl. Jobflag setzen (wird vom ADC ausgelöst
das LCD ausgeben - eine Berechnung ausführen - ... (wird von Mainloop aufgerufen, falls Jobflag gesetzt war, löscht Jobflag und erledigt Job) Man richtet sich ein (oder mehrere) Register ein, in denen jedes Bit für einen Job steht (Jobflags). Erkennt irgendein Programmteil (meist ein
-
Thread
AVR - Erkennen ob Interrupts verloren gehen
Im schlimmsten Fall brauchst du dazu Hardware-Unterstützung. Im einfachsten Fall kommt das ISR-Jobflag System zum Zug, bei dem du in der ISR vereinbaren kannst: Tritt der Interrupt auf, und ist das Jobflag schon (noch immer) gesetzt, dann wird es kritisch.
wenn das so ginge. Meinst du mit Jobflag das > Interrupt Flag? Nein. Ich meine die Technik des Jobflags [C] uint8_t Job; ISR( ... ) { Job = 1; } int main { .... while( 1 ) { if( Job ) ..
-
Thread
Atmega128 Prioritaeten
mir meist ein Register mit Boolschen Variablen (Flags) ein, setze in der ISR das entsprechende "Jobflag" und frage in der Mainloop die Jobflags der Reihe nach ab. Ist eins gesetzt, wird die entsprechende Routine ausgeführt und das Jobflag gelöscht. Die Timer-ISR mit der schnellsten Aufrufzeit kann
mir meist ein Register mit Boolschen Variablen (Flags) > ein,setze in der ISR das entsprechende "Jobflag" und frage in der > Mainloop die Jobflags der Reihe nach ab. Ist eins gesetzt, wird die > entsprechende Routine ausgeführt und das Jobflag gelöscht. > Die Timer-ISR mit der schnellsten Aufrufzeit
-
Thread
ICP Atmega 8
Aufgaben. Irgendein Programmteil (meist ein Interrupt) vergibt einen Auftrag, indem das zugehörige Jobflag gesetzt wird. In der Mainloop werden dann alle Jobflags der Reihe nach abgefragt und wenn eines gesetzt ist, wird die zugehörige Rüutine aufgerufen. Diese Routine löscht dann das Jobflag und erledigt
springt danach über den nach sleep stehenden Befehl "rjmp mainloop" die Hauptschleife aus, bis alle Jobflags gelöscht sind, dann wird wieder geschlafen, bis der nächste Interrupt "klingelt". ...
-
Thread
Effizientes Programmieren mit Mikrocontroller
Jobn_Needs_to_be_done = FALSE; } } } [/C] Um einen Job zur Auführung zu bringen, wird sein Jobflag auf TRUE gesetzt. Meistens passiert das in einer Interrupt Routine, die zb von einem Timer angestossen wird. Das muss aber nicht so sein. Im Grunde kann jeder Code so ein Jobflag auf TRUE setzen.
Statemachines hinein und oft hat nman eine Mischung aus beidem: einer Statemachine (Zustandsmaschine) und Jobflags.
-
Thread
Dritte Hierarchiestufe?
while( 1 ) { isIdle = true; // Annahme: es gibt nichts wichtiges zu tun if (Jobflag) { mach irgendetwas ganz wichtiges isIdle = false; // die Annahme war falsch } if (UpdateLCD) // noch ein Jobflag { update das LCD isIdle
Jobflags die Abarbeitung eines anderen Jobflags ein wenig verzögert.
-
Thread
Funktion innerhalb von ISR aufrufen
ausarten. > Oder geht man mit Interrupts etc. anders um? Ja. Eine übliche Vorgehensweise sind Jobflags. In main() gibt es die Hauptendlosschleife. Die überprüft ständig, ob ein Jobflag gesetzt ist und bearbeitet einen Job, wenn dem so ist. Die ISR sichert einfach nur die dazu notwendigen Daten in globalen Variablen und setzt das entsprechende Jobflag. Bsp. Du hast einen ADC im System. Der ADC ist so eingestellt, dass er bei fertigem Wandlerergebnis einen Interrupt auslöst. Das Wandlerergebnis muss jetzt beispielseweise noch umgerechnet werden
-
Thread
Attiny10 Problem AVR Studio 6
|= (1<<PORTB0); } // die naechste Messung kann starten // JobFlag = FALSE; } } } [/c]
volatile unsigned int EndTime = 0; // ICR-Wert bei 2.High-Flanke speichern volatile unsigned char JobFlag = FALSE; // Job Flag volatile signed long int Erg = 0; volatile signed long int Mittelwert = 0; ISR( TIM0_CAPT_vect ) { static unsigned char ErsteFlanke = TRUE; if( JobFlag )
-
Thread
Frequenz eines Rechtecksignal manipulieren
|= (1<<PORTB0); } // die naechste Messung kann starten // JobFlag = FALSE; } } }[/code]
volatile unsigned int EndTime = 0; // ICR-Wert bei 2.High-Flanke speichern volatile unsigned char JobFlag = FALSE; // Job Flag volatile signed long int Erg = 0; volatile signed long int Mittelwert = 0; ISR( TIM0_CAPT_vect ) { static unsigned char ErsteFlanke = TRUE; if( JobFlag )
-
Thread
Multitasking mit Assembler
ist, das schwarze Brett bzw. die Zetteln da drauf sind nichts anderes, als das, was andere die 'Jobflags' nennen.
soll. Läuft der Blinkdauerzähler nicht ab, dann wird nix weiter gemacht, also sofort alle anderen Jobflags (am schwarzen Brett) prüfen und ggf. (einen kleinen Schritt) einer andere Aufgabe erledigen. ...
-
Thread
PIC USART Interrupt - suche elegante Lösung
geschreieben und aus dem TX-Buffer in die UART geschrieben. Ist ein Paket vollständig, wird ein Jobflag gesetzt. Auswerten / Antworten - Applikation: Irgendwo in deiner Applikation prüfst du das Jobflag, wenn es gesetzt wird, wertest du den RX-Buffer aus, stopfst die Antwort in den TX-Buffer und
/ Empfangen rattert automatisch durch. Auf die Art macht die ISR nur wenig - Buffer stopfen, Jobflag setzen - und blockiert dir nicht andere Sachen, die Applikaion muss sich nicht um den Low-Level-Mist kümmern. Du wirst auch nie Bytes vermissen, weil alles zeitkritische in der ISR passiert.
-
Thread
Universelle Tastenabfrage nach PeDa in AVR Assembler
Fall läuft die Routine auch nicht im Interrupt, sondern > als Job der Mainloop, durch Timer und Jobflag synchronisiert. > ... > wobei ich nicht verstehe, wie die Synchronisation durch Timer und Jobflag funktioniert. Leider kann der olle Brummbär dies auch nicht mehr erklären, aber vieleicht hier
Fall läuft die Routine auch nicht im Interrupt, sondern >> als Job der Mainloop, durch Timer und Jobflag synchronisiert. >> ... >> > > wobei ich nicht verstehe, wie die Synchronisation durch Timer und > Jobflag funktioniert. Leider kann der olle Brummbär dies auch nicht mehr > erklären, aber vieleicht
-
Thread
Interrupt programmierung
bzw. man nicht sicherstellen muss, dass es in einem Aufwasch abgearbeitet werden muss, wird über Jobflags erledigt. Jobflags bedeutet: in der main werden in der Hauptschleife alle vorhandenen Jobflags ständig durchgesehen und wenn signalisiert wird (zb von einer ISR) das etwas zu machen ist, dann wird
-
Thread
Led Cluster ansteuern
aufgerufen (dauert viel zu lange, ISRs müssen extrem kurz bleiben), sondern nur das zugehörige "Jobflag" gesetzt. In der Mainloop werden dann nacheinander alle Jobflags geprüft und bei gesetztem Flag wird das zugehörige Unterprogramm aufgerufen, was den Job erledigt und das Jobflag wieder löscht. Sind
-
Thread
Sinvoller Codeaufbau?
durchläuft einfach die Endlosschleife ohne irgendwelche Warteschleifen. Dabei kontrolliert sie Jobflags, die aus Interrupts oder einfach nur Eingangssignalen gebildet werden. Die SChleife arbeitet nach den´m EVA-Prinzip: Einlesen, Verarbeiten und Ausgeben. Bei Eingängen werden Flankenbits gebildet.
Vielen Dank an Alle! Ich habe mich jetzt den halben Tag durch das Thema JobFlags gegraben und angefangen den Code dahingehend umzustrukturieren. Es ist sehr interessant und wird sicherlich mein zukünftiges Programmieren beeinflussen. Ungewohn ist zwar noch das viele Benützen
-
Thread
MSP430 ADC12 Problem
in einer globalen Variablen bereitgestellt zusätzliche globale Variable auf 1 setzen (das sog. Jobflag) um der ganzen Welt anzuzeigen, dass ein ADC Wert verfügbar ist und etwas damit gemacht werden müsste. Interrupt fertig In der Hauptschleife in main() while( 1 ) { das Jobflag
ist es 1 -> Interrupt sperren Wert von der globalen Variablen wegholen Jobflag wieder auf 0 setzen. Interrupt freigeben Wert formatieren und über UART ausgeben } Auf die Art ist die Interrupt Routine so kurz wie es nur irgendwie geht und lässt noch
-
Thread
effiziente programmstruktur
Komponenten initialisiert, auch die entsprechenden Interrupts. Dann kommt meist die Mainloop, in der Jobflags (auch Tastenflags der entprellten Tasten) überprüft werden und darauf reagiert wird (in Routine verzweigen, die das Jobflag löscht und den Job ausführt). Sind alle Jobs erledigt, dann wird gepennt
und die entsprechenden ISRs aufrufen. Hier kommt es auf die Situation an, ob in der ISR nur ein Jobflag für die Mainloop gesetzt wird oder ob der Job gleich in der ISR erledigt wird. Auch die Frage der Redundanz kann von Fall zu Fall unterschiedlich ausfallen. Manchmal ist es eben schneller, einen
-
Thread
ATtiny13 klein programm
als Endlosschleife organisiert und ruft reiherum alle zu erledigenden Jobs auf (Auswertung der Jobflags und bedingte Sprünge) - Jobs der Mainloop setzen ihr Jobflag zurück und erledigen die entsprechende Arbeit - Interrupt-Service-Routinen werden von Ereignissen (z.B. Timer-Überlauf) ausgelöst und aufgerufen können über eigene Boolsche Variablen (Jobflags, Semaphores) Jobs bei der Mainloop anmelden ...
-
Thread
Was anderes als "delay_ms" ?
Stelle (A) vorbei und kann dort Arbeit erledigen. Dieser timeCount ist eine spezielle Form eines Jobflags, in der eine ISR der Hauptschleife mitteilt, dass es Arbeit zu tun gibt. In diesem Fall zählt die ISR im Prinzip im Jobflag mit, wie oft sie schon aufgerufen wurde und die Hauptschleife weiß, dass
komplett in der ISR abhandeln (siehe den Wiki Artikel "Entprellung") und der Tastendruck selber ist das Jobflag, das in der Hauptschleife abgefragt wird. Das andere Konzept, das man an dieser Stelle oft sinnvoll einsetzen kann, ist das Konzept einer Statemachine (oder Zustandsautomat). Dein Programm oder
-
Thread
LED seltener umschalten
ja auch Zeit. Blöd nur, dass dieser Zeitversatz davon abhängt, wo dir Mainloop genau war, als das Jobflag gesetzt wurde.
der Aufwand nicht höher als der Nutzen ist. Eine LED umschalten dauert ein paar Taktzyklen. Ein Jobflag setzen dauert auch ein paar Taktzyklen. Kommt sich also im Endeffekt mehr oder weniger aufs gleiche raus. Und dann gewinnt die einfachere Lösung.
-
Thread
Ist die obligatorische Endlosschleife am Ende der main Funktion nur Aberglaube?
Bearbeitung eines Sachverhaltes in die ISR zu setzen. > > Wenn es länger dauert, dann wird ein Jobflag bemüht. > Die Aussage "alles wird immer und unbedingt immer in einer ISR gemacht" > ist genauso falsch wie "man darf gar nichts in einer ISR machen ausser > ein Flag zu setzen". Man entscheidet
weil die Main-Loop damit beschäftigt ist und erst eine halbe Sekunde später wieder zur Abfrage des Jobflags kommt.
-
Thread
Blinkende LEDs als paralleles Programm
Warteschleifen in irgend einer Form benutzt, sondern einen Standard-Aufbau mit Hauptschleife und Jobflags macht. Ereignisse werden in Interrupts verfrachtet und setzen bei Bedarf die Jobflags, so dass die Hauptschleife bei Bedarf die entsprechende (kurze) Aktion durchführt. Vielleicht erst mal mit
-
Thread
interrupt ohne rücksprung
dazu lautet: Job-Flags. Ein Interrupt macht so gut wie keine Arbeit selber, sondern er setzt ein Jobflag, welches der Hauptschleife mitteilt, dass es wieder mal Zeit wäre die Signalqualität zu überprüfen. Die Hauptschleife registriert dieses Ansinnen anhand des Jobflags und entscheidet, dass genau das
-
Thread
Timer Interrupt - Speicher voll?
mehr rauskommt, weil er nur noch Interrupts abarbeitet? > Weis jemand Rat? Interrupt setzt Jobflag. Jobflag sorgt in der Hauptschleife für den Schreibvorgang. Das ist die übliche Methode wie man regelmässige Aktionen organisiert, die länger andauern. Und schreiben auf eine SD-Karte qualifiziert
-
Thread
Tiny26 wacht aus ADC noise reduction nicht mehr auf :-(
der Mainloop ein. Das sichert ab, das alle ISRs ordentlich verlassen wurden und alle Jobs (per Jobflags) erledigt sind. Ich nutze SLEEP im Idle-Mode (meist) bereits für ganz einfache Programme, wenn alle Jobs der Mainloop erledigt sind, schicke ich den AVR schlafen. Der nächste Interrupt weckt ihn dann wieder und vor dem nächsten Interrupt kann sowiso kein neuer Job (über Jobflags) in Auftrag gegeben werden. In Deinem Fall müsste beim Start des ADC der Sleep-Mode von Idle auf ADC-Noise-red. umgeschaltet werden. Laut Datenblatt (Seite 41) sollte der ADC bereits eingeschaltet
-
Thread
Wie viele Cycles darf die Interrupt-Routine haben?
Wenn doch, dann kann man natürlich den kompletten Datums-Teil rausziehen und nur diesen über ein JobFlag in der Hauptschleife anstossen. In 24 Stunden wird der kleine Racker dann ja doch irgendwann Zeit haben, das Datum nachzuziehen.
tatsächlich ein Problem ist, kann man das ganze Datumshochzählen auch in die Hauptschleife (mit Jobflag) auslagern. > Noch ne Frage meinerseits die nicht ganz in diesen Thread passt: > Ich nutze jetzt nen Timer2 als RTC (OVERFLOW_INTERRUPT). Nun möchte ich > mit diesem TIMER auch noch einen Taster
-
Thread
Probleme mit UART Mega8
LCD-Ausgaben über Ringbuffer laufen lasse und die Zeichenausgabe vom Ringbuffer zum LCD über Timer (und Jobflag) synchronisiere. Somit wird das nächste Zeichen immer erst ausgegeben, wenn der nächste "Termin" ran ist. Dazwischen wird nicht gewartet, sondern die Mainloop durchlaufen und "geschaut, was es sonst noch so zu tun gibt", also alle Jobflags und ggf. Tastenflags der Entprellung abgefragt. ...
-
Thread
LCD - Ausgabefehler
Lösung für LCD-Befehle, die in der ISR gebraucht werden? Im Grunde ja. Man nennt die Dinger 'Jobflags'. Sie zeigen der Hauptschleife an, dass ein Job zu erledigen ist, bei dir das löschen eines LCD. Aber im Grunde hast du trotzdem immer noch einen falschen Ansatz. Die ISR soll sich nämlich im
verstanden, dass sich die ISR nicht um das LCD kümmern soll. Trotzdem entscheidet die ISR durch diese Jobflags was zu tun ist. In meinem Programm kümmert sie sich um das LCD. Wo ist der falsche Ansatz, wenn meine ISR durch setzen von Variablen dem main mitteilt, dass es im darauffolgenden Durchlauf das LCD
-
Thread
Digitaler Datenbus + Ein & Ausgänge + Timer
züglich zur Mainloop zurück gesprungen und ein anderer Job erledigt. - In der Mainloop werden die Jobflags geprüft und ggf zum erforder- lichen Unterprogramm verzweigt. Kann dieses den Job erledigen, dann löscht es das Jobflag und tut seine Arbeit. Sind alle Jobs abgear- beitet, dann wird in
-
Thread
gemessene Frequenz mit UART verschicken
UpadateUart Job Flag gemacht hast einfach nochmal: In der ISR wird eine globale Variable (das Jobflag) auf 1 gesetzt. in der main() wird neben all den anderen Dingen auch dieses Jobflag noch überprüft und wenn es 1 ist, dann wird über die UART verschickt. int main(void) { ... for
-
Thread
AVR Timer1Overflow problem!
Jobauftrag) mitgeteilt, dass ein neues Ergebnis vorliegt. Die Mainloop fragt zyklisch alle Jobflags ab und verzweigt zu einem Job, wenn ein Auftrag vorliegt. Hier ist es das Jobflag für die neue Sekunde, das zum Aufruf der Handler-Routine führt. Diese macht nun Folgendes: - Jobauftrag (Merker)
-
Thread
UART - Heizungssteurung
:p ... Nun, muss ich also bei > Tastendruck da raus :) Auch deshalb ist die Lösung mit den Jobflags (zb updateTime) die bessere Lösung. Dann verteilt sich die Logik des Programms nicht über so viele Codestellen, sondern bleibt mehr beisammen und bleibt besser überschaubar. Das Jobflag updateTime
-
Thread
Spannungsmessung mit PIC16F877A -->LCD-Anzeige
scheinbar mehrere Dinge gleichzeitig machen oft genau so: IN der Hauptschleife werden nacheinander die Jobflags abgeklappert und nachgesehen ob es in einem Teilbereich etwas zu tun gibt. Wenn ja (wenn also das Flag gesetzt ist), dann wird die Arbeit ausgeführt und das Flag auf 0 zurück gesetzt. Wenn irgendein anderes Teilsystem eine Arbeit erledigt haben will, dann setzt es das entsrpechende Jobflag auf 1. Und delays - die sind, bis auf ganz kurze Delays, schlicht und ergreifend verboten. Denn sie sind der Tod jeden Programmes, das sich um mehrere Dinge 'gleichzeitig' kümmern muss.
-
Thread
UART + Taschenrechner Teil2
gesetzt, weil 0x15 empfangen wurde, machst Du den Job in der Hauptschleife. Siehe ...HanneS... "Jobflag http://www.mikrocontroller.net/search?query=jobflag&forums%5B%5D=1&forums%5B%5D=9&forums%5B%5D=10&forums%5B%5D=2&forums%5B%5D=4&forums%5B%5D=3&forums%5B%5D=6&forums%5B%5D=17&forums%5B%5D=11&forums
-
Thread
Stoppuhr mit Bascom AVR
LCD-Ausgabe. Die macht man am besten in die Mainroutine rein. Und die wird eben durch das (die) Jobflag(s) getriggert. So kann man nur einmal in der Sekunde eine Ausgabe steuern, oder bei Stop. ciao gustav
#5402163: > Die macht man am besten in die Mainroutine rein. Und die wird eben durch > das (die) Jobflag(s) getriggert. Ja, das funktioniert gut, so mache ich das auch. Gruß Alex Für den CTC-Timer verwende ich folgendes: Diese CTC-Timereinstellung habe ich mir vor ein paar Jahren gebastelt.
-
Thread
Frage zum Fading von LED's
bin eigentlich zum Schluss gekommen, dass ich das nicht tun würde. Ich würde mir in der ISR ein Jobflag setzen und dass dann in der Hauptschleife auswerten. Der Grund: Spätestens beim übergang von einer Fading Fahrt zur nächsten sind ein paar Berechnungen notwendig. Ist nicht so wild, aber doch.
eigentlich zum Schluss > gekommen, dass ich das nicht tun würde. Ich würde mir in der ISR ein > Jobflag setzen und dass dann in der Hauptschleife auswerten. Das kann ich von der Praxis her absolut bestätigen. Ich hatte bei einer ähnlichen Entwicklung http://www.mikrocontroller.net/topic/261922
-
Thread
Befehlsinterpreter auf MC und diverser anderer Kram
einer globalen String Variablen gesammelt, bis die ISR zb. den Return erkennt. Danach setzt sie ein Jobflag, der aussagt, dass eine komplette Eingabezeile fertig vorliegt und beim nächsten Durchlauf der mainloop wird dieses Jobflag ausgwertet und die Eingabezeile der Verarbeitung zugeführt.
-
Thread
C 'Zeitsteuerung', µS - 24h. Bitte mal ansehen
kann nach meinem Konzept (extrem kurze ISRs, Synchronisierung der Jobs in der Mainloop mittels Jobflags, Sleep-Mode Idle, wenn alle Jobs der Mainloop fertig sind) eigentlich nicht passieren. Denn der Zeitzählung ist es egal, ob ein Impuls abgesetzt wurde oder nicht. Und da ein Impuls immer kürzer ist
Klingt gut! Klingt nicht nur gut, ist auch gut. Der Überlauf-Int "taktet" die Mainloop über ein Jobflag, der Compare-Int schaltet nur den Impuls aus (egal ob er diesmal an war), den Rest erledigt die Mainloop: - Zeit hochzählen und Schaltuhrfunktion ausüben - Servostrom einschalten, wenn Schaltzeit
-
Thread
Atmega 8 stürzt unregelmäßig ab
zaehler' im ANA_COMP interrupt in die Quere(atomarer Zugriff), oder? Ich würde wie ..HanneS.. Jobflags in den Interruptroutinen setzen und in der Main abarbeiten.
-
Thread
Frage zu ISR
in g). Machs so, wie man das gemeinhin macht: Setz dir eine globale Variable auf 1 (ein sog. Jobflag) und mach die Berechnung in der Hauptschleife. > Aber bevor das Risiko besteht, dass der Timer-ISR einmal nicht > aufgerufen wird, mach ichs ohne ADC-ISR. Wenn du dir das sowieso leisten kannst
-
Thread
Schieberegistersachen
Controller Zeit dazu findet, bis der Lesepointer den Schreibpointer erreicht hat. Dann wird ein "Jobflag" gelöscht, welches in der LCD_DATA-Routine gesetzt wurde, worauf die Zeichenausgabe eingestellt wird. Auch die Cursor-Positionierung erfolgt über den Ringbuffer. Dazu wurden Steuerzeichen im unteren
-
Thread
LCD + SD-Karte an SPI- Pins ?
Bildschirmspeicher übrig, dann prüfe ich im LCD-Wait (Warten auf ein vom Timer gesetztes Flag) die Jobflags und arbeite darin die Jobs der Mainloop ab. Das ist effizienter als Warteschleifen. ...