Futaba S Bus Dekoder, Fehler im Programm

[Michael L. (fliegermichl)]

Hallo zusammen,

ich suche schon seit Tagen nach einem Fehler in anhängendem Programm.
Es handelt sich um einen Dekoder für das Futaba S.BUS Protokoll. 
(Modellbauecke)

das Protokoll sendet alle 14 ms eine Folge von 300 Bits und zwar immer 
ein Startbit, 8 Datenbit, ein Paritybit und 2 Stopbit. Jedes Bit ist 
ziemlich genau 10 Mikrosekunden breit.

Da der Bus keine Taktleitung hat, lasse ich per externem Interrupt bei 
jedem Startbit den Timer2 10 Mikrosekunden lang laufen und lese im 
Compare Match Interrupt die Eingangsleitung (PD2). Sind alle 8 Datenbit 
und das Parity Bit eingelesen, stoppe ich den Timer und aktiviere wieder 
den externen Interrupt um mit dem nächsten Startbit wieder mit dem Bus 
zu synchronisieren.

Das Problem: Manchmal geht das erste oder auch das erste und zweite 
Datenbit verloren so als ob der Timer doppelt oder 3 mal so lange läuft 
wie er soll.
Wenn das Problem auftritt, so tut es dies bei jedem Frame.

Ziehe ich die Spannungsversorgung vom Board ab und stecke sie wieder an, 
so tritt der Fehler entweder auf oder aber auch nicht. Dies dann aber 
ganz konsequent bei jedem Frame.

Das gelbe Signal ist die S Bus Leitung. Das blaue Signal zeigt, wann das 
Programm den Bus ausliest (bzw. ein Takt vorher)

Ich hatte zunächst angenommen, daß mit der Synchronisation etwas nicht 
stimmt. So lasse ich PC1 beim ersten Startbit setzen und nach dem Ende 
der Sequenz wieder löschen. Das haut aber in jedem Fall hin (Davon hab 
ich kein Bild angehängt)

Vielleicht erbarmt sich ja einer meiner und schaut mal über das 
Programm.
Ich verwende einen ATMega8 mit 8Mhz externem Quarz.

Danke und Gruß
 der Michl

[Michael L. (fliegermichl)]

Nachtrag,

wenn ich das Programm im Simulator (AVR Studio 4.18 Simulator V1) laufen 
lasse, tritt der Fehler nicht auf.
Im Anhang eine Stimuli Datei 6 kompletten Frames.

Gruß
 Michl

[LD (Gast)]

Hallöchen,

ich bin nicht so fit in Assembler als dass ich mir das jetzt eben 
durchlesen könnte, nur als andere Variante:

- Ich habe beim Lesen von verschiedensten Bus-Telegrammen bessere 
Erfahrungen mit der capture-Funktion gemacht. Da du ja weißt wann welche 
Bit- oder Pausenlängen auftreten.

Nur als mögliche Variante ;)

[Michael L. (fliegermichl)]

Hallo,

das geht leider nicht. Wenn sich von einem Bit zum nächsten nichts 
ändert, dann belässt der Bus die Leitung einfach so wie sie ist.

Die einzigen Kandidaten sind die Stopbits (immer 1 also 0V da 
invertiert) und das Startbit (immer 0 also 5V da invertiert)

Dazwischen muß ich mit dem Timer arbeiten.

Mir scheint, daß ich irgend eine Initialisierung vergessen habe. Aber 
welche?

Ich hatte auch orakelt, daß vielleicht der Prozessor aus irgendeinem 
Grund resetet wird. Deshalb die 3mal 100 ms blinken der roten LED beim 
Programmstart. Das ist aber auch nicht der Fall.

Aufgefallen ist mir, daß die gelbe LED nach dem Start immer mal kurz 
aufblitzt und dann entweder aus bleibt (my Error is running) oder an 
bleibt (my Program is running)

Weiss jemand, wie das mit dem Hardware Debugger funktioniert? Dann 
könnte man dem Prozessor auf die Finger lunzen. Wie schon weiter oben 
beschrieben, tritt der Fehler nicht auf, wenn ich das Programm im 
Simulator laufen lasse.

Gruß
 Michl

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Michael Läßig schrieb:
> das Protokoll sendet alle 14 ms eine Folge von 300 Bits und zwar immer
> ein Startbit, 8 Datenbit, ein Paritybit und 2 Stopbit. Jedes Bit ist
> ziemlich genau 10 Mikrosekunden breit.
Warum fällt mir da sofort "serielle Schnittstelle" und 100kBd ein?
Kannst du nicht einfach den UART vom uC nehmen?

Ein Transistor könnte die nötige Invertierung des Signals übernehmen...

[Michael L. (fliegermichl)]

Hallo,

Das wäre eine Möglichkeit. Aber interessehalber würde ich schon gern 
wissen, wieso vom Aufruf start_read_timer im INT0 Handler bis zum 
CompareMatch Interrupt manchmal ca. 20 Mikrosekunden vergehen, der 
CompareMatch Interrupt danach aber wieder richtig alle 10 Mikrosekunden 
feuert.

Wenn ich es mir so recht überlege, ist die Verwendung des UART mit 
Sicherheit die bessere Variante, da ich die Timer dann für andere Zwecke 
verwenden kann. Das Programm soll ja später noch mehr machen als nur das 
Bus Signal zu dekodieren.