Sinvoller Codeaufbau?

[Fremder (Gast)]

Hallo,

ich bin neu in dem Thema der uC bzw. ASM und habe eine Frage zum 
Codeaufbau.

Ich habe eine zeitunkritische MAIN in der auf ein paar externe Signale 
gewartet (teilweise mehrere Sekunden) und dann weitergerechnet werden 
muss. Parallel hierzu soll der uC aber seinen Status per Blinkmuster 
signalisieren. Diese Blinkroutine braucht aber auch etwas länger (~ 40 
Wörter). Was viel zu lange für eine ISR ist, zumal andere Zeitkritische 
Interrupts auftreten können.

Meine Idee ist einen durchlaufenden Timer mit x ms CompareInterrupt 
laufen zu lassen. Der Interrupt tut nichts ausser Interrupts wieder 
freigeben (SEI) die Blinkroutine aktivieren (RCALL). Im Folgenden noch 
mal als Code

.org 0x000
   RJMP RESET   
.org INT0addr
   RJMP INT0addr       
.org OC1Aaddr
   RJMP OC1Aaddr


RESET:
   NOP ;Initialisierung des uC
   NOP
   NOP
   SEI ;Interrupts erlauben

MAIN:
   NOP ;Teile der MAIN

   loop: ;Warten das an Port D 0xAA
   IN R16, PIND
   CPI R16, 0xAA
   BRNE loop

   NOP ;noch mehr MAIN

   RJMP MAIN

OC1Aaddr:
   SEI
   RCALL BlinkR
   RET

BlinkR:
   NOP ;Lange BlinkRoutine
   NOP
   NOP
   RET

INT0addr:
   NOP ;Wichtige ISR
   RETI

Macht soetwas Sinn?
Was gäbe es für Alternativen und was wäre die bessere/beste?


Danke für eure Hilfe!
--Daniel

[Conny G. (conny_g)]

"sei" in einem Interrupt ist ein bisschen gefährlich, man kann sich dann 
nicht mehr sicher sein, dass nicht diese Routine wieder von demselben 
Interrupt unterbrochen wird und dann läuft man einen Stack Overflow.
Sollte man gar nicht erst anfangen.

40 Worte (Befehle?) pro Millisekunde ist nicht so viel, das sind bei 8 
Mhz 40/8000 = 0,5% Auslastung des Prozessors.
Natürlich könnte etwas anderes diese 40 Takte = 5 Mikrosekunden warten 
müssen, das hängt davon ab, wie zeitkritisch das wirklich ist.

Es gibt auch noch die Möglichkeit die Blinkroutine zu kürzen und mehr 
Logik ausserhalb zu platzieren, die Blinkroutine ermittelt nicht, was zu 
tun ist, sondern führt lediglich aus.

[Karl H. (kbuchegg)]

Fremder schrieb:

> muss. Parallel hierzu soll der uC aber seinen Status per Blinkmuster
> signalisieren. Diese Blinkroutine braucht aber auch etwas länger (~ 40
> Wörter).

Aus wievielen Befehlen die ISR besteht, ist egal. Entscheidend ist, wie 
lange das zur Abarbeitung braucht!

> Was viel zu lange für eine ISR ist, zumal andere Zeitkritische
> Interrupts auftreten können.

Ganz klar: Jobflags fürs Blinken.

Der andere Punkt:
Bei zeitkritisch, über wieviel Zeit reden wir da? Wieviele µs dürfen vom 
auftreten des Ereignisses bis zu seiner Behandlung in einer ISR 
vergehen.

Ich trau mich wetten, das das was du unter zeitkritisch verstehst recht 
wenig damit zu tun hat, was man bei vernünftiger Programmierung 
problemlos erreichen kann. Mit Warteschleifen in einer ISR (und sei es 
nur zum Blinken einer LED) gewinnt man hingegen keinen Blumentopf.

[oldmax (Gast)]

Hi
Es ist auch in ASM kein Problem, seinem Programm den Charakter einer 
Ereignissteuerung zu verpassen. Die Main 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. Einfach alten Wert mit neuen 
Wert EOR-Verknüpfen und je nach Wunsch das Ergebnis mit altem oder neuem 
Wert verunden. Vielleicht hilft dir das Tutorial hier etwas weiter. 
Sonst gibt es noch einé kleine Anleitung in ÀVR-Praxis-Forum unter der 
Rubrik "FAQ" im Beitrag "Keine Angst vor Assembler". Das steht dann auch 
drin, wie das mit den Ereignissen gemeint ist.
Gruß oldmax

[Falk B. (falk)]

Siehe Multitasking. Das geht 1:1 auch in Assembler.

[Fremder (Gast)]

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 
des SRAM um die Flags zu setzen und zu kontrollieren, aber irgendwie 
habe ich das Gefühl, dass man damit erst so richtig die 
Leistungsfähigkeit eines AVRs ausnutzt.
Auf Blöd kann man damit sogar eine Art Interrupt-Priorität machen. Sehr 
genial...