Pamiętam stare czasy, kiedy wymieniając pliki między komputerami łączyło
się je za pomocą kabla LPT albo null-modem. W menedżerach plików pokroju
Norton Commandera była odpowiednia opcja, która pozwoliła się podłączyć
do drugiego urządzenia i przerzucić pliki.

Tak sobie pomyślałem, że podobną metodę można by zastosować w projektach
z mikrokontrolerami. Jeśli na przykład mam projekt z wewnętrznym flashem
AT45DBxx, na którym postawię system plików za pomocą FatFS, to czy
byłoby możliwe przerzucanie plików za pomocą jakiegoś standardowego
protokołu (bez konieczności pisania własnego softu po stronie PC) przez
UART?

Zdaje sobie sprawę z tego, że można zastosować kartę pamięci
(rozwiązanie najłatwiejsze) albo MCU z funkcją klienta USB, co
pozwoliłoby na zrobienie z niego "pendrive'a". To pierwsze rozwiązanie
rzecz jasna już wykorzystywałem, a to drugie jest jednak dość istotną
komplikacją - sama biblioteka do obsługi stosu USB zużyje sporo zasobów.

do góry

On Tue, 12 Jan 2016 18:17:43 +0100, Atlantis <m...@w...pl>
wrote:
> Tak sobie pomyślałem, że podobną metodę można by zastosować w
projektach
> z mikrokontrolerami. Jeśli na przykład mam projekt z wewnętrznym
flashem
> AT45DBxx, na którym postawię system plików za pomocą FatFS, to czy
> byłoby możliwe przerzucanie plików za pomocą jakiegoś standardowego
> protokołu (bez konieczności pisania własnego softu po stronie PC)
przez
> UART?


Można użyć np. Kermita. Jest kilka protokołow transferu plików po
łączu szeregowym. Do modułów gsm Telita tak można wgrywać pliki przez
uart.

> komplikacją - sama biblioteka do obsługi stosu USB zużyje sporo
zasobów.

Dlaczego? ~10kB flash to dużo?
Jeśli mcu ma mieć dostęp do fsa, który sam udaje jako pendrive, można
użyć petitfat zamiast fatfs.

--
Marek

do góry

"Atlantis" <m...@w...pl> wrote in message
news:5695353b$0$662$65785112@news.neostrada.pl...
> Pamiętam stare czasy, kiedy wymieniając pliki między komputerami łączyło
> się je za pomocą kabla LPT albo null-modem. W menedżerach plików pokroju
> Norton Commandera była odpowiednia opcja, która pozwoliła się podłączyć
> do drugiego urządzenia i przerzucić pliki.
>
> Tak sobie pomyślałem, że podobną metodę można by zastosować w projektach
> z mikrokontrolerami. Jeśli na przykład mam projekt z wewnętrznym flashem
> AT45DBxx, na którym postawię system plików za pomocą FatFS, to czy
> byłoby możliwe przerzucanie plików za pomocą jakiegoś standardowego
> protokołu (bez konieczności pisania własnego softu po stronie PC) przez
> UART?

Poczytaj o starych technologiach typu protokoły x-modem, z-modem itp.
Większość programów terminali znakowych na peceta, włącznie ze
sławnym Hyper Terminalem obsługuje taką wymianę plików.

do góry

W dniu 2016-01-14 o 03:19, Pszemol pisze:

> Poczytaj o starych technologiach typu protokoły x-modem, z-modem itp.
> Większość programów terminali znakowych na peceta, włącznie ze
> sławnym Hyper Terminalem obsługuje taką wymianę plików.

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.

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?

do góry

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

do góry

Użytkownik "Atlantis" napisał w wiadomości grup
dyskusyjnych:5697ae59$0$22822$6...@n...neostrad
a.pl...
W dniu 2016-01-14 o 03:19, Pszemol pisze:
>> Poczytaj o starych technologiach typu protokoły x-modem, z-modem
>> itp.
>> Większość programów terminali znakowych na peceta, włącznie ze
>> sławnym Hyper Terminalem obsługuje taką wymianę plików.

>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.

poniekad wszystkie/wiekszosc.
Jesli laczyles sie z jakims terminalowym systemem (unix itp), to
trzeba bylo na zdalnym systemie uruchomic program wysylajacy,
odbierajacy lub zarzadzajcy.

pisales wiec na swoim terminalu/komputerze np "xmodem send plik", to
sie wykonywalo na zdalnym komputerze, wypisywalo "uruchom program
odbiorczy na terminalu", uruchamiales (jesli pecet to zwykle jakis
klawisz funkcyjny), ten wyslal znaczek mowiacy "jestem gotowy do
odbioru" i zdalny wysylal.

Albo pisales np "rz" (receive Zmodem), ten wypisywal "teraz mozesz
wyslac plik", wiec startowales wysylanie.

Ciekawy byl Kermit - ale zdazyl sie tak rozbudowac, ze nie wiem czy
znajdziesz jakas prosta implementacje.

>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?

O ile pamietam to w Kermicie byly podobne funkcje, ale zdecydowanie
nie w stylu NC.
no chyba, ze w tym jakas ladna prezentacje zrobili
http://www.columbia.edu/kermit/k95.html

J.

do góry

On Thu, 14 Jan 2016 20:14:57 +0100, "J.F."
<j...@p...onet.pl> wrote:
> pisales wiec na swoim terminalu/komputerze np "xmodem send plik", to

Kolega pytał o recursive całej struktury a nie pojedynczych plików....

--
Marek

do góry

W dniu 2016-01-14 o 19:25, Marek pisze:

> 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.

Coś takiego już kiedyś robiłem. Tyle tylko, że w tamtym projekcie nie
było systemu plików, a zawartość jednego większego pliku (próbki PCM)
była ładowana do "surowej" pamięci AT45DBxx. Program po przyjęciu
odpowiedniej komendy zmieniał tryb pracy UART-a w taki sposób, że
zamiast oczekiwać na komendy ładował on każdy przychodzący bajt do
bufora, a gdy uzbierała się z tego pełna strona zapisywał ją we flashu.

Teraz jednak przydałoby mi się coś, co pozwoli nie tylko wrzucić plik do
pamięci, ale także go stamtąd wyciągnąć, najlepiej przy pomocy jakiegoś
standardowego oprogramowania, bez potrzeby pisana własnego softu na PC.
Już nawet mogę zrezygnować z przeglądania systemu katalogów - niechby i
był tylko jeden katalog główny, do którego byłyby wrzucane pliki i z
którego można by wyciągnąć plik o konkretnej nazwie.


> 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.

Miałem na myśli pamięć flash podłączaną przez SPI, np. AT45DB, gdzie do
zagospodarowana mogę mieć nawet kilka MB. Wiem, że można użyć karty SD
albo USB MSD, ale w tym wypadku zależy mi na tym, żeby usunięcie nośnika
w trakcie pracy urządzenia było fizycznie niemożliwe.
A kwestię montowania urządzenia jako PD na PC na razie pominąłem z
prostej przyczyny - teoretycznie zastanawia mnie implementacja takiego
rozwiązania w jednym ze starszych projektów na AVR, który nie ma w ogóle
interfejsu USB.

do góry