Mam do wyrzucenia na uart dość długi ciąg i robię to następująco:

gdzie:

oraz:


Problemem jest, że raz dostaję przez UART ostatnią wartość (Pomiar_BAT) = 053 (co odpowiada napięciu zasilania x10 i jest zgodne z prawdą), a drugi raz 139 (nie wiem skąd).
Co więcej na zachowanie sprintf i/lub ADC ma zawartość w linii:
MKuart.h, ale co ma RX bufor wspólnego z TX?
Ponieważ mam użyte około 90% ram pomyślałem - STOS... ale nie!
Wyrzuciłem zmienną char MMC_Buff[512], zużycie RAM spadło do ~40% i dalej to samo

Co więcej - jak zmniejszę ten bufor o połowę tj. do 32, to dostaję:

I dodatkowo nie dostaję pozostałych danych, która są wysyłane przez UART w innym zdarzeniu...

Jak zwiększę do 64 bajtów to dostaję dane z obu zdarzeń*, ale wartość ostatnia szaleje jak wyżej.

Szczerze mówiąc już nie wiem gdzie szukać baboola
Sytuacja ulega naprawie gdy dam bardzo duży bufor odbiorczy - 128 bajtów i zmienną rx_buff > od bufora np. 130 bajtów.
Ale tym sposobem zaczyna brakować mi ramu po dodaniu bufora do zapisu na MMC. Najdłuższa linia NMEA ma ~75 bajtów, więc dodatkowe 50 to marnotrawstwo.

* - drugie zdarzenie to obsługa komend AT z dodanym kawałkiem służącym do parsowania NMEA...

_________________
Czekamy na RedBook'a!

Naucz się dzielić projekt na mniejsze kawałki. Sorki ale ja mało rozumiem z tego co opisałeś. Nie mówię tego złośliwie broń boże - po prostu nie wiem jak można na takim etapie szukać błędu ? podziel wysyłanie na mniejsze części i sprawdzaj mniejszymi krokami aż dojdziesz od którego momentu zaczyna ci coś iść w krzaki.

Poza tym piszesz o buforze odbiorczym - to ty coś odbierasz czy wysyłasz ? już się całkiem pogubiłem. Bo jak wysyłasz to w ogóle możesz zrezygnować nawet do testów z przerwań i buforów cyklicznych a nawet w ogóle nie buforować nadawanych rzeczy - tylko słać dane jedna po drugiej do UART'a - po co ten spritf() ??

No możliwości testowania jest milion a ty nawet z najmniejszej nie korzystasz tylko napisałeś kobyłę i z tego punktu widzenia szukasz problemu. A tu trzeba zacząć od źrebaka

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

No właśnie ciężko to nawet opisać jak się ma 90% dość skomplikowanego programu i nagle zaczynają się krzaki niewiadomego pochodzenia.
Ja odbieram dane z GPS'a, przetwarzam je i wysyłam oraz dodatkowo wysyłam dane w innym zdarzeniu, a to nikły % kodu.
sprintf jest ponieważ te dane trafią także do pliku na karcie (ale tego jeszcze nie dodałem).

Jak mam za mały bufor odbiorczy to wpływa mi to na wysyłanie i to jest dziwne... a błąd definitywnie powoduje sytuacja gdy bufor odbiorczy jest za mały i wąż zaczyna zjadać własny ogon.

LED się zapalił po czym zgasł... i dalej sobie "wesoło" mruga

_________________
Czekamy na RedBook'a!

Nie mam zielonego pojęcia czy akurat to ma wpływ, ale chyba tu jest coś nie tak



raczej powinno być

Też był krzak, ale to nie to...

Problem jest zidentyfikowany tylko nie do końca dla mnie zrozumiały.
GPS w stanie noFIX wysyła pakiet:

W sumie 193 znaki widzialne, 6x CRLF + liczne znaki puste.

Teraz mam bufor dajmy na to 32 bajty (domyślny).
Zdarzenie które ma za zadanie przechwycić linie i odesłać nie zmienione odsyła jedynie linie o ilości znaków < 32, tak?

Bo dostaję tylko:
a wszystkie one mają <32.

No to teraz zagadka - dlaczego jak zrobię bufor o pojemności 45 = najdłuższej z tych linii ($GPRMC = 43 znaki + [CR][LF]) to ta sama nie zmieniona funkcja odsyłająca pBuf nic mi nie odsyła?
W ogóle jak pojemność bufora nie jest potęgą 2 to nic się nie odsyła - musi być 32, 64 albo 128 i dopiero dla 128 bajtowego bufora wydaje się że jest dobrze.

_________________
Czekamy na RedBook'a!

No jeśli stosujesz jednak odbiór i buforowanie z użyciem buforów cyklicznych wg sposobu, który opisałem w książce to sorki ale tam jest to wyraźnie napisane i opisane jak działa i dlaczego bufor musi być potęgą 2 ...

podpowiedź jeśli nie będzie potęgą 2, to będzie złe maskowanie i wszystko się posypie ... zerknij do książki i do kodu to ci się wyjaśni (zwróć szczególną uwagę na maskowanie w celu kręcenia wskaźnikami w buforach)

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

I jeszcze jedno, akurat ta uwaga w procedurze obsługi przerwania którą zacytowałeś wyżej jest bardzo ważna i w drugiej książce, tej zielonej w ost. rozdziale, masz kompleksowo opisane jak podejść do całkowitej i pełnej obsługi tego przerwania jeśli teraz nie masz sam pomysłu jak to sobie zorganizować. Dodam że wtedy treść obsługi przerwania jest ściśle powiązana ze zdarzeniową obsługą uarta

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

No ciekawie, ciekawie...
Tylko po co w main.c taka kobyła
I jak to się dzieje, że jak zmniejszę ten bufor do [2] to też działa OK?

_________________
Czekamy na RedBook'a!

czy ty zdajesz sobie sprawę co to są bufory cykliczne ? gdzie są definiowane ? i o co tu chodzi ? bo wydaje mi się że w ogóle nie wiesz - po tym pytaniu

char bufor[100];

być może założyłem sobie na potrzeby obróbki wszystkiego w zasadzie. To tak samo gdy np działam z kartą pamięci i tworzę na jej potrzeby bufor 512 bajtów, to myślisz że co ? że na potrzeby stringów itp będę zaraz tworzył kolejny ? NIE ... jeśli tylko nie zachodzi obawa że dane się nadpiszą (trzeba odpowiednio konstruować program) to taki jeden bufor można wykorzystywać do wielu rzeczy.

Tymczasem polecam ci jeszcze raz zajrzeć do niebieskiej książki oraz do plików bibliotek UART'a i tam sprawdzić jak powstaje albo jak powstają bufory cykliczne - bo to całkiem inna rzecz od tego bufora.

Tymczasem twoje obecne doświadczenia jak widzę polegają - na ślepo - na zmniejszaniu czy zwiększaniu jakichś tam buforów bez zrozumienia do końca jakie one pełnią funkcje w programie i obserwacji czy coś ci działa czy nie.

Nie tędy droga.

W skrócie - jeśli mam sporo wolnej pamięci RAM to pozwalam sobie na parsowanie danych w oddzielnych buforach niż te cykliczne. Ale np gdy mam mało pamięci RAM a potrzebuję parsować np SMS'y .... i to w PDU, gdzie długość linii przekracza lekką ręką 160 albo i więcej bajtów to wtedy parsowanie robię "w locie" czyli "on line" w samych buforach cyklicznych. Ale myślisz że wszystko można tak szybko pokazać i wyjaśnić ???? robię to po kawałku dla lepszego zrozumienia. Niestety ty na razie nawet zasady pracy buforów cyklicznych nie poznałeś (szkoda) .... stąd twoje poważne kłopoty jak widzę ....

Więcej o parsowaniu masz w drugiej książce

a w trzeciej książce na pewno będzie o GSM/SMS/GPRS więc tam na pewno zobaczysz przykłady parsowania danych "w locie" czyli bezpośrednio w buforach cyklicznych.

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

Hihihiii no to już możemy zacząć tworzyć nieoficjalny spis tego co będzie w trzeciej książce

oooops już się włączył "podsłuch"

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

No i jednak...
Dodałem stack_monitor do programu i okazuje się, że RAMu brakuje
Niby RAM 430B zajęte przy programowaniu, ale w trakcie działania programu wyświetla mi 462B nigdy nie tknięte przez stos.
Nic dziwnego, że jak przyładuję 512B bufor dla petitfat to się zaczynają dziać cuda (1024 - 430 - 512 = 82, a stos już 132 zajmuje).
Tryb optymalizacji programu włączyć i ...

_________________
Czekamy na RedBook'a!

No jak widzisz z pamięcią RAM trzeba uważać - za dużo buforów i będzie problem

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

Jak idą prace nad obsługą sms? Aktualnie próbuję przebrnąć przez źródła żeby napisać program do odbioru i wysyłki sms (nokia). Czy znany jest orientacyjny termin ukazania się trzeciej części?