Natrafiłem na dziwny problem:
Mam robocika, którego mózgiem jest FPGA, wysyłam z niego dane do kompa
UARTem. Robot wysyła paczki o rozmiarze 32 bajtów z prędkością 115200.
Na chwilę obecną idzie to po kablu: FPGA (UART 3.3V) -> konwerter
poziomów 3.3/5V -> PL2303 -> USB. Na kompie mam prosty programik w C,
który odbiera dane z ttyUSB, przelicza pomiary i zapisuje do pliku
tekstowego. Do tej pory robot wysyłał dane 5 razy na sekundę i wszystko
było cacy, ale chwilowo potrzebuje zobaczyć szybkie zmiany i zwiększyłem
częstotliwość wysyłania do 100Hz. Dane ładnie sobie spływają, ale
zauważyłem, że co kilkadziesiąt-kilkaset ramek jest jakiś kwas. Po
obejrzeniu surowych danych odczytanych z ttyUSB okazuje się, że w
błędnych ramkach jeden bajt zmienia swoje położenie, jakby coś się
gdzieś buforowało i nagle wypluwało później. Porównałem niby "błędną"
ramkę odebraną przez kompa i analizatorem logicznym obejrzałem co
wypluwa FPGA i co ciekawe od tej strony jest dobrze. Czyli wygląda to
tak, że FPGA wysyła ramkę powiedzmy:
0 1 2 3 4 5 6 7 8 9,
ale po jej odebraniu robi się:
0 1 2 7 3 4 5 6 8 9
Czyli w tym przypadku bajt wysłany jako 7 nagle znalazł się między
odebranymi 2 a 3.
O co tu może chodzić?

--
Pozdrawiam
Jakub Rakus

do góry

On Sat, 28 Mar 2015 17:16:24 +0100, Jakub Rakus <s...@o...pl>
wrote:
> poziomów 3.3/5V -> PL2303 -> USB. Na kompie mam prosty programik w
C,

Offtopicznie: masz na pewno pl2303 5V?
Mam ze dwa klony tych układów, które się zgłaszają jako pl2303 ale z
Linuxowym usbserial co kilka ramek prawidłowych danych wysyłają
śmieci...

--
Marek

do góry

On 28.03.2015 19:50, Marek wrote:
> On Sat, 28 Mar 2015 17:16:24 +0100, Jakub Rakus <s...@o...pl> wrote:
>> poziomów 3.3/5V -> PL2303 -> USB. Na kompie mam prosty programik w
> C,
>
> Offtopicznie: masz na pewno pl2303 5V?
> Mam ze dwa klony tych układów, które się zgłaszają jako pl2303 ale z
> Linuxowym usbserial co kilka ramek prawidłowych danych wysyłają śmieci...
>

Na scalaku napisane PL2303, a co tam chińczyk wsadził do środka nikt nie
wie, lsusb pokazuje:
Bus 002 Device 003: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial
Port
Nigdy nie sprawiał mi problemów, na pewno nie wtyka "śmieci" między
ramki i nie przekłamuje ich całkiem, robiłem nawet próby wysyłania
dużego pliku tekstowego przy zwarciu RX-TX i idzie bez problemu.

--
Pozdrawiam
Jakub Rakus

do góry

Jakub Rakus <s...@o...pl> wrote:

> Na scalaku napisane PL2303, a co tam chińczyk wsadził do środka nikt nie
> wie, lsusb pokazuje:

Masz jak sprawdzić z FT232? Raczej podejrzewałbym PL2303 o jaja... chociaż
nigdy nie miałem z nim problemu pod Linuksem. Z FTDI też nie.

Zasilanie PL2303 dobrze odfiltrowane, stabilne?

--
"qui hic minxerit aut cacaverit, habeat deos superos et inferos iratos"
http://www.chmurka.net/

do góry

Jakub Rakus <s...@o...pl> wrote:

> Na chwilę obecną idzie to po kablu: FPGA (UART 3.3V) -> konwerter
> poziomów 3.3/5V -> PL2303 -> USB. Na kompie mam prosty programik w C,
> który odbiera dane z ttyUSB, przelicza pomiary i zapisuje do pliku

Jeszcze jedno - masz jak to sprawdzić na Windowsie? Może kernelowy moduł
do PL2303 ma jakiegoś buga...

Albo np. na innym PC (inna płyta główna, inny kontroler USB)...

Miałem takie jaja, o jakich piszesz, ale na zupełnie innym sprzęcie (moduł
Bluetooth czasami tak się zachowywał), ale wrzucenie najnowszego firmware
załatwiło problem.

--
"qui hic minxerit aut cacaverit, habeat deos superos et inferos iratos"
http://www.chmurka.net/

do góry

W dniu 2015-03-28 o 21:27, Jakub Rakus pisze:
>
> Na scalaku napisane PL2303, a co tam chińczyk wsadził do środka nikt nie
> wie, lsusb pokazuje:
> Bus 002 Device 003: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial
> Port
> Nigdy nie sprawiał mi problemów, na pewno nie wtyka "śmieci" między
> ramki i nie przekłamuje ich całkiem, robiłem nawet próby wysyłania
> dużego pliku tekstowego przy zwarciu RX-TX i idzie bez problemu.
>

Miałem kiedyś konwerter właśnie z układem PL2303 (lub jego klonem) i
potrafił długo działać poprawnie a potem nagle zacząć głupieć. Głupienie
polegało na zamienianiu nie tyle pojedynczych bajtów co całych ciągów.
Czym gęstsza była komunikacja tym prawdopodobieństwo zgłupienia większe.
Od tego czasu wystrzegam się wszystkiego co ma w sobie układ PL2303 bo
sporo włosów wyrwałem sobie z głowy zanim doszedłem do wniosku, że to
konwerter psuje transmisję...

BK

do góry

On Sat, 28 Mar 2015 21:27:14 +0100, Jakub Rakus <s...@o...pl>
wrote:
> Na scalaku napisane PL2303, a co tam chińczyk wsadził do środka
nikt nie
> wie, lsusb pokazuje:
> Bus 002 Device 003: ID 067b:2303 Prolific Technology, Inc. PL2303
Serial
> Port
> Nigdy nie sprawiał mi problemów, na pewno nie wtyka "śmieci" między
> ramki i nie przekłamuje ich całkiem, robiłem nawet próby wysyłania
> dużego pliku tekstowego przy zwarciu RX-TX i idzie bez problemu.

No to oryginał, te klony mają inne oznaczemia ale zgłaszają devid
pl2303.

--
Marek

do góry

"Jakub Rakus" <s...@o...pl> wrote in message
news:mf6k4p$utj$1@node2.news.atman.pl...
> Natrafiłem na dziwny problem:
[...]
> tak, że FPGA wysyła ramkę powiedzmy:
> 0 1 2 3 4 5 6 7 8 9,
> ale po jej odebraniu robi się:
> 0 1 2 7 3 4 5 6 8 9
> Czyli w tym przypadku bajt wysłany jako 7 nagle znalazł się między
> odebranymi 2 a 3.
> O co tu może chodzić?

A ja zapytam z innej nieco strony - Czy Twój protokół
komunikacyjny ma jakąś ścisłą formę, paczki danych są
ładnie ubrane w ramki start/stop/suma kontrolna (STX/ETX/CRC)?
Czy przesyłasz "gołe" dane?

do góry

On 29.03.2015 14:49, Pszemol wrote:
> "Jakub Rakus" <s...@o...pl> wrote in message
> news:mf6k4p$utj$1@node2.news.atman.pl...
>> Natrafiłem na dziwny problem:
> [...]
>> tak, że FPGA wysyła ramkę powiedzmy:
>> 0 1 2 3 4 5 6 7 8 9,
>> ale po jej odebraniu robi się:
>> 0 1 2 7 3 4 5 6 8 9
>> Czyli w tym przypadku bajt wysłany jako 7 nagle znalazł się między
>> odebranymi 2 a 3.
>> O co tu może chodzić?
>
> A ja zapytam z innej nieco strony - Czy Twój protokół
> komunikacyjny ma jakąś ścisłą formę, paczki danych są
> ładnie ubrane w ramki start/stop/suma kontrolna (STX/ETX/CRC)?
> Czy przesyłasz "gołe" dane?

Tak, każda paczka zaczyna się dwoma ramkami startu i kończy bardzo
prostym CRC i ramką stopu. CRC jest banalne, to zwykły XOR wszystkich
bajtów przed nim, dlatego też nie jest odporny na zamianę miejscami
bajtów w paczce. Ale rzecz nie w tym, żeby eliminować takie paczki, (bo
to mogę rozpoznać po dziwnych danych nawet jak CRC się zgadza), tylko
spowodować żeby one się poprawnie odbierały.

--
Pozdrawiam
Jakub Rakus

do góry

On 28.03.2015 23:49, Marek wrote:
> On Sat, 28 Mar 2015 21:27:14 +0100, Jakub Rakus <s...@o...pl> wrote:
>> Na scalaku napisane PL2303, a co tam chińczyk wsadził do środka
> nikt nie
>> wie, lsusb pokazuje:
>> Bus 002 Device 003: ID 067b:2303 Prolific Technology, Inc. PL2303
> Serial
>> Port
>> Nigdy nie sprawiał mi problemów, na pewno nie wtyka "śmieci" między
>> ramki i nie przekłamuje ich całkiem, robiłem nawet próby wysyłania
>> dużego pliku tekstowego przy zwarciu RX-TX i idzie bez problemu.
>
> No to oryginał, te klony mają inne oznaczemia ale zgłaszają devid pl2303.
>

Po przyjrzeniu się dokładnie scalakowi stwierdzam, że to chyba jednak
nie jest oryginał. Mam takiego gotowca z ebaya wciskanego w usb z
wyprowadzonymi goldpinami, na scalaku PL2303HX, jak się zajrzy na stronę
Prolifica i w noty to wychodzi, że to rewizja A, o której ostrzegają, że
jest dużo podróbek. No i ta moje też chyba jest oszukana bo ma jakiś
dziwny kod daty produkcji, niezgodny z wzorcem zamieszczonym w dataszicie.
Na razie robię próby na przejściówce RS232/USB z układem HL340 i
wygląda, że teraz jest dobrze, nie zauważam poprzestawianych ramek.
Chyba jednak trzeba będzie tego PL przelutować na oryginała.

--
Pozdrawiam
Jakub Rakus

do góry