ATNEL tech-forum

Re: Dziwne zachowanie ADC i/lub UART? Możliwe?

2012-10-09T21:35:43+01:00

mirekk36 napisał(a):

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.

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?

Statystyki: Napisane przez main.c — 9 paź 2012, o 21:35

Re: Dziwne zachowanie ADC i/lub UART? Możliwe?

2012-09-21T21:59:21+01:00

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

Statystyki: Napisane przez mirekk36 — 21 wrz 2012, o 21:59

Re: Dziwne zachowanie ADC i/lub UART? Możliwe?

2012-09-21T21:56:31+01:00

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 ...

Statystyki: Napisane przez szopler — 21 wrz 2012, o 21:56

Re: Dziwne zachowanie ADC i/lub UART? Możliwe?

2012-09-21T12:21:59+01:00

Malutki_27 napisał(a):

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"

Statystyki: Napisane przez mirekk36 — 21 wrz 2012, o 12:21

Re: Dziwne zachowanie ADC i/lub UART? Możliwe?

2012-09-21T12:06:25+01:00

mirekk36 napisał(a):

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.

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

Statystyki: Napisane przez Malutki_27 — 21 wrz 2012, o 12:06

Re: Dziwne zachowanie ADC i/lub UART? Możliwe?

2012-09-21T11:21:43+01:00

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.

Statystyki: Napisane przez mirekk36 — 21 wrz 2012, o 11:21

Re: Dziwne zachowanie ADC i/lub UART? Możliwe?

2012-09-21T11:09:49+01:00

No ciekawie, ciekawie...
Tylko po co w main.c taka kobyła [syntax=c]char bufor[100];// bufor na potrzeby odebranych danych z UART[/syntax]
I jak to się dzieje, że jak zmniejszę ten bufor do [2] to też działa OK?

Statystyki: Napisane przez szopler — 21 wrz 2012, o 11:09

Re: Dziwne zachowanie ADC i/lub UART? Możliwe?

2012-09-21T03:56:38+01:00

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

Statystyki: Napisane przez mirekk36 — 21 wrz 2012, o 03:56

Re: Dziwne zachowanie ADC i/lub UART? Możliwe?

2012-09-20T23:59:09+01:00

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)

Statystyki: Napisane przez mirekk36 — 20 wrz 2012, o 23:59

Re: Dziwne zachowanie ADC i/lub UART? Możliwe?

2012-09-20T23:31:36+01:00

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:

Quote:

$GPGGA,000313.04,,,,,0,0,,,M,,M,,*7D
$GPGLL,,,,,000313.04,V,N*4F
$GPGSA,A,1,,,,,,,,,,,,,,,*1E
$GPGSV,1,1,00*79
$GPRMC,000313.04,V,,,,,0.000,,060180,,,N*59
$GPVTG,,T,,M,0.000,N,0.000,K,N*2C

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?
[syntax=c]int8_t NMEA_PARSER(char * pBuf) {
uart_puts(pBuf);
uart_puts(CR);
return 0;
}[/syntax]
Bo dostaję tylko:

Quote:

$GPGLL,,,,,000313.04,V,N*4F
$GPGSA,A,1,,,,,,,,,,,,,,,*1E
$GPGSV,1,1,00*79

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.

Statystyki: Napisane przez szopler — 20 wrz 2012, o 23:31

Re: Dziwne zachowanie ADC i/lub UART? Możliwe?

2012-09-20T23:02:11+01:00

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

[syntax=c]ADMUX = (ADMUX & 0b11100000) | kanal;[/syntax]

raczej powinno być

[syntax=c]ADMUX = (ADMUX & 0b11111000) | kanal;[/syntax]

Statystyki: Napisane przez Malutki_27 — 20 wrz 2012, o 23:02

Re: Dziwne zachowanie ADC i/lub UART? Możliwe?

2012-09-20T22:21:29+01:00

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.

Quote:

// tutaj możemy w jakiś wygodny dla nas sposób obsłużyć błąd spowodowany
// próbą nadpisania danych w buforze, mogłoby dojść do sytuacji gdzie
// nasz wąż zacząłby zjadać własny ogon

PORTB ^=(1<

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

Statystyki: Napisane przez szopler — 20 wrz 2012, o 22:21

Re: Dziwne zachowanie ADC i/lub UART? Możliwe?

2012-09-20T22:05:42+01:00

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

Statystyki: Napisane przez mirekk36 — 20 wrz 2012, o 22:05

Dziwne zachowanie ADC i/lub UART? Możliwe?

2012-09-20T21:27:34+01:00

Mam do wyrzucenia na uart dość długi ciąg i robię to następująco:
[syntax=c]
sprintf(CSV_Tx_Buff ,"%02u/%02u/%02u;%02u:%02u:%02u;%10lu;%10lu;%10lu;%10lu;%3u;%3u",
(u08)RTC_Time.D, (u08)RTC_Time.M, (u08)RTC_Time.Y, (u08)RTC_Time.h, (u08)RTC_Time.m, (u08)RTC_Time.s,
PULSE.A, PULSE.B, PULSE.C, PULSE.D, Pomiar_HV, Pomiar_BAT);
uart_puts(CSV_Tx_Buff);
uart_putc('\r');[/syntax]
gdzie:
[syntax=c]void obsluga_baterii(void) {
if (_FLAGA.BATCheck == _Set) {
Pomiar_BAT = (151UL*obsluga_adc(6)) / 1000UL;
_FLAGA.BATCheck = _Rst;
}
}[/syntax]
oraz:
[syntax=c]u16 obsluga_adc(u08 kanal) {
ADMUX = (ADMUX & 0b11100000) | kanal; // ADMUX & maska (zachowaj to co już jest ustawione) i ustaw 3 ostatnie bity - nr kanalu
sbi(ADCSRA,ADSC); // Start konwersji ADC
while (ADCSRA & (1< return ADCW; // Zwroc wynik konwersji
}[/syntax]

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:
[syntax=c]#define UART_RX_BUF_SIZE 32[/syntax] 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ę:
[syntax=txt]09/00/00;02:44:11; 2; 2; 2; 2;400; 53
09/00/00;02:44:15; 3; 3; 3; 3;402; 28
09/00/00;02:44:21; 4; 4; 4; 4;399; 0
09/00/00;02:44:24; 5; 5; 5; 5;400; 53[/syntax]
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...

Statystyki: Napisane przez szopler — 20 wrz 2012, o 21:27