Transmisja RS232

[Gość]

Witam,
Pracuję nad transmisją mikrokontrolera z portem RS232. Zrobiłem ją na standardowych vi a nie na VISA bo wydawała mi sie mało stabilna.
Generalnie wszystko działa ale mam problem z powtarzaniem operacji tzn. dane z mikrokontrolera są wywoływane komendą lecz przy następnym wywoływaniu tą komendą nie ma takiego samego odzewu jak przy pierwszym wywołaniu.
W związku z tym moje pytanie:
1) czy idzie jakoś "wyczyścic" bufor zapisu i odczytu w standardwej komunikacji (nie VISA)?
2) jak zrobic zeby ilosc bajtów dostosowywała sie sama do bajtow obieranych tzn. żebym nie musiał deklarowac stałej ilości requested byte count?

byłbym wdzięczny za pomoc
pozdrawiam

[Mikrobi]

Trzy pytania na początek:
1. Jaki masz system operacyjny, jaką wersję LabVIEW?
2. co rozumiesz przez standardowe VI ?
3. dlaczego uważasz że VISA jest "niestabilna"?

[Gość]

Trochę z innej beczki, lecz też o problemach z RS232:

1. LabView 7.1, WinXP, PIV 3G, 1G RAM.

2. Wysyłam do zewnętrznego urządzenia przez RS w PC zapytanie i dostaję odpowiedź. Zewnętrznym urządzeniem jest "czysty hardware" na mikroprocesorze. Funkcjonuje on na 100% poprawnie - sygnały, bit po bicie i ramka po ramce sprawdzane na oscyloskopie.

3. Odpowiedź "siedzi" sobie w buforze RS w PC.
Czekam np. 20ms i odczytuję ją standardową aplikacją z VISA (wzór z exampla).

4.Ale...., jeśli odpowiedź w urządzeniu ma 15 bajtów, to LabView odczytuje mi z portu....tylko np. 8 bajtów. Czekam ok. 10 ms i znów odczytuję port RS, i wtedy mam jeszcze brakujące 7 bajtów (proporcje czasami się różnią). :evil:

5. Po dwukrotnym (czasami trzykrotnym) odczycie portu mam całą odebraną odpowiedź.

6. W tym czasie do portu nic do dosyłałem !!!! Wszystko trafiło tam na samym początku. Po raz pierwszy odczytuję port RS w PC, wtedy, gdy transmisja z zewnętrznego urządzenia już dawno się skończyła - stąd te opóĹşnienie 20 ms na początku.

7. Tak czy inaczej transmisja mi się rwie i się przedłuża.

Według mnie bruĹşdzi mi tu Windows i jego sposób obsługi portu RS, ale brak mi na to dowodów.

Ma ktoś może jakiś pomysł, co z tym fantem zrobić? Albo jak to definitywnie stwierdzić? Może ktoś wie dokładnie, co Windowsy wyczyniają z portem RS? :?:

[Gość]

Witam,

Odp: 1) WinXP, LabView 6.1
2) użyłem sformuowania "standardowe" aby odróżnc jakoś
wykorzystanie VISA od wykorzystania koponentów Serial
Compatibility do transmisji.
(Instrument I/O-> I/O Compatibility-> Serial Compatibility)
3) "nietabilna" - ponieważ przynajmniej w moim przypadku
transmisja, którą stworzyłem raz przebiega bez zarzutów a drugi
raz pojawiają się błędy i jest to czysto losowa sprawa. Zdaje
sobie sprawe że to raczej wina samej transmisji przez RS232
albo i mojego programu (jestem początkujący ) lecz przy
użyciu komponentów "Serial Compatibility" problemy
te znikają.

Mikrokontroler reaguje na określone komendy słowne. Po wywołaniu jedną z tych komend dokonuje odpowiedniego pomiaru, wysłania tych danych portem RS a następnie wraca do pętli gdzie znowu oczekuje na ponowne wprowadzenie komendy.
Program w mikrokontrolerze działa poprawnie gdyż transmisja np. z terminal emulatorem działa ok włącznie z wielokrotnym wywoływaniem komendami.
Mój problem polega na tym, że nie potrafie wywołac więcej niż raz (komendą wysłaną z PC do mikrokontrolera) tej samej reakcji mikrokontrolera. Tzn. mikrokontroler reaguje na ponowne wywołanie go określoną komendą ale nie w ten sam sposób co za pierwszym razem. W związku z tym za każdym razem muszę odłączac zasilanie od układu.

Próbowałem juz chyba wszystkiego ale dalej nie wiem w czym tkwi problem.

Przepraszam jeżeli namieszałem.

pozdrawiam

Sieciel

[Defiant]

Proponuję odczytajć jeszcze raz bufor RS'a - czasami ma jeszcze coś do dodania (przy krótkim timeout'cie nie musi to trwać wieki).

[mgawlik]

mialem podobne problemy (w2k, laptop ASUS, LV7.1) z tym ze ja uzywalem przejsciowki USB - RS232 i myslalem ze problemy wynikaja wlasnie z tego. przejsciowka USB byla widziana po zainstalowaniu jako normalny port szeregowy. uzywalem narzedzi VISA.

zauwazylem, ze podczas tansmisji laptop-PC (obustronnej) nie wystepuja zadne problemy, przesylalem pojedyncze dane i kawalki plikow i nic sie nie zawieszalo ani nie gubilo danych. problem pojawial sie w transmisji z mikrokontrolera. zwalilem to na niedopracdowany soft w mikrokontrolerze, ale widze ze nie slusznie.

byc moze problemem jest to, ze w transmisji zwiazanej z mikrokontrolerem wykorzywstujemy tylko TXR i RXD, a pomijamy te dodatkowe sygnaly ktore sa w porcie. chociaz to dosc latwo bedzie wykazac, wystarczy odpowiednio spreparowac kabel do RSa, zlaczyc nim dwa PCty i sprawdzic co bedzie sie dzialo.

czasem problemem mikrokontrolerow sa zle kwarce, t.z. najlepiej faktycznie dac kwarc 11.059MHz i dokladnie dopasowac timingi transmisji

[Gość]

No tak tylko TXR i RXD, a kwarc mam 8MHz. Lecz nie moge tego zmienić bo taki jest układ :/

[mgawlik]

przeczytaj w dokumentaji mikrokontrolera rozdzial dotyczacy portu szeregowego. powinna tam byc tabelka zalecanych kwarcow i zwiazanych z nimi mozliwych predkonsci portu oraz bledu jaki sie pojawia jesli kwarc nie jest dobrze dopasowany czestotliwosciowo. z tych danych okreslisz czy miescisz sie w bledzie dopuszczanym przez standard. napiszco ci wyszlo to pokombinujemy dalej.

[Gość]

Dla predkości transmisji 9600 bodów i częstotliwości 8MHz ten błąd wynosi 0,16%. To chyba nie dużo? Ile wynosi standard? Słyszałem że do 1% jest ok, czy to prawda?

pozdrawiam

[Gość]

Przerobiłem to na VISA podorabiałem pare rzeczy i działa bez zarzutów (cofam zdanie o "niestabilności VISA).
Ale dalej nie idzie w tym samym cyklu (oprócz pierwszego razu) wywołac mikrokontrolera tak by zareagował jak za pierwszym razem.

Program:
1.Konfiguracja portu - OK
2.Odczyt z portu - OK
3.Zapis do portu (wpisanie komendy) - OK
4.Odczyt danych z portu (wywołanych komendą) -OK
5. Zapis do portu (tej samej komedny) - OK
6. Odczyt danych z portu (wywołanych komendą) - OK ale nie tych co w p.3
7.Zamknięcie transmisji - OK

W etapie 6 mojego programu nie odczytuje tych samych danych co w p.3 (a powinien!).
Program w mikrokontrolerze jest tak napisany że wprowadzenie jakiejkolwiek innej komendy niż zadeklarowana sygnalizowane jest krótkim komunikatem . Ten właśnie komunikat odczytuje mi w p.6.
Wygląda to tak jakby wpisywana była inna komenda - lecz komenda jest identyczna!

Czy wobec tego zostaje mi już tylko programowy reset zasilania układu ???

[Gość]

Działa!!! )))) yes

ps. powyższe pytanie - nieaktualne

pozdrawiam

Sieciel