ATNEL tech-forum

Re: "Przerywana" komunikacja z terminalem po RS232

2013-06-16T18:37:17+01:00

Aaaa no to teraz rozumiem wszystko jasne

Statystyki: Napisane przez mirekk36 — 16 cze 2013, o 18:37

Re: "Przerywana" komunikacja z terminalem po RS232

2013-06-16T18:20:35+01:00

Co innego pomyślałem a co innego napisałem, oczywiście chodziło mi wykorzystanie timera programowego i procedurki opisanej na 406 str

Statystyki: Napisane przez keymaker — 16 cze 2013, o 18:20

Re: "Przerywana" komunikacja z terminalem po RS232

2013-06-16T16:33:51+01:00

do przerwan ??? z petli glownej ??? to jednak mocno jeszcze czegos nie rozumiesz. Przerwania to nie wątki jak w PC więc tylko zdecydowanie pogorszysz sytuację. Musisz się nauczyc pisac funkcje niblokujace a to wcale nie oznacza tylko tego zeby nie stosowac delayow. Dobry przyklad funkcji nieblokujacej masz w niebieskiej ksiazce SUPERDEBOUNE. Przyjrzyj sie jej , naucz sie wykorzystywac timery programowe i wtedy zadna funkcja w petli glownej nie przeszkodzi ci w obsludze zdarzenia uarta. Bo jeszcze raz powtorze pomysl przeniesienia jak to mowiszdlugich funkcji do przerwan to pomysl z kosmosu

a antenka ? pewnie ze musi byc

Statystyki: Napisane przez mirekk36 — 16 cze 2013, o 16:33

Re: "Przerywana" komunikacja z terminalem po RS232

2013-06-16T15:46:38+01:00

Oczywiście tego 10s delaya podałem wyłącznie jako mocno przerośnięty zamiennik innych funkcji, które bym planował wkomponować w pętle główna, a które nawet bez opóźnień w nich zawartych (bo nigdzie funkcji delay nie zamierzam używać) ale mimo wszytko będą się jakiś tam czas wykonywać, a co jak rozumiem w powyższego posta zmniejszy częstotliwość wykonywania się zdarzenia od obsługi uart No nic będę kombinował, zapewne poprzerzucam funkcje z pętli głównej main do procedur obsługi przerwań.

A co z tą drucikową antenką? Ktoś wie?

Statystyki: Napisane przez keymaker — 16 cze 2013, o 15:46

Re: "Przerywana" komunikacja z terminalem po RS232

2013-06-16T12:36:30+01:00

Quote:

Bo gdy załóżmy będzie:
while(1) { _delay_ms(10000); UART_RX_STR_EVENT(bufor); }
to podczas tego okresu czekania 10s dane będą odebrane ale reakcja na nie nastąpi dopiero przy dojściu programu do linijki UART_RX_STR_EVENT(bufor);?

korzystanie z tego mechanizmu (zdarzeń / EVENTS) zakłada że WSZYSTKO W PĘTLI głównej jest NIEBLOKUJĄCE. A zatem naturalną rzeczą będzie to że jak zablokujesz pętlę główną szczególnie w tak obrzydliwy sposób _delay'em .... to wiadomo że zdarzenie będzie miało czkawkę 1 sekundową - takie programowanie jest wręcz niedopuszczalne.

Zapomnij o delayach, chociaż jak rozumiem tutaj podałeś tego delaya tylko jako przykład dla lepszego zrozumienia i upewnienia się idei działania - mam nadzieję.

Statystyki: Napisane przez mirekk36 — 16 cze 2013, o 12:36

Re: "Przerywana" komunikacja z terminalem po RS232

2013-06-16T10:35:09+01:00

Uzupełniając to co napisałem wcześniej, pracuję na systemie Win7 64bit, sterowniki od dongla zainstalowały się automatycznie, ale z racji, że na dołączonej CD były sterowniki widcomm to postanowiłem je też zainstalować. Nie było z tym żadnych kłopotów.

W celu przetestowania przełączyłem się na komunikację po kablu, problemów z podłączeniem przez putty brak, przerywanej komunikacji w terminalu również nie uświadczyłem, zatem kod jest ok, więc wróciłem do BT. Na drodze dalszych "zabaw" zauważyłem, że częstotliwość poprawnych podłączeń przez putty oraz jakości komunikacji wydaje się zależeć od położenia płytki a wiec modułu BT na biurku 0.o.

Uwzględniając to co napisał mirekk36 o antence to właśnie w jej braku bym upatrywał dziwne zachowania mojego modułu BT (nie ma jej pewnie dlatego, że tak jak napisałem w pierwszym poście mój modulik pochodzi od konkurencji).

Zatem (bo może ktoś to wie/sprawdzał) owa drucikowa antenka w modułach z układem BTM-222 znacząco wpływa na jakość komunikacji? Czy jej brak w istotnym stopniu może wpływać na jakość połączenia?

Mam jeszcze jedno pytanko odnośnie czy dobrze rozumiem działanie zdarzenia UART_RX_STR_EVENT(bufor);.
To jest tak z nim, że dane nadchodzące z RS są odbierane na bieżąco, w tle działania programu, ale reakcja na te dane następuje dopiero gdy wykonywany program natrafi na tą linijkę: UART_RX_STR_EVENT(bufor);?
Czyli, że idealną byłaby sytuacja (ponieważ zależny mi na szybkiej i ciągłej reakcji na komendy, które chce wysyłać do uC):
while(1) { UART_RX_STR_EVENT(bufor); } ?
Bo gdy załóżmy będzie:
while(1) { _delay_ms(10000); UART_RX_STR_EVENT(bufor); }
to podczas tego okresu czekania 10s dane będą odebrane ale reakcja na nie nastąpi dopiero przy dojściu programu do linijki UART_RX_STR_EVENT(bufor);?

Statystyki: Napisane przez keymaker — 16 cze 2013, o 10:35

Re: "Przerywana" komunikacja z terminalem po RS232

2013-06-16T00:39:25+01:00

hmm dziwny problem opisujesz ale ja bym przede wszystkim na twoim miejscu sprawdził czy te kody których używasz najpierw działają po kablu bez BTM'a .... czy gdzieś nie popełniasz babola w programie

druga sprawa - piszesz że nie dolutowałeś antenki - ale to jak ? masz moduł ATB-BTM-222 od nas i dostałeś bez wlutowanego kawałka przewodu jako antenki ? to coś nie tak - dlaczego nie zgłosiłeś tego do mnie ?

nie napisałeś nic o systemie na jakim pracujesz ale sądząc po opisie walk ze sterownikami to przypuszczam że na XP ? dobrze myślę ? - bo pod Win7 albo Win8 nie miałbyś takich kłopotów

dlatego dobrze by było gdybyś miał możliwość sprawdzenia tego na innym donglu USB/BT i ew nowszym systemie

Statystyki: Napisane przez mirekk36 — 16 cze 2013, o 00:39

"Przerywana" komunikacja z terminalem po RS232

2013-06-15T23:44:40+01:00

Witam,

mam nadzieję, że temat w dobrym miejscu, ale jeżeli nie to proszę modów o przeniesienie.

Ale do rzeczy. Mam problem z komunikacją po RS232 z wykorzystaniem modułu BTM-222 pomiędzy PC a uC (ATmega88PA na wew. 8MHz z podłączonym modułem BTM-222 i PC wraz z jakimś donglem BT od esperanzy, choć ze sterownikami, które pan Mirek polecał). Problem objawia się tak że czasami komunikaty docierające z uC do PC zawieszają się na terminalu i zamiast pojawić się pełna linijka: "Przykladowy ale za to dlugi tekst do testow!" na termianlu pokazuje się tylko "P" i koniec. Czasami po dłuższej chwili "doleci" reszta tekstu i nawet działa dobrze, a czasami komunikacja siądzie całkiem.

Co do kodu to używam obecnie dość mocno zmodyfikowanego przykładu z 2 książki pana Mirka dotyczącego komunikacji ASCII po RS232. (uzupełnionego o trik związany z uaktualnieniem wzoru na UBRR dla "nieprzyjaznych" częstotliwości). Jednak gdy wykryłem owy irytujący błąd odpaliłem "czysty" kod z książki, w którym jedynymi zmianami było odpowiednie dostosowanie nazw rejestrów konfiguracyjnych i bitów na te występujące w mojej ATmedze w pliku od obsługi uarta. I tutaj niestety ten błąd również napotkałem, czy to przy resetowaniu uC gdzie na początku przesyłany jest do terminala tekst powitalny jak i przy komendzie "ATI" która również przesyła do PC dłuższą linijkę tekstu. Jest to na tyle irytujące i budzi mój niepokój że postanowiłem poszukać rozwiązania tej kwestii teraz zanim przejdę do dalszych etapów własnego projektu.
Ponadto niejako przy okazji wspomnę też o tym, próba połączenia się z BTM-222 przy użyciu putty (prędkość 19200) często udaje się dopiero za którymś razem, wcześniej racząc mnie wielokrotnie komunikatem o niemożności połączenia.

Dodam, że posiadany przeze mnie moduł BTM-222 nie jest firmy Atnel, nie dolutowałem też jeszcze antenki w postaci drucika, moje podejrzenie trochę kieruje się w stronę problemów z zasięgiem (podyktowane tym iż właśnie pisząc te słowa ułożyłem w innym miejscu na biurku płytkę stykową z moim układem testowym i o dziwo KAŻDA próba podłączenia przez putty poszła bez problemu oraz komunikacja się nie wieszała), ale o rade czy to może to a może zupełnie coś innego proszę kolegów

Statystyki: Napisane przez keymaker — 15 cze 2013, o 23:44