-
Thread
Seltsames Verhalten bei verschiedenen Timer Prescalern-Atmega 328P
PORTB ^= (1<<PB1); sei(); } void _taster_einlesen() { jflags &= ~(1<<taster_einlesen); //Jobflag löschen uint8_t taster_new; //Hilfsvariable1 uint8_t taster_temp; //Hilfsvariable2 taster_new = (PIND & (1<<pwm_start)); taster_temp = taster_new; taster_new &= ~(taster_old);
-
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
Softwareentprellung Routine von Peter Danneger
] Tastenabfrage: ;Entprell-Algorithmus geklaut bei Peter Dannegger... cbr flags,1<<entprell ;Jobflag löschen in tmp,tap ;Tastenport einlesen (gedrückt=L) com tmp ;invertieren (gedrückt=H) andi tmp,alltast ;ungenutzte Bits ausblenden eor tmp,tas ;nur Änderungen
-
Thread
Servomotor steuern - C Routine von dieser Seite
einen Buffer geschrieben, sofern es kein '\n' ist. Erkennt die ISR einen '\n' dann setzt sie ein Jobflag und ein Teilzweig in der Hauptschleife aktiviert sich und sieht sich den Buffer an.
-
Thread
Assembler wieder auf dem Weg nach vorn Gesperrt
F_CPU not defined. #endif #include <avr/io.h> #include <avr/interrupt.h> volatile char jobflag; int main(void) { char count = 0; TCCR0A = (1 << WGM01); TCCR0B = (1 << CS02) | (1 << CS00); TIMSK0 = (1 << OCIE0A); OCR0A = 60; DDRB = (1 << 1); sei(); while(1) { if(jobflag) { jobflag = 0; count++; count %= 4; if(!count) PINB |= (1 << 1); } } } ISR(TIMER0_COMPA_vect) { jobflag = 1; } [/c] Statistik
-
Thread
Timerproblem
Prinzip her ist diese Lösung in dieser konkreten Situation besser, als erst mal umständlich ein Jobflag Variable zu bemühen, in der Hoffnung, dass in der Hauptschleife so zeitnah darauf reagiert werden kann, so dass keinem die manchmal zeitweilige Verkürzung des Intervalls auffällt. Diese LED hier
-
Thread
interner RTC oder externer
Timeout fehlt. void __ISR(_RTCC_VECTOR,ipl6) _RTCCInterrupt(void) Die ISR. Die setzt nur ein Jobflag. Alles weitere passiert in einem Eventhandler. Für die Funktion kann ich nicht garantieren, es läuft aber seit >1Jahr in meiner Wetterstation.
-
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
ATMega8 Timer0 verliert Interrupts
vielleicht ginge auch der Timer2, der kann das. im Übrigen bin ich auch der Meinung, das vieles mit Jobflags besser gelöst ist. Ein SEI ist die ungünstigste Variante. Zu schnell findet man sich in einer unnötigen Fehlersuche wieder. Mag ja sein, das es Briefe gibt, die man direkt im Beisein des Briefträgers
-
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
Problem mit Interrupt-Funktion
als gültige Signale abgelegt. Nun kann man entscheiden, ob eine weitere Eventsteuerung mittels Jobflags aufgesetzt werden soll, sprich Flankenauswertung. Z.B. Du hast ene VAriable namens Ablage. In jedem Durchlauf prüfst du mit einer ExclusivOder, ob neue Signaleingänge zu den abgelegten unterschiedlich
-
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
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
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
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
CTC Timer - immer 2s zuviel
Millisekunde eine ISR aufgerufen wird. Und den Rest leitet man dann mit entsprechenden Zählern und Jobflags von diesen 1 Millisekunden her. Aber der Timer tickt durch. Ständig. Der Zeitfehler ist dann nicht größer als diese 1 Millisekunden, was angesichts diverser Ausgaben völlig ausreichend ist.
-
Thread
Probleme mit Counter auf Atmega8
z.B. mit einer ISR zu arbeiten. Schau mal über die Suchmaschine, ob du irgend welche Beiträge zu Jobflags findest. Dann wird dir vermutlich auch deutlich, welche Struktur du beim Programmieren, grad in Assembler, dir angewöhnen solltest. Ansonsten schau mal zur Konkurenz AVR-Praxis.de. Dort ist in der
-
Thread
mit kurzen Impulsen schalten / gegenseitig entriegeln / Attiny2313
fertig... job_neues_byte: ;es ist ein neues Byte eingetroffen cbr flags,1<<neubyte ;Jobflag entwerten ldi yl,low(toz-1) ;Pointer vor Timeout-Zähler ldi yh,high(toz-1) ;im SRAM ldi zl,low(bimu*2-5) ;Pointer 5 vor Bitmustertabelle ldi zh,high(bimu*2-5) ;
[avrasm] job_neues_byte: ;es ist ein neues Byte eingetroffen cbr flags,1<<neubyte ;Jobflag entwerten ldi yl,low(toz-1) ;Pointer vor Timeout-Zähler ldi yh,high(toz-1) ;im SRAM ldi zl,low(bimu*2-5) ;Pointer 5 vor Bitmust ... [/avrasm] und auch da verschaffen
-
Thread
Datenverwaltungsprogramm für Atmel-Mikrocontroller (Ankündigung)
ist es auch nicht erforderlich, jede Änderung in den Variablen mitzubekommen. Oft reicht es, die Jobflags zu untersuchen, um herauszufinden, warum das Ergebnis vom Erwarteten so unterschiedlich ist. Für mich hat OpenEye gute Dienste geleistet. Sicher kann einiges verbessert werden, aber ich hab auch nicht
-
Thread
Programmstruktur/Codeaufteilung in verschiedene Dateien
Einziger Punkt den man überlegen kann: Steckt man alles in die ISR oder macht man sich die Arbeit Jobflags zu benutzen so dass die Hauptschleife in main() die Arbeit macht. Da es aber nur auf das Umschalten von Portpins zu geeigneten Zählerständen rausläuft, würde ich der Einfachheit halber alles in der
-
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
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
Problem mit Temperaturmesssystem
die Zeitbehandlung machen. Wenn es an der Zeit ist eine neue Messung anzustossen, dann wird ein Jobflag gesetzt, welches in loop() ausgewertet wird. Damit hast du die Messung von der Erfassung und Zählung der Zeitintervalle entkoppelt. Jetzt muss nur noch das Intervall der Messungen länger sein, als
-
Thread
Zweipunktregler mit uC programmieren: Anfänger
das ein Standardaufsatz: Timer erzeugt einen Basistakt, in der ISR wird die Zeit runtergeteilt, Jobflag gesetzt dass es wieder an der Zeit ist einen Korrekturzyklus einzulegen, der dann auch durchgeführt wird.
-
Thread
C Pointer auf Array an Funktion übergeben
Und die Sache mit den Jobflags verstreu sie nicht über das ganze Programm. Lass die Auswertung ruhig in der Hauptschleife [C] void MesseFeuchte(char *str) { static uint16_t i = 0; // // Die Zeitdauer zwischen
-
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
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
Programmablauf / Modellauto Steuerung
diese 1000 erreicht hat (oder von 1000 auf 0 runtergezählt hat), dann setzt du eine Variable (das Jobflag) auf 1. In der Hauptschleife wird natürlich unter anderem geprüft, ob das Flag auf 1 steht und wenn ja wird die LED umgeschaltet und das Flag wieder zurückgesetzt. Gewartet wird nicht mehr. Auf
-
Thread
ATMEGA32 Programmierung einer Windkraftanlage
Zustandsmaschinen aufbaut zb dass ein Systemtakt in Form einer ISR nicht schlecht ist zb dass ein Aufbau mit Jobflags seine Vorteile hat zb wie das mit Timern funktioniert zb wie man Drehzahlen vernünftig misst zb das man Datentypen nicht unnötig groß wählt zb was atomarer Zugriff ist etc. etc.
-
Thread
AVR-Studio - Code Größe anzeigen
Compiler erstmal die halbe CPU sichern muss. Daher ist es des öfteren besser, in der ISR nur ein Jobflag zu setzen und die eigentliche Arbeit in der Hauptschleife zu machen.
-
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
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
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
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
Problem beim DREHGEBER
drehgeber: ;UP, liest Drehgeber und Taster entprellend ein cbr merker,1<<entprell ;Jobflag löschen push wl ;Variablen beschaffen push wh push r0 push r1 push zl push zh lds wl,evt ;Entprell-Vorteiler holen, inc wl ;erhöhen
-
Thread
problem mit peter fleurys uart lib und interrupts
überwechseln: In der ISR gar nicht ausgeben. Zumindest nicht derartige Mengen. Setzt dir in der ISR ein Jobflag und atbeite das im Hauptprogramm ab und mach von dort die Ausgaben. In einer ISR möchtest du normalerweise sowieso nicht ausgeben, da dir dieser Interrupt jederzeit überall reinknallen kann, zb