Dzień dobry.

Witam wszystkich - to mój pierwszy post.

Usart po raz kolejny, bo przejrzałem chyba wszystkie posty na ten temat, ale wciąż czegoś nie mogę pojąć.
Biblioteki Mirka z zielonej książki. Urządzenie pracujące jako slave (kilka lat pracowało bezbłędnie pod Bascomem, teraz w ramach nauki C próbuję przepisywać programy moich urządzeń z Bascoma na C). Jego zadaniem jest odczytywać temperatury z czujników DS1820 (czterech) i na żądanie mastera wysłać wyniki. Będąc na etapie książki niebieskiej, stworzyłem kod pozwalający realizować to zadanie, ale w sposób trochę prymitywny. W pętli głównej jedną z instrukcji było


Po zakupie i przeczytaniu książki zielonej chciałem to zrobić prawie jak komendy AT, ale na początek prościej. Układ działa, ale trochę dziwnie. Po resecie mikroprocesora, w odpowiedzi na odpowiedni ciąg znaków z mastera, w buforze pojawiają się na początek dwa przypadkowe znaki (o kodach 67 i 225 a dopiero po nich znaki wysyłane przez mastera). Co ciekawe, jeśli ręcznie zmuszę mastera do wysłania ponownie sekwencji znaków, program zaskakuje i działa dobrze do najbliższego resetu. Tak jest przy komunikacji (po RS485) z masterem. Jeśli podłączam terminal i łącze się po RS232, pierwsze wysłanie odpowiednich znaków nie wywołuje żadnej reakcji, dopiero drugie powoduje "zaskoczenie" programu jak powyżej.

Podejrzewam, że problem może być w okolicach funkcji UART_RX_STR_EVENT(char * rbuf), albo uart_getc(void), albo uart_get_str(char * buf), albo w przerwaniu odbiorczym. Nie wiem np. po co w funkcji "..get_str" jest warunek

if( ascii_line )...

Przecież funkcja ta jest wywoływana tylko w jednym miejscu (UART_RX_STR_EVENT) pod warunkiem, że "ascii_line" i tak jest różne od zera....?

Wstawię tu pełny kod, gdyby komuś chciało się rzucić okiem i coś podpowiedzieć, byłbym wdzięczny.



W plikach mkuart.c i mkuart.c raczej mało grzebałem, ale na wszelki wypadek:

[ posłuchaj zasada i moja prośba jest taka - aby nie publikować na forach bibliotek z książki - no chyba że sam je znacznie przerabiasz ok ? .... mirekk36 ]


pozdrawiam wszystkich

jest właśnie po to, że można tą funkcję get_str() używać niezależnie albo nawet bez wywoływania zdarzenia USART_EVENT() rozumiesz ?

pomyśl - gdy nie używaż ZDARZENIA, a tylko get_str() ... to jeśli nic nie pojawiło się w buforze - to po co ma coś być sprawdzane ? następuje od razu opuszczenie funkcji. Dopiero gdy pojawiła się linia (ramka) to funkcja ładnie zareaguje i zwróci ci odebraną linię

------------------------ [ Dodano po: 6 minutach ]



No widzisz ... po PIERWSZE masz do tej funkcji ładnie przekazany wskaźnik bufora *pBuf a ty posługujesz się niepotrzebnie tablicą bufor[]

Po DRUGIE - twoje kłopoty ze zrozumieniem działania tego parsowania wcale mnie nie dziwią, bo to co robisz wyżej świadczy, że troszkę rzuciłeś się na zbyt głęboką wodę .... i na razie w ogóle nie rozumiesz wskaźników ..... więc nie dziw się, że tu wszystko wydaje ci się obce i niezrozumiałe

gdybyś po drodze czyli dużo wcześniej poćwiczył wskaźniki to szybko byś zrozumiał jak porównywać stringi w C , zresztą przykłady masz w zielonej książce w tym rozdziale o parsowaniu - no WŁAŚNIE ale tam jest sporo o wskaźnikach

widzisz tam funkcje:



i podobne ?

przecież to dzięki nim można sobie pięknie porównywać to co wpadło ci do bufora np:



poczytaj sobie jak działa taka funkcja i podobne ....

ale jednak najpierw zabierz się mocniej za wskaźniki i ćwiczenia z pierwszej książki a jak czegoś nie rozumiesz to śmiało pytaj, nawet łap mnie na Skype - zawsze chętnie pomogę jak będziesz miał jakieś konkretne pytanie - zapraszam.

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Dzięki za tak szybki odzew.

Już po wysłaniu tej wiadomości przyszło mi do głowy, że powtórzenie tego warunku sprawia, że funkcja jest bardziej uniwersalna i może ktoś chcieć jej użyć w inny sposób niż przez to zdarzenie.
W bibliotekach z książki trochę grzebałem i nie jestem pewien, czy czegoś tam nie zepsułem, dlatego je zamieściłem.
Z tym buforem i wskaźnikiem do niego od razu coś mi nie pasowało. Pomyślę jeszcze o tym. Ze wskaźnikami u mnie faktycznie bardzo kiepsko, miałem nadzieję zacząć coś ćwiczyć na żywym organiźmie, bo sucha teoria trudniej do mnie trafia. W masterze, który będzie musiał rozebrać te dane i reagować odpowiednimi akcjami na poszczególne temperatury, nie obejdzie się bez szczególowego zrozumienia Twojego pliku AT.c i funkcji, o których piszesz. Tutaj zasugerowałem się faktem, że na początku tego pliku, zanim jeszcze zaczynasz parsować zawartość bufora, wysyłasz
jego zawartość na LCD prostym poleceniem lcd_str(pBuf) - myślałem, że skoro można go tak po prostu wyświetlić (a także - sprawdziłem to - wysłać na terminal poleceniem uart_puts(pBuf)), to również można go w prosty sposób porównywać. To jest proste urządzenie (w Bascomie poszło mi z nim bardzo łatwo) i miałem nadzieję "szybko" to załatwić, żeby mieć układ wysyłający dane, które już w masterze móglbym szczegółowo rozgryzać, analizować i parsować z wykorzystaniem specjalistycznych funkcji. Widzę, że niezbędne będzie to "rozgryzanie" już w tym slavie.
Jeszcze poczytam i odezwę się.

pozdrawiam

No ale ja właśnie suchej teorii jak widzisz mało napisałem w niebieskiej książce - za to ZDECYDOWANIE przeniosłem przykłady do części praktycznej czyli do rozdziałów warsztatowych - tam gdzie piszemy przykładowe różne biblioteki .... tylko czasem czytelnicy pomijają sobie co niektóre rozdziały sądząc, że ja po prostu zaparłem się aby komuś na siłę pokazać jak zrobić sobie np samemu obsługę do: LCD, multipleksowania, RC5 itp itd

tymczasem jest CAŁKIEM INACZEJ - ponieważ do mnie też o wiele lepiej trafia praktyka niż sucha teoria to postanowiłem tą teorię przekazywać przy okazji na ciekawych przykładach - dlatego warto czytać po kolei te wszystkie rozdziały i z niebieskiej i zielonej książki bo uwierz mi, że po kolei robię TYLE ćwiczeń tzn jak najwięcej żeby na końcu drugiej (zielonej) książki przejść do fajnej obsługi UART'a

Jak widzisz nie przypadkowo jest to OSTATNI rozdział nie przypadkowo

ale w miarę czytania i ćwiczenia wskaźników śmiało pytaj ... bo to warto jak najszybciej zaskoczyć a przynajmniej ich dobre podstawy

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Okazało się, że problem był jednak w sprzęcie, a ściślej mówiąc w transmisji RS485. Dawno temu, na potrzeby jakiejś aplikacji (chciałem odbierać dane z jednego układu i posyłać je wraz z innymi danymi do innego układu a miałem tylko jeden USART - nie chciałem w tamtym konkretnym przykładzie stosować UARTA'a programowego) trochę na zasadzie "ciekawe, czy się uda" połączyłem bezpośrednio dwa transcivery MAX232 oraz MAX485. To znaczy, do pinu RXD procesora podłączyłem jednocześnie piny RX MAX485 i MAX232 a do TXD procka odpowiednie piny Max'ow. Układ działał (zresztą pracuje do dziś), tyle tylko, że należało restrykcyjnie pilnować sterowania w odpowiednich momentach pinami sterującymi "485" - stan tego pinu miał także wpływ na możliwości pracy MAX232. Tutaj to przeoczyłem, stąd problemy, o których pisałem na początku.

Czyli "od... się pan od mojego programu" mógłby powiedzieć Mirek i miałby rację.
Wracam do wskaźników, bo przy okazji szukania błędów w programie zobaczyłem swoje braki.







Nie wiem, jak się zamyka temat...

Na naszym forum nie ma takich rzeczy

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]