Hallo, ich bin Einsteiger und überlege für ein Projekt, ob ich mit Polling oder Interrupt arbeiten soll. Im Projekt geht es darum, RS232-Befehle an eine Temperaturregelung weiterzugeben, z.B. Einstellen einer Temp., Auslesen einer Temp., Einstellen von Modi und Parametern etc. Also nicht unbedingt zeitkritische Anwendungen, und die Regelung muss ja sowieso erstmal reagieren und braucht dann etwas Zeit bis zum eingeschwungenen Zustand. Wie würdet ihr das lösen? Ich tendiere zur Zeit zu Polling, weil mir diese Art der Steuerung einfach klarer und robuster erscheint. Außerdem würden mich allgemeine Pro und Cons interessieren.
Hi, ich persönlich finde die Nutzung von Interrupts prinzipiell sehr elegant. Wichtig ist nur das die Interrupt Service Routine (ISR) die verwendeten Register sichert (push/pop). Außerdem solltest du unbedingt das SREG sichern und wieder herstellen wenn die ISR verlassen wird. Schema z.B. für Timer1 overflow : onTC1: push r16 in r16,SREG push r16 ; ; hier Deine Anweisungen ; pop r16 out SREG,r16 pop r16 reti Alternativ zum (dauerhaften) persistent polling, wobei das Programm wartet bis das erwartete Ereignis eintritt, kannst du auch eine einmalige Abfrage machen (non persistent). Falls das Ereignis noch nicht eingetreten ist macht das Programm einfach weiter - villeicht klappt es dann im nächsten Durchlauf. Damit hast du dann nicht einen so großen Zeitverzug. Gruß Stefan
M. I. wrote: > Hallo, > > ich bin Einsteiger und überlege für ein Projekt, ob ich mit Polling oder > Interrupt arbeiten soll. > > Im Projekt geht es darum, RS232-Befehle an eine Temperaturregelung > weiterzugeben, z.B. Einstellen einer Temp., Auslesen einer Temp., > Einstellen von Modi und Parametern etc. > > Also nicht unbedingt zeitkritische Anwendungen, und die Regelung muss ja > sowieso erstmal reagieren und braucht dann etwas Zeit bis zum > eingeschwungenen Zustand. > > Wie würdet ihr das lösen? Ich tendiere zur Zeit zu Polling, weil mir > diese Art der Steuerung einfach klarer und robuster erscheint. > In diesem Fall ist das auch so! Bei Polling oder abscannen im Timerinterrupt (z.B) hast Du auch gleichzeitig die Möglichkeit einer TIMEOUT Überwachung. > Außerdem würden mich allgemeine Pro und Cons interessieren.
@Dirk Hofmann Du meinst den Watchdog? Wieso hätte ich diese Möglichkeit bei Interrupts nicht?
M. I. wrote: > @Dirk Hofmann > > Du meinst den Watchdog? Wieso hätte ich diese Möglichkeit bei Interrupts > nicht? Nein ich meine nicht den Watchdog. Dieser schützt davor, wenn sich Ein System im Nirvana aufhängt. Ich meine hier eine partielle Kontrolle der Pheripherie, die sozusagen in einem "Aufwasch" erledigt wird. Dadurch bekommst Du auch ein nachvollziehbares Timing für Reaktionszeiten. Um dies jedoch zu beurteilen, solltest Du mal schildern, was Du genau pollen willst!?
Im Grunde geht es um das Pollen von RS232-Befehlen, also der UART-Receive muss abgefragt werden, um die Befehle dann in Steuerinformationen an den Regler umzusetzen. Wenn z.B. der Befehl "Setze Temperatur auf X Grad" ankommt, muss im Regler eben diese Solltemperatur eingestellt werden.
Würde ich persönlich mit einer Kombination aus ISR und Polling realisieren. In der ISR wird das Zeichen von der UART geholt und in einen Buffer gestellt. Ist das Zeichen das vereinbarte End-eines-Befehls Zeichen (dafür würde ich Return benutzen), dann setzt die ISR ein Jobflag, dass eine Zeile komplett empfangen wurde. Das Polling geschieht in der üblichen main-Schleife. Diese pollt unter anderem das Eine-Zeile-empfangen Job Flag und wenn dieses signalisiert, dass eine Zeile da ist, wird in der main-Schleife das Kommando ausgewertet.
1 | char UARTLine[40]; // hier hinterlässt die ISR die empfangene |
2 | // Zeile
|
3 | volatile uint8_t lineReceived; // wird 1 wenn von der ISR |
4 | // ein CR empfangen wird
|
5 | |
6 | |
7 | int main() |
8 | {
|
9 | ....
|
10 | |
11 | while( 1 ) { |
12 | |
13 | if( lineReceived == 1 ) { |
14 | // eine Zeile ist eingelangt, werte sie aus
|
15 | |
16 | ....
|
17 | |
18 | lineReceived = 0; |
19 | }
|
20 | |
21 | ....
|
22 | |
23 | }
|
24 | }
|
So ungefähr. Oh, und die ISR ist natürlich der UART Receive Interrupt.
Danke für den Vorschlag. Was mich etwas daran stört ist die Tatsache, dass bei jedem erhaltenen Zeichen der Interrupt ausgelöst wird. Eigentlich bräuchte ich den Interrupt ja nur, wenn ein kompletter Befehl mit Ende-Zeichen angekommen ist. Da das Programm auch noch andere Routinen enthalten wird, die nicht durch RS232-Befehle gestartet werden, etwa eine Berechnung von Soll-Ist-Differenztemperaturen, funkt mir der Interrupt unter Umständen ständig dazwischen, obwohl der komplette Befehl noch gar nicht übermittelt ist. Kann ja durchaus sein dass der Prozessor damit kein Problem hat, aber ich stelle es trotzdem mal zur Diskussion.
M. I. wrote: > Danke für den Vorschlag. > > Was mich etwas daran stört ist die Tatsache, dass bei jedem erhaltenen > Zeichen der Interrupt ausgelöst wird. Eigentlich bräuchte ich den > Interrupt ja nur, wenn ein kompletter Befehl mit Ende-Zeichen angekommen > ist. > > Da das Programm auch noch andere Routinen enthalten wird, die nicht > durch RS232-Befehle gestartet werden, etwa eine Berechnung von > Soll-Ist-Differenztemperaturen, funkt mir der Interrupt unter Umständen > ständig dazwischen, obwohl der komplette Befehl noch gar nicht > übermittelt ist. Was ist dir lieber: Das ein empfangenes Zeichen einen Interrupt auslöst und in dieser ISR in 5 bis 10 Taktzyklen das Zeichen geholt und zwischengespeichert wird oder wenn du ständig alle paar Millisekunden die UART überprüfen musst ob nicht vielleicht in der Zwischenzeit ein Zeichen eingetrudelt ist, dass zwischen- gespeichert werden muss. Die ISR wird nur dann aufgerufen, wenn auch wirklich ein Zeichen über die UART eingetroffen ist. Da du die Kommandos händisch eingibst, dürfte das ja nicht so oft der Fall sein. Aus Sicht des µC vergeht zwischen 2 empfangenen Zeichen allerdings eine halbe Ewigkeit.
Du hast schon Recht, abgefragt werden muss der UART ja so oder so. Ich dachte, vielleicht gibt es eine Möglichkeit, erst den UART-Eingang zu verarbeiten wenn ein kompletter Befehl eingetroffen ist. Aber je mehr ich darüber nachdenke desto mehr merke ich, dass das Blödsinn ist ;)
Bitte 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.