USART - xmodem (Xminilab) - Bildübertragung

[Fabian H. (Firma: Technische Universität Berlin) (brein)]

Hallo Leute,

ich habe mir ja das Xminilab von Gabotronics besorgt.
Nun würde ich ganz gerne dessen Bildschirminhalt auslesen.

Dies geht über USART mit dem Befehlszeichen 'C' und als Antwort bekomme 
ich die Daten über das xmoden-Protokoll. (Manual Seite 27.)
http://de.wikipedia.org/wiki/XMODEM

Nun habe ich noch nie mit diesem Protokoll gearbeitet und ich verstehe 
im konkreten Fall nicht, was ich falsch mache.

Wenn ich 'C' sende, bekomme ich folgende 133 Zeichen wieder:

00000000: 01 01 fe 42 4d 3e 04 00   00 00 00 00 00 3e 00 00 
00000010: 00 28 00 00 00 80 00 00   00 40 00 00 00 01 00 01 
00000020: 00 00 00 00 00 00 04 00   00 00 00 00 00 00 00 00 
00000030: 00 00 00 00 00 00 00 00   00 00 00 00 00 ff ff ff 
00000040: 00 ff ff ff ff ff ff ff   ff ff ff ff ff ff ff ff 
00000050: ff ff ff ff ff ff ff ff   ff ff ff ff ff ff ff ff 
00000060: ff ff ff ff ff ff ff ff   ff ff ff ff ff ff ff ff 
00000070: ff ff ff ff ff ff ff ff   ff ff ff ff ff ff ff ff 
00000080: ff ff ff ab 86

Wenn ich das richt verstanden habe, kommt erst das Startbyte 0x01, was 
auch stimmt, dann eine Blocknummer, für den ersten auch 0x01 und dann 
das Einerkomplement von der Blocknummer. In diesem Fall 0xFE. Dann 
kommen die 128 Bytes Payload und eine Prüfsumme.
Ich erhalte aber erstens 133 Bytes und zweitens dachte ich, ich müsste 8 
Blöcke erhalten. Das Display hat eine Auflösung von 128x64. 128 Bytes 
pro Block, 8 Bits (Punkte) pro Byte. So werden mit jedem Block 1024 
Punkte übertragen.

$$128 \cdot 64 = 8192 = 1024 \cdot 8$$

Wenn ich aber 0x06 sende passiert nichts. Auch wenn ich den Empfang 
ablehne 0x15, wird nicht wie vorgesehen, der Block wiederholt.

Ich nehme mal ganz stark an, dass 0xAB meine Prüfsumme ist (ich habe 
es nicht nachgerechnet) und das 0x86 ein Fehlercode ist? Wie lange 
habe ich denn eigentlich Zeit, um 0x06 zu senden? Ich mache das im 
Moment über CuteCom (Terminalemulator).

Oder mache ich etwas anderes falsch?

Gruß und vielen Dank
Fabian

[Fabian H. (Firma: Technische Universität Berlin) (brein)]

hmmm, verwendet man heute überhaupt noch das xmodem-Protokoll?

OK, man hat bes bei Modems eingesetzt. Aber heute? Da fallen mir eben 
nur solche Spezialfälle ein.

Gruß
Fabian

[Reinhard Kern (Gast)]

Ich glaube, hier werden alle deine Fragen beantwortet:

http://www.atmel.com/Images/doc1472.pdf

Gruss Reinhard

[Fabian H. (Firma: Technische Universität Berlin) (brein)]

Sieht sehr gut aus! Danke!
Melde mich sicher bald wieder1 ^^

[Fabian H. (Firma: Technische Universität Berlin) (brein)]

Danke Reinhard Kern!

Habe es durchgelesen und bin jetzt ein kleines Stück weiter.
Es sind also doch 133 Bytes, da es sich um das Xmodem CRC Protokoll 
handelt und dieses zwei Bytes als Checksumme sendet.

Gut soweit.
Warum aber, sendet es nur einen Block?
OK, es sendet auch kein EOF. Demzufolge erhält es mein ACK nicht.
Wie lange aber wartet es denn auf das ACK? Ich gebe die Befehlte über 
ein Terminalemulator raus. Kann schon sein, dass ich als Mensch zu 
langsam bin.
Aber müsste das Gerät denn nicht den Block wiederholen, wenn es kein ACK 
bekommt?

Gruß
Fabian

[Reinhard Kern (Gast)]

Hallo,

Lesen bildet, steht alles da drin: Xmodem ist "receiver driven", es 
passiert nur was, wenn der Empfänger eines der Controlzeichen sendet, 
Timeout gibt es nicht. Bleibt die Frage, wieso reagiert der Sender auf 
C, aber nicht auf ACK? Das könnte die falsche Parity sein, denn C hat 
eine andere Parity als ACK und NAK. Mehr Ferndiagnose geht leider nicht.

Gruss Reinhard

[Fabian H. (Firma: Technische Universität Berlin) (brein)]

Reinhard Kern schrieb:
> Lesen bildet

Hatte ich! Nur leider falsch! ;)

Ich dachte "garbled" hieße sowas wie nicht angekommen, also in der Tonne 
gelandet.
Also sendet es nur wiederholt, wenn ein ACK oder was auch immer bekommt, 
aber es nicht als ACK identifizieren kann.
Was ist denn das Timeout für's ACK? Ist das definiert?

Aus dem Pseudocode werde ich nicht so ganz schlau.

Danke
Fabian

[Reinhard Kern (Gast)]

Hallo,

um ganz präzise zu sein: natürlich hat ein Programmierer überall, wo 
etwas NICHT passieren kann, ein geregeltes Timeout  vorzusehen, sonst 
würde sich das System im Fehlerfall ja für immer und ewig aufhängen (das 
passiert versehentlich schon oft genug). Im Protokoll ist aber kein 
Timeout vorgesehen.

Das macht aber nichts: der Sender tut eben nichts, wenn kein ACK kommt. 
Wenn ein C kommt, fängt er eben wieder von vorne an, usw. Kann schon 
sein, dass der Sender nach einer minutenlangen Pause nicht mehr 
reagiert, aber das ist eben nicht Bestandteil des Protokolls. Im Übrigen 
wurde das für steinzeitliche Überland-Telefonleitungen konzipiert und 
darf daher nicht wegen jedem kleinen Blitzschlag abbrechen.

Gruss Reinhard

[Fabian H. (Firma: Technische Universität Berlin) (brein)]

Reinhard Kern schrieb:
> Das macht aber nichts: der Sender tut eben nichts, wenn kein ACK kommt.
> Wenn ein C kommt, fängt er eben wieder von vorne an, usw.
Genau das beobachte ich auch.

> Kann schon
> sein, dass der Sender nach einer minutenlangen Pause nicht mehr
> reagiert, aber das ist eben nicht Bestandteil des Protokolls.
Ich gebe die Befehle zum Testen händisch ein, aber Minuten brauche ich 
dafür nicht. Ich brauche etwa eine Sekunde. Vielleicht liege ich sogar 
darunter.

Enter; 6; Enter;