kolejność znaków odebranych

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ć?
Reply to
Jakub Rakus
Loading thread data ...

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...

Reply to
Marek

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.

Reply to
Jakub Rakus

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?

Reply to
Gof

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.

Reply to
Gof

W dniu 2015-03-28 o 21:27, Jakub Rakus pisze:

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

Reply to
BK

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

Reply to
Marek

[...]

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?

Reply to
Pszemol

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.

Reply to
Jakub Rakus

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.

Reply to
Jakub Rakus

Dnia Sat, 28 Mar 2015 17:16:24 +0100, Jakub Rakus napisał(a):

No coz, jakies bledne realizacje fifo moze by i potrafily cos takiego zrobic, ale ... a nie jest to tak, ze wiele bajtow wypada z transmisji? odbierasz 012 z jednej ramki, 7 z drugiej, 345689 z trzeciej ?

Jeszcze mozliwa drobna niezgodnosc zegarow i odbiornik gubi bity ..

J.

Reply to
J.F.

No właśnie, ile w tym FPGA masz domen zegarowych?

MiSter

Reply to
MiSter

Nie, odbieram każdą paczkę, wiem to gdyż w każdej paczce jest bajt będący kręcącym się w kółko licznikiem. Jeśli akurat w błędnej paczce wypadnie, że to bajt licznika zostanie przesunięty to dostaję po prostu jakąś bzdurę między dwoma wartościami prawidłowymi. Ale jak już napisałem wyżej - problem rozwiązany, to podróbka PL2303 kaszani sprawę.

Reply to
Jakub Rakus

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.