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

> 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.
Tzn? Jakim zegarem poganiasz ten procek?

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?

do góry

Użytkownik "Zbych" <a...@o...pl> napisał w wiadomości
news:4ec35fb2$0$2201$65785112@news.neostrada.pl...
>W dniu 2011-11-15 22:16, pbartosz pisze:
>> 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?
>
> Oscyloskop w łapę i sprawdź czasy trwania bitów i poziomy napięć między
> FPGA a konwerterem USB.

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

do góry

Użytkownik "J.F" <j...@p...onet.pl> napisał w wiadomości
news:ja03oe$lk6$1@news.onet.pl...
> Użytkownik "pbartosz" napisał w wiadomości grup
>> Zmniejszyłem Baud Rate z 9600 do 4800 i działa.
>> Dzięki. :)
> 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.

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.

do góry

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

do góry

Użytkownik "Marcin Wasilewski" napisał w wiadomości grup
dyskusyjnych:ja092t$h5e$...@n...onet.pl...
Użytkownik "J.F" <j...@p...onet.pl> napisał w wiadomości
>>> Zmniejszyłem Baud Rate z 9600 do 4800 i działa.
>> 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.

> 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

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 :-)

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

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

J.

do góry

Użytkownik "Jacek" <a...@o...pl> napisał w wiadomości
news:jmbsuy1rusc2$.2u62r88feucs.dlg@40tude.net...
> Wg Twojego przypadku przeklamana bylaby cala transmisja.
> Watkotworca ma inne objawy.

Przepraszam Jacku, komu odpisujesz? Ani nie zaznaczyłeś komu, ani nie
zacytowałeś, a raczej mało kto ma "wróżka" w rubryce zawód wpisane. (a
przepraszam, po "references" szukać nie będę, nie mam na to czasu ani chęci)
Domyśliłem się jedynie, że chodzi o mnie. W takim razie odpowiem, choć nie
powinienem, nie mając pewności, że dotyczy to mnie.

Skoro są problemy z transmisją, pierwsze co bym zrobił, to sprawdził, czy
przebieg jest prawidłowy, niezależnie, jaki to problem. Jak ma być dokładnie
sprawdzone, to nawet mało prawdopodobne "opcje". Zniekształcenie przebiegu
może być tak minimalne, że zwykle idzie, ale coś czasem kichnie i nie
pójdzie, zaś, gdy transmisja nie jest zbyt dobrze zabezpieczona (np. jedynie
zwykła suma CRC, czy wręcz bajt modulo, lub parzystości), łatwo może ulec
przekłamaniu zarówno blok danych, jak i bajt(y) kontrolny(-e). Kilkakrotnie
zdarzyło mi sięna Packet-Radio już ze sporawnym przebiegiem, ale za to
zaszumionym sygnałem, zakłócenie spowodowało przekłamanie pakietu i CRC tak,
że kontrola to puściła. Akurat wiem, co dokładnie miało przyjść,a jeden znak
jednak był inny. O tym, że nadawca wysyłał pakiet prawidłowo, wiedziałem z
podglądu - były pewne problemy - za słaby sygnał i trochę powtórek. Jedna
okazała się błędna...
W momencie, gdy jest to np. komenda coś sterująca, to może ją źle wykonać,
albo w ogóle pójść w maliny.
Dlatego opisałem swój przypadek ze zniekształconym przebiegiem, aby kolega z
kłopotem sprawdził też pod tym kątem.

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

do góry

On 16/11/2011 01:01, pbartosz wrote:
> On 15 Lis, 22:16, pbartosz<b...@g...com> wrote:
>> 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?
>
> 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ą

Znaczy w VHDL trzeba szukac. Jak mocno jestes pewny ze nie ma tam
nigdzie bledu?

Inny test - jak masz drugi konwerter to, zebys wyeliminowal wszystko co
mozliwer, podlacz go do wyjscia RX MAX232 ktory jest po stronie FPGA i
wsadz to na innego COMa. Jesli bedzie OK, to znaczy ze problem lezy
pomiedzy tym pinem i miejscem ktore Ci wyswietla HEX.


--
Jerry1111

do góry

Zrobiłem kilka testów i sytuacja wygląda następująco:
- w komunikacji PC-FPGA z użyciem portu RS232 w komputerze
stacjonarnym błąd nie występuje,
- błąd przy przesyłaniu przez konwerter objawia się tym, że czasami
zostaje wysłana! wartość 0 zamiast 249 lub 250 - błąd jest po stronie
wysyłającej,
- na innym komputerze i z innym sterownikiem konwertera błąd nadal
występuje.
Stąd wnioskuję, że konwerter jest wadliwy.

Zauważyłem jeszcze, że na drugim komputerze z innym sterownikiem
konwertera, wysyłanie danych w ogóle nie działało, jeśli pomiędzy
kolejnymi wywołaniami funkcji WriteFile nie było odpowiednio długiej
przerwy (musiał być np. Sleep(5)). W pierwszym komputerze ten problem
nie występuje.

Jutro postaram się sprawdzić inny konwerter.

do góry

Araneus Diadematus <w...@c...pl> napisał(a):
> Przepraszam Jacku, komu odpisujesz? Ani nie zaznaczyłeś komu, ani nie
> zacytowałeś, a raczej mało kto ma "wróżka" w rubryce zawód wpisane. (a
> przepraszam, po "references" szukać nie będę, nie mam na to czasu ani
> chęci) Domyśliłem się jedynie, że chodzi o mnie. W takim razie odpowiem,
> choć nie powinienem, nie mając pewności, że dotyczy to mnie.

Przepraszam, że się wtrącę, ale skoro jest References, to IMO nie ma dużego
problemu, bo każdy sensowny czytnik wątkuje. Oczywiście z cytatem byłoby
kulturalniej.

--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
Uptime: 1 day, 23 hours, 44 minutes and 10 seconds

do góry

Zrobiłem kilka testów i sytuacja wygląda następująco:
- w komunikacji PC->FPGA z użyciem portu RS232 w komputerze
stacjonarnym błąd nie występuje,
- błąd przy przesyłaniu PC->FPGA przez konwerter objawia się tym, że
czasami
zostaje wysłana! wartość 0 zamiast 249 lub 250 - błąd jest po stronie
wysyłającej,
- na innym komputerze i z innym sterownikiem konwertera błąd nadal
występuje.
Stąd wnioskuję, że konwerter jest wadliwy.

Zauważyłem jeszcze, że na drugim komputerze, wysyłanie danych z PC nie
działało (pojawiał się falstart lub framing error), jeśli pomiędzy
kolejnymi wywołaniami funkcji WriteFile nie było odpowiednio długiej
przerwy (musiał być np. Sleep(5)). W pierwszym komputerze ten problem
nie występuje.

Jutro postaram się sprawdzić inny konwerter.

do góry