Hallo Leute, ich sende in einem Programm eine Nachricht via Funk zu einem anderen Controller. Das ganze geschieht in einer Schleife, in welcher das Programm am Ende auf ein ACK vom anderen Controller wartet. Kommt dies nicht, wird die Nachricht erneut gesendet (deshalb die Schleife). Die Antwort kommt via INT0 rein und wird in der ISR ausgewertet (Zeit ist genug da). Ist die Nachricht korrekt, so wird in der ISR ein Flag zum Verlassen der Sendeschleife gesetzt. Mein Problem betrifft nun das Warten auf den Interrupt. Aktuell lasse ich einfach in einer for-Schleife ein wenig rechnen. Kann ich zur definierten Zeiteinstellung auch ein _wait_ms() nutzen oder blockiert mor das den INT0?
Jens K. schrieb: > ich einfach in einer for-Schleife ein wenig rechnen. Kann ich zur > definierten Zeiteinstellung auch ein _wait_ms() nutzen oder blockiert > mor das den INT0? Nein, INT wird nicht blockiert. Hast du keinen Systimer in deinem Code ?
Das kommt auf die Implementierung von _wait_ms, den Prozessor, den Compiler, dazu dem Wetter und dem Vornamen deiner Tante an. Merkste was? Oliver
:
Bearbeitet durch User
@ Jens K. (mister232) >ich sende in einem Programm eine Nachricht via Funk zu einem anderen >Controller. Das ganze geschieht in einer Schleife, in welcher das >Programm am Ende auf ein ACK vom anderen Controller wartet. Kommt dies >nicht, wird die Nachricht erneut gesendet (deshalb die Schleife). Die >Antwort kommt via INT0 rein und wird in der ISR ausgewertet (Zeit ist >genug da). Ist die Nachricht korrekt, so wird in der ISR ein Flag zum >Verlassen der Sendeschleife gesetzt. AUA. Das klingt alles nach einem SEHR schlechten Konzept. Siehe Interrupt. >Mein Problem betrifft nun das Warten auf den Interrupt. Eben das tut keiner. Ein Interrupt wird verarbeitet, wenn er generiert wird, da muss dien CPU nicht drauf warten. > Aktuell lasse >ich einfach in einer for-Schleife ein wenig rechnen. Kann ich zur >definierten Zeiteinstellung auch ein _wait_ms() nutzen Kann man, blockiert dir aber zu 100% die CPU. Und wenn wu in einer ISR wartest, was so oder so ganz böse ist, wird dein INT0 Interrupt nie aufgerufen, denn der AVR hat keine verschachtelten Interrupts. > oder blockiert mor das den INT0? Nur, wenn du schon in einer anderen ISR bist.
Jens K. schrieb: > Mein Problem betrifft nun das Warten auf den Interrupt. Das ist mal eine kuriose Strategie: "Auf eine Unterbrechung warten". Das ist doch eine Umschreibung für "Langeweile haben". Wenn du schon aktiv Rechenzeit vernichten willst, warum pollst du dann nicht solange einfach direkt die IO-Leitung, an der das ACK-Signal hereinkommt?
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Wenn du schon aktiv Rechenzeit vernichten willst, warum pollst du dann > nicht solange einfach direkt die IO-Leitung, an der das ACK-Signal > hereinkommt? Wahrscheinlich weil er keinen Systimer hat und irgendwie die Zeit welche zwischen Senden und ACK vergangen ist, rauskriegen muss.
Die Fragen wurden ja schon beantwortet. Und wie schon gesagt, ist "Warten auf Interrupt" ganz schlecht. Da du ja schon einen Interrupt hast, nämlich INT0, kannst du ja gleich noch einen zweiten dazu bauen, nämlich einen TimerInterrupt T1_INT. Du stellst den Timer auf die zu wartende Zeit, schickst deine Message ab und startest den Timer. Dann kannst du von mir aus machen was du willst. Tritt der T1_INT ein, kam kein ACK, tritt der INT0 ein, ist alles OK. Dann wieder von vorne.
Jens K. schrieb: > ich sende in einem Programm eine Nachricht via Funk zu einem anderen > Controller. Das ganze geschieht in einer Schleife, in welcher das > Programm am Ende auf ein ACK vom anderen Controller wartet. Kommt dies > nicht, wird die Nachricht erneut gesendet (deshalb die Schleife). Das ist schon vom Ansatz her eine Scheisskonstruktion. Befasse dich mit ereignisorientierter Programmierung und state machines, dann brauchst du solche hirntoten Konstrukte nicht mehr und hast dann auch keine solchen Probleme mehr. Ja klar, es gibt Fälle, in denen diese prinzipiell hirntoten Konstrukte tatsächlich genügen oder sogar die bestmögliche Lösung sind. Aber das sind wirklich eher seltene Ausnahmen. Nur Anfängern kommt es so vor, als könnte es anders sein...
Vielen Dank für die Antworten. Ich werde das mit dem Timer von DanVet mal ausprobieren.
c-hater schrieb: > Jens K. schrieb: > Das ist schon vom Ansatz her eine Scheisskonstruktion. Befasse dich mit > ereignisorientierter Programmierung und state machines, dann brauchst du > solche hirntoten Konstrukte nicht mehr und hast dann auch keine solchen > Probleme mehr. > > Ja klar, es gibt Fälle, in denen diese prinzipiell hirntoten Konstrukte > tatsächlich genügen oder sogar die bestmögliche Lösung sind. Aber das > sind wirklich eher seltene Ausnahmen. Nur Anfängern kommt es so vor, als > könnte es anders sein... Ehrlich gesagt habe ich deinen Kommentar nicht verstanden. Es sei denn du hast meinen Post (vor deinem) nicht gelesen und meinst das selbe wie ich.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.