Přenos souboru XMODEM

[jenda23]

Zdárek, potřeboval bych z procesoru přenést soubor do počítače, takže bych volil asi jeden z protokolů pro přenos dat a to XMODEM, bohužel jsem k tomu nenašel podrobnější informaci jak vlastně ten rpotokol funguje. Nemáte někdo něco, nebo popřípadě bych uvítal jestli by byl někdo ochoten zde tento protokol popsat. Ještě jsem uvažoval na protokolem Kermit, k tomu jsem něco málo našel, ale taky nic moc.

Díky jenda

[anonymousCoward]

Prinutil si ma pozriet do kalendara, ci som v spravnom storoci. Tie protokoly su mierne stare, okrem ineho - ale proti gustu ..
Mozes prosim rozviest, z akeho procesoru chces posielat data, cez aku fyzicku vrstvu, a co za OS bezi na PC ? Urcite existuje lepsie riesenie, aj keby si packety mal posielat po holuboch

Ale ak nechces, tak prosim: XYMODEM, Kermit.

[jenda23]

Jedná se o procesor atmega64 potřebuju vyslat data do TXT souboru z paměti eeprom. Na PC běží xp a výše, jde mi o univerzální podporu terminálu. Připojení bude přes COM port.

[anonymousCoward]

Ah, uz vidim - pravepodobne Ti ide o prenos cez HyperTerminal, preto poziadavka na tie protokoly.

Osobne by som to riesil cez obycajne RS-232 a parriadkovy server beziaci na WIndows - inak mi ako druhe najjednoduchsie pride spravit copy&paste z existujuceho a osvedceneho SW, napriklad z lrzsz. Ak dobre pozeram, ZMODEM je implementovany v subore src/zm.c (+ par headerov a vygenerovany config.h).

// Edit: tato implementacia vyzera na pohlad cistejsie, a robi snad len to co potrebujes; okrem toho bola pisana ako embedded. Je tam aj linka na skrateny popis protokolu XMODEM.

[jenda23]

Asi díky jednoduchosti zůstanu u Xmodemu, jak jsem procházel tu dokumentaci od Tebe a udělal jsem si log z požadavku na příjem souboru v hyperterminálu tak jsem koukal že po zadání názvu souboru odešle odesilateli symbol "C" a čeká. Teoreticky by pak mělo stačit odeslat první blok 128 bajtů ve formátu "SOH 01 FE Data[128] CRC CRC" počkat na ACK a a další blok. Chápu správně? Jen mi tam chybí od senderu odeslanej název souboru a potvrzení že byl otevřen.

[anonymousCoward]

S XMODEM vela skusenosti nemam, takze som si radsej precital celu dokumentaciu, a vidim viacero moznosti.
V prvom rade, mozeme pouzit cisty XMODEM (specifikacia je tu) - vyzera extremne jednoducho, ale nema CRC a nevie posielat metadata o subore (nazov suboru atd).
Alebo, mozeme pouzit XMODEM-CRC a snad len podmnozinu YMODEM (batch XMODEM), ktora vie posielat viacero suborov spolu so specifikovanim ich nazvu.

Mam rozpisanu odpoved aj na otazku ohladom komunikacie, ale radsej pockam na Tvoje vyjarenie, ci potrebujes CRC a/alebo posielat aj nazov suboru.

[jenda23]

No mým cílem je přenést vždy jeden soubor, CRC není nutností jelikož nejde o kritická data. Ale asi bych volil střední cestu čili Xmodem-CRC. Koukám von Terminál podporuje jen Xmodem, ale nevím jestli je s CRC nebo ne, ale vzhledem k tomu že odesílá "C" tak podle manuálu pokud začíná odesláním "C" by měl paket obsahovat i CRC. A teoreticky název souboru při čistém příjmu MCU>Terminál asi nebude třeba jelikož se název souboru zadává před započetím přijmu. A ani terminál nezačíná odesláním informace o názvu souboru, ale třeba to chábu blbě.

[sonikmartin]

JA jsem to kdysi resil tak ze jsem poslal Meze prikaz precti eeprom a data posli hned na uart a tam jsem jenom v SW bufroval jednotliva data a potom jde celek ulozit do cehokoli. SW pro takovouhle komunikaci je otazkou chvilky. Kdyztak se ozvi. Ja spise resil XMODEM kvuli bootloaderu, ale to jsem porad nejak nezlomil. Pouzivam porad puvodni od MCS, ale chci ho integrovat do svyh SW ale to se mi nedari.

[jenda23]

Já prozatím řeším přenos souboru za pomocí zachytávání z terminálu do souboru, ale todle mi přijde pohodlnější. Však MCS řeší přenos dat taky za pomocí Xmodemu...když si to odchytíš je komunikace s bootloaderem velice primitivní...

[anonymousCoward]

Terminal alebo HyperTerminal? To druhe by totiz podla linky, co som poslal v druhom prispevku, malo podporovat 'Kermit, Xmodem, Xmodem-1K, Ymodem, Ymodem-G, and Zmodem'. Konkretny protokol sa mozno da nastavit ... a mozno nie, neviem to teraz vyskusat.

Terminal (R) nazov suboru neposiela, aj ked by ho este pred zacatim prenosu mal mat k dispozicii. Preco sa zadava dvakrat, netusim - asi z historickych dovodov, aby si ho stahujuci pouzivatel mohol ulozit pod nim zvolenym nazvom.
Nazov suboru moze S poslat viacerymi sposobmi, uz podla protokolu - bud hned na zaciatku prenosu (MODEM7), alebo ako sucast *nulteho* bloku (TelLink t.j. YMODEM a vyssie). To druhe mi pripada ako prenosnejsi napad. Ale kedze Ti to netreba, asi to mozeme ignorovat.

A ano, ak to posiela 'C', zjavne to chce CRC-16; neviem ako funguje Tvoj terminal, ale podla wiki by mal terminal skusit poslat XMODEM-ovsky NAK, ak mu nepride odpoved na 'C'. Kedze pises ze CRC nie je nutne, zjednodusilo by to implementaciu - vies to otestovat ? Timeout po ktorom terminal posle NAK by mal byt v sekundach, mozno 3, mozno celych 10.

[jenda23]

Ano mám na mysli hyperterminal, omlouvám se za blbý vajádření. ANo hyperterminal obsahuje všechny tyto protokoly, a nastaví se před započetím přenosu. Mylsím že CRC bude třeba, dnes již nevyzkouším, začnu na tom pracovat zítra.

Vycházím z této dokumetace kterou jsi posílal jako první kde je uveden protokol s CRC tako

Figure 2. Mixed 1024 and 128 byte Blocks

SENDER RECEIVER
"sx -k foo.bar"
"foo.bar open x.x minutes"
C
STX 01 FE Data[1024] CRC CRC
ACK
STX 02 FD Data[1024] CRC CRC
ACK
SOH 03 FC Data[128] CRC CRC
ACK
SOH 04 FB Data[100] CPMEOF[28] CRC CRC
ACK
EOT
ACK

pokud v H terminálu zadám odeslat soubor, asi odešle i název (nezkoušel jsem), ale pokud zadám přijmout soubor zadám název souboru a on jen odešle C, čeká 10s na odpověď pokud nedostane odpovědi zkusí to asi ještě 5x a pak odešle ACK a ukončí přenos.

V příkladu je uveden kombinovaný přenos 128 a 1024 bloků, já využiji pouze 128 bytový blok. čili SOH znamená krátký paket, 01 číslo paketu, FE - to nevím co je, pak vlastních 128 Byte dat, pak 16bit CRC. Ale co znamená toto CPMEOF[28] netuším, jestli to není onen název souboru o délce max 28 Byte. Nemáš ponětí? A EOT je jasné.

[anonymousCoward]

Nazov suboru terminal neposiela, aspon som to nikde v dokumentacii nenasiel.

Priklad, ktory udavas popisuje 'zmiesany' prenos cez 128 a 1024 byteove bloky - toto asi potrebovat nebudes. Nepredpokladam, ze subor ktory chces posielat ma megabajty, takze myslim, ze bude jednoduchsie zostat pri 128 byteoch.
'CPMEOF[28]' znamena CP/M EOF t.j. znak konca riadku z prehistorickeho OS (^Z, hexa 1A) opakovany 28 krat, ako indikacia konca suboru a sucastne výplň posledneho bloku, v ktorom je (v priklade) 100 bajtov dat. CP/M mal totiz (kedysi) granularitu blokov 'diskovych zariadeni' fixne 128 byteov, a ano, XMODEM vznikal este vtedy ...
BTW ak ma Tvoj subor presne 128 bajtov (alebo 1024, ak sa rozhodnes pre velke bloky), alebo ich celociselny nasobok, tak pre istotu pridaj este jeden blok ktory bude mat v datach len jeden CPMEOF.

To, ze HT neskusi po 'C' poslat 'NAK' je mrzute, ale tak nejak ma to u MS neprekvapuje, ved ide len o zazity standard
Pre nas to znamena nutnost pouzit XMODEM-CRC, ale to je nakoniec len mierna komplikacia.

Kedze originalne RFC su asi zbytocne detailne a teda matuce, pozri PDF k appnote AVR350, strana 3 - je tam pekny priklad komunikacie, aj s popisom (a ziaden ASCII art, normalna tabulka).
Nanestastie, appnote pre 'XMODEM sender' asi neexistuje.

Este k nazvu suboru: pri vyssie popisanom sposobe ho posielat nebude ani S, ani R. Ako som pisal v minulom prispevku, moze ho posielat S ako sucast nulteho bloku (t.j. blok s indexom nula - inak zacnes od jedna), ale to uz je YMODEM; alebo mozes skusit stastie s MODEM7, ale na to by som u Mrkvosoftu nevsazal. Daj vediet ak by si to predsa len potreboval, rozsirenie na YMODEM by nemal byt principialny problem.

BTW pri implementacii Ti moze pomoct kniznicne CRC - vraj 'Optimized CRC-XMODEM calculation'.

[dxr]

Toto sa ti moze hodit.
http://sourceforge.net/projects/extraputty/
predsa len kym to vyladis hyperterminal je taky...... tazkopadny.

[jenda23]

Díky chlapi, takže počkam na příchod znaku C pak pošlu sekvenci o x krát 128 byte , 16bit CRC, poslední paket kdyby byl krátkej doplním do 128 byte CPMEOF symbolem (čili 1A) , a pak znak EOT (04) a přenos by měl bejt ukončen.

A až by toto fungovalo zkusil bych ten Ymodem.

[jenda23]

Ahoj, ještě dotaz, jak odeslat pořadí bloku? To je binární číslo? Takže když budu mít první paket UDR registr naplním hodnotou 1, nebo to je string takže ho naplním hodnotou 49 což odpovídá číslu 1 v podobě stringu? Stejně tak doplněk k tomu, to jsem nějak nepochopil.

[anonymousCoward]

Poradie bloku je reprezentovane binarnym cislom.
Kedze Ti netreba posielat zo S metadata o subore, poradove cislo prveho bloku je 1 t.j. hexa 1, binarne 00000001 - t.j. nie ASCII hodnota '1', co by zodpovedalo byte s hexa hodnotou 31.
Dalsi blok bude mat cislo 2 (ak Ti jeho prijem R potvrdi ACK-om, inak musis opakovat prenos takeho 'nepodareneho' bloku), dalsi 3 ... az po 255 - po tom 'pretecies' a dalsi blok bude mat cislo 0 (nie 1, ako na zaciatku prenosu!), po nom nasledujuci 1, potom 2 atd.
Toto je trosku nekonzistentne, ale c'est la vie.

Druhy byte posielany S v bloku je jednotkovy doplnok poradoveho cisla bloku. Jednotkovy doplnok je podobna prisera ako dvojkovy doplnok, len lahsi na vypocitanie - jednoducho znegujes bity daneho cisla:
Jednotkovy doplnok 1 (0b00000001) je 254 (0b11111110), doplnok 2 (0b00000010) je 253 (0b11111101) atd. Ak sa Ti nepaci bitova negacia, rovnaky vysledok dostanes, ak od 255 odpocitas cislo bloku. AVR ma na jednotkovy doplnok instrukciu COM za 1 takt, a tiez SUB na 1 takt .. takze je to asi jedno. Ak pises v C(++), mozes rovno pouzit operator bitovej negacie:

Kód: Vybrať všetko

uint8_t onesComplement = ~blockNumber;

.

Cize: prvy posielany byte zo S bude indikacia typu bloku - pre 128 bytove bloky to je ASCII znak oznacovany ako SOH (t.j. byte s hodnotou 1); az po nom posielas cislo bloku, potom jeho jednotkovy doplnok, dalej 128 byteov dat suboru a nakoniec 2 byte CRC z 128 byteov aktualne posielanych dat, v poradi big endian. Toto opakujes, kym mas data na posielanie.

Este Ta pre istotu opravim: koniec suboru musi byt (pre istotu) vzdy indikovany znakom EOF (hexa 1A), hocako je velky. A na uplny koniec prenosu posiela S len jeden ASCII znak EOT t.j. byte s hexa hodnotou 4.

// Edit: pocitanie s malymi celymi cislami, moja zahuba ...

[jenda23]

Zdárek, můj dotaz o číslování paketu byl vřešen hned, zase sem měl ruce rychlejší než hlavu takže jsem to vyzkoušel, pokusně sem zkoušel do souboru odesílat 128 krát písmeno "m". Mechám MCU čekat na písmeno C, v moment kdy spustim příjem souboru do PC mi terminál odešle písmeno C. V ten moment mi procesor odešle "SOH" znak, za ním binárně 1, pak binárně 254, po té s rozestupem 1ms krmim terminál písmenem "m", pak odešlu MSB 16bit CRC, LSB 16bit CRC a čekám na ACK od terminálu, ovšem žádného se nedočkám. Terminál sice paket akceptuje, ale do errorů vypíše že pakte je příliš krátný a nevyšle ACK. Zkoušel sem i 1024 prvků v bloku odeslat ale i přes to píše že je paket krátkej. V terminálu mám navolenej Xmodem, pak je tam ještě Xmodem-1k což je pro 1024 bajtů v paketu. Ale i tam je problém s krátkým paketem. Při čemž když si linku odposlechnu tak data z MCU do COM portu a potažmo i terminálu dojdou v pořádku přesně tak jak je odesílám. Nenapadlo mě nic co by mohlo bejt příčinou.

[anonymousCoward]

Z Tvojho popisu problem nevidim - ak sa da, priloz sem prosim relevantnu cast kodu.

[MiloPS3]

nema byt u "XMODEM 128 byte blocks" nahodou checksum ? misto crc
a u 1024 je to STX 01 FE Data[1024] CRC CRC

[jenda23]

V dokumentaci ej CRC, ale co je skutečnost nevím.