Elektroda.pl
Elektroda.pl
X
Elektroda.pl
Computer Controls
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Emulator pendrive'a przez ethernet

dominus 10 Lis 2010 23:33 3641 12
  • #1 10 Lis 2010 23:33
    dominus
    Poziom 11  

    Witam szanownych forumowiczów. Przyszedł mi do głowy pewien pomysł. Posiadam kino domowe, które ma możliwość odczytu plików z zewnętrznej pamięci USB (pendrive, dysk - ogólnie Mass Storage). Byłoby miło, gdyby dało się połączyć w jakiś sposób kino z komputerem, na którym znajdują się pliki a/v. W pobliżu znajduje się router ASUS z linuxem, który ma gniazda USB, stąd pierwsza myśl - połączenie kablem USB. Jako że wcześniej nie miałem okazji łączyć kompów przez USB, rozczarowałem się, że te kabelki potrzebują wydumanych sterowników po obu stronach i tu klops, bo kino daje sobie radę tylko z Mass Storage :(. Pomyślałem - skoro nie ma takich kabelków, to zrobię sobie sam! I tu kolejny zonk, bo poszukiwania mikrokontrolerów z dwoma USB device'ami się nie powiodło. Ale mnie olśniło, że może są kontrolery z USB device oraz z ethernetem. I tu pozytywne zaskoczenie - są i nawet można je dostać :) Tyle, ze mamy sporą różnorodność AVR, LPC, ST, MICROCHIP...
    Ogólna idea jest taka: kino wysyła komendy do usb mikrokontrolera, ten przesyła je przez ethernet do komputera w sieci, na którym uruchomiony jest program-serwer obsługujący zapytania i odsyłający odpowiedzi do kina. Idea prosta, tylko potrzebuję podpowiedzi, jaki mikrokontroler wybrać... Po przejrzeniu oferty osobiście skłaniam się do 32-bitowców Microchipa PIC32MX6 albo 7. Są narzędzia (w wersji testowej co prawda, ale nie przesadnie ograniczonej), są gotowe przykłady do obsługi USB i ethernetu. Na oko wystarczyłyby drobne przeróbki. Do tego można zawalczyć o sample od producenta. Minus to obudowa TQFP, ale przecież są płytki przejściówki. Potrzebuję pomocy w upewnieniu się bądź odradzeniu tego pomysłu. No i jeszcze kwestia programatora - nie posiadam żadnego do PICów. Tu też mam pytanie. W datasheetach piszą, że można to zaprogramować PICKITEM. Żeby go zrobić, też trzeba czymś zaprogramować PICa, więc lipa :). Ale na ebayu można dostać PICKIT3 w granicach 150 PLN, są też tańsze chińskie podróbki, o których czytałem, że "nie bardzo chcą współpracować". Te "nie chińskie" wyglądają jak oryginały, więc byłbym w stanie zainwestować na przyszłość.
    To jeszcze raz seria pytań:
    1. Czy PIC32MX6/7 to dobry wybór - czy ktoś z tym już pracował, jakie wrażenia?
    2. Co z tym PICKITEM3 - czy to co na ebayu jest warte zakupu (nie mam ochoty walczyć ze stworzeniem programatora, wolę, żeby chociaż on był pewny), ktoś tego używał?
    3. A może macie jakieś inne pomysły na podłączenie kina do sieci? W pobliżu jest router z USB i linuxem.
    Z góry dzięki za zainteresowanie

    0 12
  • Computer Controls
  • #2 11 Lis 2010 00:34
    buh
    Poziom 22  

    Jeśli dobrze zrozumiałem to komputer ma być widziany przez kino domowe jako pamięć masowa?

    Jeśli tak, to nie będzie to raczej proste zadanie. Jeśli dobrze pamiętam to Linux posiadał taką możliwość pod warunkiem, że kontroler USB w komputerze mógł zostać przełączony w tryb slave. Z tego co wiem firma FTDI ma w swojej ofercie kontrolery master/slave USB. Warto się zainteresować.

    Można też spróbować z kablem USB do łączenia 2 komputerów. Tam jest chyba właśnie taki kontroler master/slave, który automatycznie przełącza. Ale do tego trzeba też oprogramowanie.

    0
  • Computer Controls
  • #3 11 Lis 2010 01:52
    dominus
    Poziom 11  

    Dokładnie tak - komputer ma udawać pendrive'a. Tylko że ze względu na odległość nie ma możliwości połączenia bezpośredniego. Kino przez USB musi być połączone z routerem. Albo przez USB albo ethernetem.
    Zerkałem na te FTDI, ale minus jest taki, że potrzebowałbym dwa takie układy plus jakiś mikrokontroler i to wszystko musiałoby działać z sensowną prędkością przesyłanych danych, a tu wąskie gardła są dwa - na styku FTDI<->mikrokontroler. Ewentualnie mają chyba taie kontrolery z dwoma USB, jednak problemem wydaje mi się napisanie sterownika USB (właściwie dwóch - jeden na ftdi, drugi na linucha na routerze). Co prawda na linuxie chyba łatwiej, ale nie wiem, jak obciążenie routera procesem sterownika USB wpłynęłoby na jego pracę. W końcu ten sterownik musiałby udawać FAT32. No i tu kolejne problemy, bo router musiałby mieć dostęp do zawartości dysku kompa, czyli jak nie jakiś FTP to SAMBA...
    Dlatego rozwiązanie typu mikrokontroler z USB i ethernetem wydał mi się najlepszy. Mimo, że kontroler właściwie nie będzie obciążony pracą, to połączenie przez ethernet daje dużo większe możliwości - program serwerowy może stanąć na dowolnym sprzęcie (windows, linux) podpiętym do netu - kwestia napisania softu udającego FAT32 to już raczej nie kłopot.
    Tylko czy bazę w postaci mikrokontrolera z rodziny PIC wybrałem sobie dobrą?...

    0
  • #4 11 Lis 2010 11:27
    nsvinc
    Poziom 35  

    Temat jest trywialny.
    Jesli postawisz sobie na PC serwer FTP, i przez FTP bedziesz udostepniac pliki na siec, wystarczy ci JEDEN procesor, w ktorym jest USB dev i Eth. Przykladem takiego procka to STM32F107xxxx. Na to zadanie potrzeba ci okolo 64k flash (z duzym zapasem!) i 32k ramu, czyli wystarczy maly procek.

    USB tego procesora wpinasz w hosta kina domowego. Eth procesora podlaczasz do sieci, w ktorej jest twoj PC.
    Procesor ma zaimplementowana klase USB mass storage, stos TCP/IP i obsluge File Transfer Protocol po TCP.

    I wtedy np. gdy host usb chce odczytac jakies pliki z katalogu biezacego, ty wysylasz na FTP rozkaz LIST, czekasz na odpowiedzi (a wraca lista plikow w ascii!) a nastepnie zamieniasz tekst na format zdefiniowany w klasie Mass Storage, i przesylasz do hosta USB...No tak w skrocie.
    Reszta funkcjonalnosci bedzie zaimplementowana analogicznie.

    Za nic w swiecie nie pchalbym sie w FTDI czy inne konwertery. Kazdy posredni scalak to w twoim przypadku spadek wydajnosci lacza.

    Nie rozumiem problemu podlaczenia tego "miendzymordzia" (interfejsu :P ) do routera. Przeciez to wszystko jedno dokad podlaczysz kabel sieciowy, czy do PC, czy do routera, czy do WAN, jak juz uda ci sie translacja USB <-> Eth.
    Przeciez korzystajac z IP (co jest tu przymusem) masz do dyspozycji dowolne konfiguracje sieci.

    Caly ten pomysl przejdzie tylko wtedy, jesli twoj router obsluguje loopback. Jesli nie, lokalny klient FTP nie bedzie widzial lokalnego serwera FTP, w efekcie czego serwer FTP musialby miec WAN IP, i to inny, niz router.
    Druga mozliwosc jest uzycie static routing, ale to tez nie wszedzie i nie zawsze :]

    Jesli odpada FTP, mozesz zawsze napisac w np. takim C# wlasny serwer. Nie ma koniecznosci pisania zadnych sterownikow. Wtedy protokol kapsulkowany w TCP definiujesz juz sam, port polaczenia tez. Mozna isc dalej, i z TCP ogolnie zrezygnowac, wykorzystac tylko IP, a reszta to implementacja dowolna. Wtedy dobrze definiujac protokol, zyskasz pare bitow na dane (bo uwalamy sporo naglowka, naglowek TCP + FTP to spoooro), a dodatkowo, mozesz wlasny protokol zoptymalizowac pod katem implementacji w mikrokontroler. No i odpada problem braku loopback-a w routerze.

    1
  • #5 11 Lis 2010 12:52
    dominus
    Poziom 11  

    nsvinc napisał:

    Temat jest trywialny.

    He he he - pewnie tak, tylko nie miałem jeszcze do czynienia z prockami z takimi peryferiami, a oferta jakaś jest...

    nsvinc napisał:

    Za nic w swiecie nie pchalbym sie w FTDI czy inne konwertery. Kazdy posredni scalak to w twoim przypadku spadek wydajnosci lacza.

    Do takich samych wniosków doszedłem wyżej :)

    nsvinc napisał:

    Nie rozumiem problemu podlaczenia tego "miendzymordzia" (interfejsu :P ) do routera.

    Problem był wtedy, kiedy chciałem zrobić sprzęg za pomocą procka z dwoma portami USB podłączonymi do kina oraz do routera - wtedy musiałbym pisać stery na router, które poprzez sieć dogadywałyby się z kompem.

    nsvinc napisał:

    Caly ten pomysl przejdzie tylko wtedy, jesli ...

    Jeśli to będzie sprzęg pomiędzy USB a ethernetem (a na 100% będzie :) ) to problem oprogramowania odpada, bo serwer będzie stał gdziekolwiek i to na pewno nie będzie FTP, tylko coś własnego, bo z tego co wiem, MASS STORAGE nie śmiga na warstwie podawania nazw plików, tylko poprzez przesył odpowiednich sektorów z pendrive'a/dysku USB. Wykorzystanie FTP na mokrokontrolerze wydaje się w tej sytuacji bezcelowe - muszę zbudować "wirtualny FAT", a tego już kontrolerowi nie powierzę, bo sama tablica FAT to ponad 2MB.

    Wszystko, co napisałeś zgadza się z moimi przemyśleniami. Prosiłbym raczej o weryfikację wyboru kontrolera. Jak pisałem wyżej podobają mi się te PICe, ale sprawdzę jeszcze tego wspomnianego przez Ciebie STM (jak z programowaniem itp.)

    0
  • #6 11 Lis 2010 14:48
    Samuraj
    Poziom 35  

    Pomysł ciekawy, można by wykorzystać jeszcze zamiast serwera FTP, lub własnej aplikacji udostępnianie plików przez otoczenie sieciowe, w tym przypadku nie musimy instalować żadnej aplikacji na hoście.
    Każdy komputer w otoczeniu byłby widziany jako katalog.
    Tylko co z wydajnością takich małych mikrokontrolerów ?
    Trzeba by sprawdzić jaką przepustowość wymagają takie zabiegi.

    0
  • #7 11 Lis 2010 15:10
    dominus
    Poziom 11  

    Samuraj napisał:

    Pomysł ciekawy, można by wykorzystać jeszcze zamiast serwera FTP, lub własnej aplikacji udostępnianie plików przez otoczenie sieciowe, w tym przypadku nie musimy instalować żadnej aplikacji na hoście.
    Każdy komputer w otoczeniu byłby widziany jako katalog.


    Tak, tylko że przenosi ciężar na napisanie na kontroler softu wirtualnego FATa, a jak pisałem wcześniej średnio mi się to podoba... Wolałbym załatwić to poprzez soft na kompie - wtedy na takim serwerze mógłbym "podpinać" katalogi udostępnione w sieci. Wiem, że takie rozwiązanie jest trochę mniej uniwersalne, ale budowanie FAT na kontrolerze na podstawie zawartości katalogów dostępnych w sieci wydaje mi się karkołomne - tablica FAT musi powstać na samym początku ("przed wpięciem USB do kina"), a znając problemy otoczenia sieciowego, zebranie informacji ze wszystkich kompów w sieci w sensownym czasie jest niemożliwe :(

    Kolega nsvinc pozytywnie mnie zapłodnił tym STM32 - to już ARM, hmm... Może jednak ARM, pozostaje kwestia programatora/debuggera i środowiska/bibliotek...

    0
  • #8 11 Lis 2010 15:43
    Samuraj
    Poziom 35  

    Dlaczego chcesz tworzyć fat'a na samym początku ?
    Nie łatwiej w locie ?
    Odczytujesz katalog i już masz zawartość, zmieniasz ścieżkę w kinie domowym, zmieniasz ścieżkę dostępu i znowu tworzysz tablicę fat.

    0
  • #9 11 Lis 2010 16:08
    dominus
    Poziom 11  

    Wszystko zależy od tego, jak zorganizowany jest dostęp do dysku od strony kina. Przez USB na 100% lecą żądania odczytu odpowiednich sektorów. Jeśli projektanci kina założyli (całkiem słusznie), że nie ma konkurencyjnego dostępu do danych znajdujących się na penie, to (z punktu widzenia kina) tablicę FATowską można sczytać raz na początku i ją sobie przechowywać nie żądając odczytu tej tablicy przy przeskoku z klastra na klaster. Sama zmiana katalogów nie byłaby już tak kłopotliwa, bo rzeczywiście w pierwszej chwili czytany będzie katalog główny. Jednak przy wejściu przez kino do podkatalogu po USB poleci żądanie odczytu jakiegoś konkretnego klastra. I tu kłopot, bo informacje o umiejscowieniu podkatalogów są w tablicy FAT (nr klastra z opisem podkatalogu - katalog to też plik)... Gdyby twórcy oprogramowania na kino zakładali, że tablica FAT może się zmieniać, to musieliby ją odczytywać za każdym razem, gdy zmieniałby się klaster, a to jest bez sensu. Klaster może mieć np 4kiB a tablica FAT 2MiB... Dlatego uważam, że tablicę FAT (oraz strukturę katalogów) należy stworzyć na samym początku, a potem w trakcie żądań kina, analizować obszary, które mają być wysłane i przesyłać fragmenty odpowiednich plików.

    0
  • #10 02 Kwi 2012 08:01
    mathaus
    Poziom 11  

    Witam
    Chciałem zapytać jak się udało rozwiązać ten problem?
    dominus jeśli możesz to napisz jeszcze kilka słów na ten temat :-)

    PS: ja dodam tylko że udało mi się znaleźć taki soft:
    Link
    ale nie testowałem....

    a co do pomysłu nsvinc to przypomina to: Link

    0
  • #11 04 Kwi 2012 00:37
    dominus
    Poziom 11  

    Idea umarła śmiercią naturalną :). Zająłem się innymi rzeczami i...
    Soft ciekawy, tylko nie wiem, czy ruszyłby w miarę bezproblemowo na routerze. Co do emulatora pendrive'a, to powiem, że koszmarne pieniądze za taki sprzęt - na dodatek nie wiadomo jaką to ma pojemność. I samo to jest problemem. Jeśli to jest fizycznie pendrive, to pojemność ma ograniczoną do kilku(dziesięciu) GiB. I za każdym razem, kiedy miałbym nowy film, to musiałbym go na tego pena wrzucać - czy to przez ethernet, czy fizycznie przez USB. Ja z założenia chciałem zrobić urządzenie, które byłoby na stałe wpięte do kina i do eth, a na kompie byłby soft (raz skonfigurowany), który by załatwiał wszystko. No i pozostaje problem zmiany zawartości pamięci, czego raczej producent kina się nie spodziewał, więc podejrzewam, że jeśli w czasie oglądania filmu wrzuciłbym coś dodatkowego do tego emulatora, to kino by tego nie widziało - uważam, że kino czyta tablicę FAT raz przy montowaniu pendrive'a, bo nie spodziewa się, że w jakiś cudowny sposób zawartość pamięci może się zmienić w trakcie.
    Na dzień dzisiejszy mogę powiedzieć, że gdybym miał to zbudować, to rzeczywiście zdecydowałbym się na STM, ale teraz czekam na raspberry Pi, które za duuużo mniejsze pieniądze ma duuużo większe możliwości - i to bez kombinacji. Chociaż w celach edukacyjnym może sobie to kiedyś zbuduję :D

    0
  • #13 07 Maj 2012 20:40
    prosiak22
    Poziom 22  

    Są już routery z serwerami DLNa i nie są drogie.
    No tylko chyba albo telewizor musi mieć obsługę DLNa albo DVD.

    0