FTDI 232BM problem
Masz problem? Zapytaj na forum elektroda.pl
From: "marek W" <dobromilek1_at_nospam_wp.pl>
Subject: FTDI 232BM problem
Date: Thu, 22 May 2003 22:12:51 +0200
Mam nastepujacy problem. Posiadam urzadzenie cos w rodzaju mikrokontolera
ktory jest umieszczony na plytce z roznymi elementami peryferyjnymi. Do tej
pory komunikowalem sie z nim za pomoca RS232. Protokol komunikacji wygladal
nastepujaco:
PC====>Urzadzenie
<wyslij rozkaz zapisu> 8bitow
<wyslij znak> 11bitow (1 bit staru, 8bitow danych,2 bity stopu)
Po wyslaniu rozkazu zapisu urzadzenie czeka na 1 bajt danych
Urzadzenie====>PC
<wyslij rozkaz odczytu> 8bitow
<wyslij znak> 11bitow (1 bit staru, 8bitow danych,2 bity stopu)
Po wyslaniu rozkazu odczytu urzadzenie w odpowiedzi wysyla 1 bajt danych
Urzadzemnie pracowalo z predkoscia 115.2kb/s. musialem to przerobic by
dzialalo pod USB wiec dostawilem konwerter USB<==>Rs232 zrobiny na FT232BM.
Napisalem funkcje otwierajace port, wysylajace i odbierajace 1 znak przy
wykorzystaniu biblioteki D2xx i FT_W32_API. Jednak to wszystko dziala
topornie i starasznie wolno. By przeslac 40kbajtow programu (ok. 80kbajtow z
rozkazami zapisu o odczytu) zajmuje jakies 30s. Przy wykorzystaniu Rs232
zajmowalo to jakies 5s. To samo sie tyczy sciagania wynikow pomiarow z
urzadzenia. Doczytalem sie scalak Ft232Bm ma time out konfigurowalny
1ms-255ms. Nastawilem mu 1ms (wykorzystalem funkcje FT_SetLatencyTimer( ) )
co przyspieszylo dzialanie z 50s do 30 s jednak to wciaz za duzo. Wiem ze
dane wysylane z PC sa buforowane w tym scalaku i aby scalak je przesla dalej
musi byc ich 64bajty lub minac okreslony czas (1ms-255ms).
Czy da sie cos zrobic z tym by czas przesylania z mniejszyc bez zmiany
protokolu transmisji na buforowany (urzadzenie ma Uart bez FIFO)?
Do czego dokladnie sluzy funkcja FT_USBParameters( ) czy do ustawiana
wielkosci pakietu?
========
Path: news-archive.icm.edu.pl!agh.edu.pl!news.agh.edu.pl!news.onet.pl!newsfeed.gazeta.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai
From: "Jerzy Szczesiul" <jerzy.szczesiul_at_nospam_ep.com.pl>
Subject: Re: FTDI 232BM problem
Date: Thu, 22 May 2003 22:50:31 +0200
Czesc
<wyslij rozkaz zapisu> 8bitow
<wyslij znak> 11bitow (1 bit staru, 8bitow danych,2 bity stopu)
Po wyslaniu rozkazu zapisu urzadzenie czeka na 1 bajt danych
Urzadzenie====>PC
<wyslij rozkaz odczytu> 8bitow
<wyslij znak> 11bitow (1 bit staru, 8bitow danych,2 bity stopu)
Po wyslaniu rozkazu odczytu urzadzenie w odpowiedzi wysyla 1 bajt danych
Napisalem funkcje otwierajace port, wysylajace i odbierajace 1 znak przy
wykorzystaniu biblioteki D2xx i FT_W32_API. Jednak to wszystko dziala
topornie i starasznie wolno. By przeslac 40kbajtow programu (ok. 80kbajtow
z
rozkazami zapisu o odczytu) zajmuje jakies 30s.
Niestety wybrales protokol zupelnie nie pasujacy do usb. Przesylanie
pojedynczych bajtow oddzielnymi transferami to najgorsza
z mozliwosci. Magistrala realizuje tylko jeden transfer w 1 ms ramce
- i juz masz przyczyne : 1ms * 1 kB = ok 1s.
Zadne ustawienia Ft tego nie zmienia - dane musza byc przesylane
wiekszymi pakietami.
--
Pozdrowienia
Jurek Szczesiul
========
Path: news-archive.icm.edu.pl!agh.edu.pl!news.agh.edu.pl!news.onet.pl!not-for-mai
From: "Tomasz Sawicki" <kotburak_at_nospam_poczta.onet.pl>
Subject: Re: FTDI 232BM problem
Date: Fri, 23 May 2003 23:28:40 +0200
<wyslij rozkaz zapisu> 8bitow
<wyslij znak> 11bitow (1 bit staru, 8bitow danych,2 bity stopu)
Po wyslaniu rozkazu zapisu urzadzenie czeka na 1 bajt danych
Urzadzenie====>PC
<wyslij rozkaz odczytu> 8bitow
<wyslij znak> 11bitow (1 bit staru, 8bitow danych,2 bity stopu)
Po wyslaniu rozkazu odczytu urzadzenie w odpowiedzi wysyla 1 bajt danych
Napisalem funkcje otwierajace port, wysylajace i odbierajace 1 znak przy
wykorzystaniu biblioteki D2xx i FT_W32_API. Jednak to wszystko dziala
topornie i starasznie wolno. By przeslac 40kbajtow programu (ok.
80kbajtow
z
rozkazami zapisu o odczytu) zajmuje jakies 30s.
Niestety wybrales protokol zupelnie nie pasujacy do usb. Przesylanie
pojedynczych bajtow oddzielnymi transferami to najgorsza
z mozliwosci. Magistrala realizuje tylko jeden transfer w 1 ms ramce
- i juz masz przyczyne : 1ms * 1 kB = ok 1s.
Eee tak źle to nie jest. O ile pamiętam dla typu BULK w ciągu jednej ramki
USB może wysłać kilka/kilkanaście pakietów, natomiast tylko ISO i INTERRUPT
mają ograniczenie do jednego pakietu w ciągu 1ms. Ale za to ISO może być
większe od 64B - nawet 1kB co daje teoretyczną przepustowość 1MB/s, ale to
jest fikcja. Natomiast uzyskanie 200-400kB/s jest realne.
Zadne ustawienia Ft tego nie zmienia - dane musza byc przesylane
wiekszymi pakietami.
To natomiast prawda. Interakcja 1 rozkaz, na 1 daną nie ma sensu.
Ten FTDI to jakiś WashnGo, więc pewnie nie wykorzystasz w pełni możliwości
USB, ale zawsze możesz zastosować jakiś kontroler z USB na pokładzie (np.
Cypress CY7C641xx - szybka 8051 +USB), albo podłączyć jakiś frontend USB np.
NS USBN960x. do kontrolera który już masz.
Pzdr,
Tomasz Sawicki
========
Path: news-archive.icm.edu.pl!agh.edu.pl!news.agh.edu.pl!news.onet.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai
From: "Jerzy Szczesiul" <jerzy.szczesiul_at_nospam_ep.com.pl>
Subject: Re: FTDI 232BM problem
Date: Sat, 24 May 2003 00:22:41 +0200
Użytkownik "Tomasz Sawicki" <kotburak_at_nospam_poczta.onet.pl> napisał w wiadomości
news:bam3od$8tl$1_at_nospam_news.onet.pl...
Niestety wybrales protokol zupelnie nie pasujacy do usb. Przesylanie
pojedynczych bajtow oddzielnymi transferami to najgorsza
z mozliwosci. Magistrala realizuje tylko jeden transfer w 1 ms ramce
- i juz masz przyczyne : 1ms * 1 kB = ok 1s.
Eee tak źle to nie jest. O ile pamiętam dla typu BULK w ciągu jednej ramki
USB może wysłać kilka/kilkanaście pakietów, natomiast tylko ISO i
INTERRUPT
mają ograniczenie do jednego pakietu w ciągu 1ms.
Zgadza się. Transakcje-pakiety tak. Ja o kompletnych
transferach związanych z kolejnymi poleceniami przesyłu.
Tak piszą w dokumentacji Ft8u :
<>
Application Note AN232-04 [..]
With a USB device, the method of transfer is done by packets.
If data is to be sent from the PC, then a packet
of data is built up by the device driver and sent to
the USB scheduler. This scheduler puts the request onto
the list of tasks for the USB host controller to perform.
This will typically take at least 1 millisecond to execute
because it will not pick up the new request until the next
' USB Frame' (The frame period is 1 millisecond). There is
therefore a sizable overhead (depending on your required
throughput) associated with moving the data from the application
to the USB device. If data were sent 'byte at a time' by an
application, this would severely limit the overall throughput of the
system as a whole.
</>
--
Pozdrowienia
Jurek Szczesiul
========
Path: news-archive.icm.edu.pl!agh.edu.pl!news.agh.edu.pl!news.onet.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai