Atlantis
Guest
Tue Jan 12, 2016 6:17 pm
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.
Marek
Guest
Wed Jan 13, 2016 1:15 am
On Tue, 12 Jan 2016 18:17:43 +0100, Atlantis <marekw1986NOSPAM@wp.pl>
wrote:
Quote:
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.
Quote:
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
Pszemol
Guest
Thu Jan 14, 2016 3:19 am
"Atlantis" <marekw1986NOSPAM@wp.pl> wrote in message
news:5695353b$0$662$65785112@news.neostrada.pl...
Quote:
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.
Atlantis
Guest
Thu Jan 14, 2016 3:19 pm
W dniu 2016-01-14 o 03:19, Pszemol pisze:
Quote:
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?
Marek
Guest
Thu Jan 14, 2016 7:25 pm
On Thu, 14 Jan 2016 15:19:06 +0100, Atlantis <marekw1986NOSPAM@wp.pl>
wrote:
Quote:
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.
Quote:
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
J.F.
Guest
Thu Jan 14, 2016 8:14 pm
Użytkownik "Atlantis" napisał w wiadomości grup
dyskusyjnych:5697ae59$0$22822$65785112@news.neostrada.pl...
W dniu 2016-01-14 o 03:19, Pszemol pisze:
Quote:
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.
Quote:
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.
Marek
Guest
Thu Jan 14, 2016 8:51 pm
On Thu, 14 Jan 2016 20:14:57 +0100, "J.F."
<jfox_xnospamx@poczta.onet.pl> wrote:
Quote:
pisales wiec na swoim terminalu/komputerze np "xmodem send plik", to
Kolega pytał o recursive całej struktury a nie pojedynczych plików....
--
Marek
Atlantis
Guest
Fri Jan 15, 2016 12:06 am
W dniu 2016-01-14 o 19:25, Marek pisze:
Quote:
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.
Quote:
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.