Hi
ich hab gerade was gefunden, das Dir u.U. weiterhelfen könnte .. so als Basis : http://www.knology.net/~gdion/whereavr.html

Also meine pingpongspiel:

Für den Ablauf, wenn es auf darauf ankommt, daß der uC mehr als nur einen Job macht, sollte man keine blockierenden Schleifen nutzen .. das haut einem das Ablauftiming immer wieder durcheinander ...

Also versuche ich meine Vorgehensweise möglichst einfach zu beschreiben:

Also nimmst Du eine globale Variable initalisierst diese mit 0 und machst via switch/case im Hauptprogramm eine Verteilung, was passieren soll, wenn die gV einen bestimmten Wert hat ...

Fängt an, Du willst was senden, im SendeStapel liegen Daten bereit - dann setzt Du gV auf 10 - als Startflag.

Wenn 10, dann Daten in Sendebuffer übertragen und Sendevorgang starten, gV auf 11.
Wenn Daten abgesendet, dann gV auf 12 setzen. Wenn 12, dann via Timer eine Abruchvariable (fürs Timeout) hochzählen.
Wenn jetzt ein ack (Empfangsbestätigung der Gegenseite) kommt) wird gV auf 13 gesetzt.
Wenn 13, dann Timeout löschen und gV = 14.
Wenn 14, dann job fertig, gV auf 0.
Wenn Daten reinkommen, dann gV auf 20,
wenn Daten fertig gV auf 25.
Wenn 25, dann Daten auswerten,
....

Verstanden, was ich meine ...
Das Hauptpgrogrammtiel sorgt für die Abarbeitung der gV - Zustände.

gV sollte auch abgefragt werden, bevor was neues in die Hauptabarbeitung gelangt und und wenn diese "belegt ist" ggf. auf einen Stapel gepackt werden.

Bevor jetzt ein gV wieder auf 0 gesetzt wird, eben auf 200 setzen, und Jobstapel - Element holen und entsp. weiterverfahren, wenn nichts zu tun, dann eben erst auf 0 setzen.

Verscheidene Programmteile, die z.B. via Timer oder Interrupt ausgeführt werden, müssen ggf. auch gV abfragen und entsp. handeln ...

Ping-Pong, weil immer hin-und-her-gesprungen wird.

So, hoffe nichts vergessen zu haben
Idee der Abarbeitung verstanden ...
.. auf diese Art und Weise, mußt Du keine for(irgendwas)-Schleifen einsetzen.
Insbesondere kann ein Interrupt von außen die aufgaben des uC ja auch bestimmen und z.b. einen Sendevorgang sinnvollerweise verzögern oder eben erst zu ende machen lassen und seinen Job dranhängen ...

Auf die Art und weise koppel ich einiges in meinen Progs mit Timerjobs, UART-RX/TX und LCD-Out, DCF77 auswerten, Schrittmotor steuern u.s.w. quasi parallel ...

... habs mal probiert, meine LCD-Routine konnte Texte ausm RAM so schnell ausgeben, daß ein mitlesen durch zwinkern nicht möglich ist (man den Text klar lesen kann), während gleichzeit die DCF77-Auswertung stimmig erfolgt und die RS232 bedient wird ...

Also, wenn Du Dein Paketsystem beibehalten willst, muß das als untergeordneter PPJob laufen ...
Und eben auch drauf reagieren, wenn nicht innerhalb eines Zeitfensters eine Antwort der Gegenstelle kommt ....

Eigentlich sollte es auch kein Problem sein, via Master die einzelnen Stellen zu pollen, ohne daß diese auch als Weiterleiter fungieren müssen ... wobei die Idee natürlich was hat

Liebe Grüße,
Vajk