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?
Użytkownik "pbartosz" snipped-for-privacy@gmail.com napisał w wiadomości news: snipped-for-privacy@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.
Odbierasz 0x00 bez bledow (po stronie PC), czy oprocz znaku w buforze masz tez jakies flagi bledow?
Pierwszy test - wysylac z dwoma bitami stopu.
Zmniejszyłem Baud Rate z 9600 do 4800 i działa. Dzięki. :)
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ą
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.
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 ...
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ł.
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.
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.
Użytkownik "pbartosz" snipped-for-privacy@gmail.com napisał w wiadomości news: snipped-for-privacy@4g2000yqu.googlegroups.com...
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?
Użytkownik "Zbych" snipped-for-privacy@onet.pl napisał w wiadomości news:4ec35fb2$0$2201$ snipped-for-privacy@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?
Użytkownik "J.F" <jfox snipped-for-privacy@poczta.onet.pl> napisał w wiadomości news:ja03oe$lk6$ snipped-for-privacy@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.
Wg Twojego przypadku przeklamana bylaby cala transmisja. Watkotworca ma inne objawy.
Użytkownik "Marcin Wasilewski" napisał w wiadomości grup dyskusyjnych:ja092t$h5e$ snipped-for-privacy@news.onet.pl... Użytkownik "J.F" <jfox snipped-for-privacy@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.
Użytkownik "Jacek" snipped-for-privacy@ola.pl napisał w wiadomości news:jmbsuy1rusc2$. snipped-for-privacy@40tude.net...
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.
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.
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.
Araneus Diadematus snipped-for-privacy@chlewik.pl napisał(a):
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.
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.
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.