On Thu, 14 Jan 2016 15:19:06 +0100, Atlantis <m...@w...pl>
wrote:
> Któryś z tych protokołów nadaje się do zintegrowania ze standardowym
> systemem komend ASCII (np. AT)? Chodzi o to, żeby standardowo
operacja
> transmisji była rozpoczynana przez jakąś komendę tekstową, kończącą
się
> np. \r. Dopiero po jej wywołaniu rozpoczynałaby się transmisja
kolejnych
> pakietów, zakończona powodzeniem, błędem albo timeoutem.

Dokładnie tak jest w Telitach. Teraz spojrzałem jak to się robiło.
Tam nawet nie było protokołem zmodem tylko ascii, wysyłało się
polecenie:
AT#WSCRIPT="nazwa_pliku",rozmiar_w_bajtach\r
pojawiał się prompt >>> i można było w terminalu wybrać "send file as
ascii" i poszło. Moduł przyjmował strumień danych o zadeklarowanej
długości do zadeklarowanej nazwy pliku.
Akurat w tym przypadku przesyłało się tekstowy skrypt w pythonie ale
nie przeszkafza aby wysłać plik binarny, długość jego przecież
deklarujesz.

> Któryś z protokołów standardowo wspiera przesyłanie informacji o
> strukturze katalogów i transmisję w dwie strony, tak aby możliwe
było
> wykonywanie operacji kopiowania w stylu Windows Commandera?

Hmm nie kojarzę, bo większość tych protokołów jest end-to-end gdzie
strony komunikacji podają sobie tylko nazwę pliku. Zmodem miał coś
takiego jak dont strip path ale to chyba działało tylko wtedy gdy po
drugiej stronie była już struktura katalogów określona w path.

Moim zdaniem kombinujesz. Jeśli "w mcu" mają znalezc się pliki (dane)
albo z niego trzeba je pobrać to eleganckim rozwiązaniem jest
udawanie pendrive.
Tylko ciężko jest zrobić system fat o rozmiarze rzędu kilobajtów
(limituje rozmiar flash mcu), mi używając mkfs.msdos udało się
minimalizując opcje zejść do fs size ok 38kB.

--
Marek