VNC1L z firmware VDPS

Dyskusje ogólne na temat "cyfrówki" czyli wszystko o TTL/CMOS, językach VHDL i VERILOG, bramkach, rejestrach, przerzutnikach... Dobre miejsce na pytania odnośnie uniwersalnych programatorów (np. Willem) a także podłączania własnych peryferiów do komputera PC.
ODPOWIEDZ
Awatar użytkownika
c4v2
Użytkownik
Posty: 427
Rejestracja: 22 lis 2005, 15:14
Lokalizacja: z przed monitora

VNC1L z firmware VDPS

Post autor: c4v2 » 31 sie 2010, 19:09

Dzień dobry-wieczór
Czy ktoś z Szanownych Forumowiczów (Forumowiczek) zajmował się układem VNC1L.
Hodzi mi dokładnie o firmware VDPS. Z tego co wyczytałem to z tym oprogramowaniem do portu USB2 (HOST) można podłączać miedzy innymi pamięci USB (BOMS). Port ten pełni również rolę HUBA'a.
Natomiast port USB1 jest skonfigurowany jako (SLAVE) i jest przeznaczony do komunikacji z PC (HOST).
W komputerze układ VNC1L jest widoczny jako użądzenie FT232R?
Czy Dołączona do portu USB2 pamięć jest widoczna w komputerze PC jako dysk?
Czyli Komputer PC widzi niejako dwa urządzenia?
Czy z mikrokontrolera będę miał dostęp do USB1(SLAVE) i USB2 (HOST-HUB)?
Czy też Komunikacja komputera PC z pamięcią USB jest tylko poprzez widoczne w menadżerze urządzeń użądzenie FT232R?
Zaznaczam że chodzi mi tylko o firmware VDPS.
Działanie VDAP, VDIF jest dla mnie jak najbardziej jasne.
Załączniki
VDPS.gif
(15.06 KiB) Pobrany 363 razy

Passage
Użytkownik
Posty: 187
Rejestracja: 16 sie 2005, 22:46
Lokalizacja: Cambridge / UK
Kontakt:

Re: VNC1L z firmware VDPS

Post autor: Passage » 31 sie 2010, 20:00

c4v2 pisze: Czy Dołączona do portu USB2 pamięć jest widoczna w komputerze PC jako dysk?
Czyli Komputer PC widzi niejako dwa urządzenia?
Nie

W komputerze bedziesz mial jedynie sterownik FT232R, natomiast jesli chodzi o pamięc USB to uklad VNC1 ma implementację stosu Mass Storage, wiec niejako implementuje oblsuge systemu plikow, do ktorego masz dostep wygodnymi komendami typu:
DIR(listowanie bierzacego katalogu), CD(zmiana katalogu), OPR(otwarcie pliku) itd.

zresztą w dokumentacji jest to jasno opisane,
pozdrawiam.

Awatar użytkownika
c4v2
Użytkownik
Posty: 427
Rejestracja: 22 lis 2005, 15:14
Lokalizacja: z przed monitora

Post autor: c4v2 » 31 sie 2010, 20:43

Dziękuję.
Czyli firmware VDPS działa tak samo jak VDAP, z tą różnicą że nie trzeba dołączać zewnętrznego układu FT323RL a port USB1 w VNC1L pracuje jako SLAVE?

[ Dodano: 2010-09-01, 14:17 ]
Ograniczenia magistrali USB niestety nie pozwalają na to aby Pamięć MSD była widoczna jednocześnie przez mikrokontroler i komputer PC (niedopuszczalne dwa Hosty w jednym połączeniu). Można by było przełączać pamięć między mikrokontrolerem a PC z mikrokontrolera. Niestety nie ma co marzyć o wielodostępie.
Chyba prościej jednak ręcznie przełączać pamięć MSD. Pamięć przenośna, w końcu do tego jest...
Może w przyszłości jacyś konstruktorzy programiści zgrabnie rozwiążą problem.
Załączniki
USB_HOST_IDEA.png
USB_HOST_IDEA.png (7.61 KiB) Przejrzano 8634 razy

Awatar użytkownika
c4v2
Użytkownik
Posty: 427
Rejestracja: 22 lis 2005, 15:14
Lokalizacja: z przed monitora

Post autor: c4v2 » 18 paź 2013, 13:33

Po dłuższym czasie odświeżam temat.
Moduł hosta VNC1L-1A z oprogramowaniem VDPS (VDPSFUL_V03_68.ROM ze zmodyfikowanymi startowymi parametrami, między innymi prędkość transmisji z 9600 na 115200) połączony z USART mikrokontrolera działa poprawnie w obu trybach tj. komend, danych. Jeżeli moduł jest w trybie komend ( linie DSR#DATAREQ#, DTR#DATAACK# są w stanie H, ) moduł pracuje zgodnie z oczekiwaniami, czyli wykonuje komendy 'CD$0D', 'DIR$0D' itp. Po przejściu w tryb danych ( linie DSR#DATAREQ#, DTR#DATAACK# są w stanie L) możliwe jest nawiązanie komunikacji z komputerem PC (wirtualny port szeregowy jak w przypadku FT232). Nie ma różnicy czy wykonana zostanie komenda 'CS S$0D' przed przełączeniem linii DSR#DATAREQ# do stanu L czy tylko zostanie przełączona linia DSR#DATAREQ# do stanu L z odczekaniem na stan L na linii DTR#DATAACK#, moduł przechodzi poprawnie w tryb danych. Wszystko jest w porządku dopóki aplikacja terminalu w komputerze PC odbiera dane. Jeżeli w trybie danych zostały wysłane jakieś dane i PC ich nie odebrał to po przejściu do trybu komend czy to przez ustawienie linii DSR#DATAREQ# w stan H, czy przez odłączenie wtyczki z gniazda USB PC'ta, host „zachowuje się nieelegancko”. Dane te nie są tracone, a są interpretowane przez host w trybie komend (!), co kończy się zwykle zwrotem komunikatu o wystąpieniu błędu jeżeli ostatnim bajtem był kod $0D, ewentualnie oczekiwaniem hosta do czasu odebrania kodu $0D i zwróceniem błędu . Samo wykrywanie podłączenia do PC nie wystarcza ponieważ jest realizowane przez wykrywanie napięcia VBUS z USB PC'ta (dzielnik napięcia dołączony do BD.7). Wykonanie komendy 'QSS$0D' faktycznie zwróci informację o pojawieniu się napięcia VBUS (fizyczne podłączenie wtyku do gniazda USB PC'ta) oraz o danych oczekujących (z PC'ta) na odebranie, jeżeli takowe są. Brak napięcia VBUS odzwierciedlane jest też wymuszeniem stanu H na linii DTR#DATAACK#, i automatycznym przejściem modułu w tryb komend. Wygląda na to że rozwiązaniem problemu z przesyłaniem „niechcianych danych” jest programowe sprawdzanie uruchomienia, zamknięcia aplikacji terminalu na PC przez wysłanie omówionych znaków po uruchomieniu i przed zamknięciem aplikacji terminalu oraz na niedopuszczaniu na wysyłanie danych w trybie danych gdy aplikacja terminalu na PC nie jest uruchomiona. Coś takiego działa ale jest „nieco karkołomne”. Czy jest to jedyna metoda na ominięcie problemu „niechcianego buforowania danych”? Czy Ktoś z Szanownych Forumowiczów spotkał się z tego typu problemem? Dodam jeszcze że pomimo ustawienia braku kontroli przepływu (zmodyfikowany w firmware parametr startowy) to linie CTS# RTS# muszą być zwarte w celu uzyskania poprawnej transmisji host-mikrokontroler.

ODPOWIEDZ