Intermittentny błąd odbioru bajtów 249 i 250 przy użyciu USB-RS232 z FPGA

Tue Nov 15, 2011 11:16 pm   

Korzystam z konwertera USB-RS232 do komunikacji FPGA z komputerem.
Używam algorytmu asynchronicznego z 8 bitami danych, bez bitu
parzystości i z jednym bitem stopu.
Gdy przesyłam bajt 249 lub 250 czasami zostaje przesłany poprawnie, a
czasami odbieram 0.
W przypadku innych liczb błąd nie występuje.
Kod po stronie komputera i FPGA jest raczej poprawny.
Co może być przyczyną?
Wadliwy konwerter?

Tue Nov 15, 2011 11:16 pm   

Użytkownik "pbartosz" <bartoszpop@gmail.com> napisał w wiadomości
news:aa3d292a-aa1b-4cee-ae08-9340ead504b7@y42g2000yqh.googlegroups.com...

Prędzej niedopasowanie prędkości transmisji do taktowania procesora.
Ramka się rozjeżdża i bufor jest zerowany. Obadaj na wolniejszych pręściach
jak jest ze stabilnością transmisji.

Tue Nov 15, 2011 11:16 pm   

On 15/11/2011 21:16, pbartosz wrote:

Odbierasz 0x00 bez bledow (po stronie PC), czy oprocz znaku w buforze
masz tez jakies flagi bledow?

Pierwszy test - wysylac z dwoma bitami stopu.

--
Jerry1111

Wed Nov 16, 2011 12:26 am   

Zmniejszyłem Baud Rate z 9600 do 4800 i działa.
Dzięki.

Wed Nov 16, 2011 3:01 am   

On 15 Lis, 22:16, pbartosz <bartosz...@gmail.com> wrote:

Jednak błąd ciągle występuje.
Przetestowałem częstotliwości od 110 bps do 9600 bps.
Bajty przesyłam z komputera na płytkę. Częstotliwość na płytce jest 16
razy większa.
Dwa bity stopy nic nie dają

Wed Nov 16, 2011 8:01 am   

W dniu 2011-11-15 22:16, pbartosz pisze:

Oscyloskop w łapę i sprawdź czasy trwania bitów i poziomy napięć między
FPGA a konwerterem USB.

Wed Nov 16, 2011 8:50 am   

On 11/15/2011 10:16 PM, pbartosz wrote:

mialem doczyczynienia z konwerterami USB - RS232 - po dokladnym
przetestowaniu, wyszlo na to ze sa one nie kompatybilne ze standardem,
sprawdz zwykly RS232 wbudowany w plyte glowna, powinno chodzi OK ...

Wed Nov 16, 2011 8:53 am   

Użytkownik "walker" <ewalker.cut@gazeta.without.pl> napisał w wiadomości
news:j9vq0r$h3n$1@news.vectranet.pl...

Myślę, że może być jednak problem z częstotliwością. Najprawdopodobniej tą od
strony FPGA.
Oscyloskop, który umożliwi zmierzenie impulsów to najlepszy pomysł.
--
Pozdr
EM

Wed Nov 16, 2011 8:56 am   

Dnia Tue, 15 Nov 2011 22:32:29 +0100, Marcin Wasilewski napisał(a):

Akurat 250 (FA) czy 249 (F9) maja duzo 1 i tak sie nie powinno zdarzac.
No chyba ze tak sie objawia "frame error".

Sprawdzilbym jeszcze inne wartosci ... ale rzecz warta podlaczenia
oscyloskopu i sprawdzenia.

J.

Wed Nov 16, 2011 11:37 am   

Użytkownik "pbartosz" napisał w wiadomości grup

Ale jak - po obu stronach czy po jednej ?

RS-232 powinien chodzic znacznie szybciej - bledow nie ma i przy
115200, a nowsze to i na 920k potrafia.

J.

Wed Nov 16, 2011 12:31 pm   

Użytkownik "pbartosz" <bartoszpop@gmail.com> napisał w wiadomości
news:f4f725f9-3962-4cad-abee-c1474212e331@4g2000yqu.googlegroups.com...



W jaki sposób dokonujesz odczytu bufora? Przerwania, w pętli?
Jeśli w pętli, to używasz w ogóle przerwań do innych celów?

Wed Nov 16, 2011 12:40 pm   

Użytkownik "Zbych" <abuse@onet.pl> napisał w wiadomości
news:4ec35fb2$0$2201$65785112@news.neostrada.pl...

Powiem, jak ja uruchamiałem swoje pierwsze packet-radio.
Kupiłem modem, wg SP5MXH, zestawiłem układ, odbiera, próbuję się łączyć, ale
adresat nie odpowiada. Poproszeni o podpowiedź koledzy zajmujący się
tematyką po zademonstrowaniu im sygnału (jedna z pierwszych rzeczy,
sprawdzić co i jak wychodzi) mówili, że sygna wygląda na zawierający
nienaturalnie dużo wysokich tonów. Jako, że kluczowanie jest sygnałem TTL
przez transoptory (dlatego bezpieczne dla C64) galwanicznie izolujące
komputer od radia, to pomyślałem, że coś musi zniekształcać przebieg.
Szczęśliwie, dysponowałem oscyloskopem i bingo, Sygnał zamiast być
prostokątny, przypominał piłę ze stępionymi zębami. Powodem kłopotu był
kondensator blokujący linię kluczowania 0/1, postawienie stanu 1 odbywało
się prawidłowo, ale powrót do zera tragicznie, zamiast poprawnego prostokąta
jakbym pilnikiem ściął, przez to modem kluczował generator w złym momencie i
odbiorca głupiał - zero pojawiao się po rozładowaniu kondensatora, klucz
dając zero pozostawał w stanie izolacji i kondensator rozładowywał się przez
linię.
Usunąłem kondensator i ruszyło jak z kopyta, przekazałem uwagi
konstruktorowi modemu, co się działo, co zbadałem i jak rozwiązałem.

Czemu o tym piszę? Może tam podobny problem, co u mnie - doszedłem do źródła
i załatałem problem...
Kondensator, pojemności pasożytnicze? I przebieg zniekształcony na tyle, że
się chrzani?

--
Alanné mba yi woma... wé (...)
Né ma ka ni kaso, Né ma pané ka, (...)
We ya senga wé, Has wéhé... )
(C) Wes Madiko - Alane

Wed Nov 16, 2011 1:08 pm   

Użytkownik "J.F" <jfox_xnospamx@poczta.onet.pl> napisał w wiadomości
news:ja03oe$lk6$1@news.onet.pl...

Zależy przy jakim zegarze. Różnie z tym bywa, ale najczęściej jest tak,
że na jeden bit danych musi przypadać minimum x cykli procesora. Poza tym do
uzyskania danej częstotliwości RS-232 używane są dzielniki i nie każdy zegar
się do danej częstotliwości nadaje, ale z tym problemy się zaczynają od
okolicy 57600 bodów i wyżej.

Wed Nov 16, 2011 2:01 pm   

Wg Twojego przypadku przeklamana bylaby cala transmisja.
Watkotworca ma inne objawy.

Wed Nov 16, 2011 5:23 pm   

Użytkownik "Marcin Wasilewski" napisał w wiadomości grup
dyskusyjnych:ja092t$h5e$1@news.onet.pl...
Użytkownik "J.F" <jfox_xnospamx@poczta.onet.pl> napisał w wiadomości

Ale kolega tam nie ma zadnego procesora :-)

Owszem, poniewaz transmisja jest asynchroniczna i moze sie zaczac w
dowolnym momencie, potrzebny jest szybki zegar, zeby probkowac czesto
linie, zareagowac na poczatek bitu startu szybko, odmierzyc pol bitu,
a potem juz mozna powoli :-)


Owszem, moze byc problem z wygenerowaniem odpowiedniej czestotliwosci.
Ale to nie tylko przy dwoch kodach bedzie sie mylilo.

J.