Od kilku dni walczę z widocznością zmiennych i w sumie nic nie wymyśliłem.
Mam globalną strukturę
w common.h

w common.c


Następnie w common.c są funkcje które obsługują dane odebrane z UARTA przez system zdarzeń czyli


Niestety pomiar.masa, jest już niewidoczne w funkcji wysli_mase, tzn, jest to pusta zmienna (same zera).
Gdzie w wcześniejszych funkcjach wyświetlanie/przeliczanie etc. działa bez zarzutu, czyli po
memcpy(&pomiar.masa, &mybuf, sizeof(mybuf));
operujemu na pomiar.masa no i dlaczego po wyjściu z funkcji czytaj_dane_z_uart1 przestaje istnieć wartość w tej zmiennej?

czy ty nie robisz tu jakiejś strasznie niebezpiecznej rzeczy ? która może ci przy okazji "przeorać wszystko" jak radziecki traktor odrzutowy ?



czy jesteś pewien że rozmiar twojego mybuf jest DOKŁADNIE równy z ....

nie jeszcze gorzej .... myślałem że ty przekopiowujesz całą strukturę a tymczasem ty bez żadnego hmmmm no zastanowienia wkopiowujesz .... no właśnie żeby jeszcze wiadomo było co ? ... u ciebie w strukturze jest



więc teraz spróbuj wytłumaczyć co w ogóle wg ciebie ma robić ta linijka ? tzn czego ty od niej oczekujesz ?

i pomyśl co ona tak naprawdę robi ? to cię ciarki przejdą po plecach

Podpowiedź: przecież u ciebie masa w tej strukturze to NIE ZAINICJALIZOWANY wskaźnik .... więc jak myślisz gdzie lecą dane po tej operacji memcpy() ??? tym bardziej, że operatorem & jeszcze na dodatek próbujesz pobrać wskaźnik z tego wskaźnika

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

Pierwsza zmiana, definicja




Czyli memcpy(&pomiar.masa, mybuf, sizeof(pomiar.masa));
działa, co prawda co któryś raz dostaje głupoty hmmmm jak by if(*mybuf++ == '0') nie za każdym razem wyłapywał z przylatujących po uarcie
0000.279CR4000.770CRLF to co jest po pierwszym zero, bo pokazuje się czasem 000,279400 na uarcie i na LCD, czyli ewidentnie jeszcze gdzieś coś po drodze się kaszani

PS. Jest jakiś sposób na "dropowanie" niewłaściwych ramek?

A czy nie powinno być czasem bez operatora &pomiar.masa
czyli tak:
memcpy(pomiar.masa, mybuf, sizeof(pomiar.masa));

_________________
https://www.instagram.com/myfirstquadcopter/

W sumie wzorowałem się na


stąd ampersand.

Nie wiem czy dobrze rozumiem, ale na jedno w sumie wychodzi przy zmiennej globalnej, i użycie w moim wypadku &pomiar.masa to takie trochę masło maślane

Pewnie, że jest - tylko trzeba go sobie zrobić ... a ty na siłę od razu wrzucasz WSZYSTKO co przylatuje do bufora ... i dlatego masz kaszaneczkę ....

Najpierw panie trzeba sparsować bufor, sprawdzić co w nim jest, a jak dane się zgadzają to dopiero wtedy te właściwe dane BACH i do memcpy()

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

Hahaha, haha, ha, h.....

no właśnie próbuję coś urzeźbić .

tj.
coś na zasadzie sizeof(mybuf)==ilość bajtów w ramce, ale nie bardzo mi to wychodzi

Dokładniej mówiąc, nie bardzo mam pomysł jak sprawdzić że w mybuf jest właściwa ilośc bajtów, bo w sumie to powinno wystarczyć.

No bo co tak naprawdę dostajemy w mybuf? no dostajemy wskaźnik na bufor gdzie bufor, jest zapełniany przez obsługę zdarzenia tak w uproszczeniu, no i co, przylatuje mi pierwsza część
0000,279CR4000,771CRLF, gdzie if(*mybuf++ == '0') na dzieńdobry odrzuca mi po pierwsze, pierwsze zero, potem tylko gdy pierwsze 0 to następuje memcpy itp.
Nie rozumiem tylko dlaczego "przecieka" nie właściwa ramka? z wagi zawsze przychodzi prawidłowa (sprawdzałem to), same biblioteki twoje Mirku też działają prawidłowo, bo jeżeli wrzucić do obsługi zdażenia ot wysyłanie po prostu na drugiego UARTA też zawsze przechodzi prawidłowa ramka. Coś się dzieje po drodze u mnie na tych "cholernych" ifach, program sie nie wykrzacza, z przepełnianiem bufora przez złe korzystanie z wskaźników już sobie poradziłem, tylko dla czego if puszcza te dodatkowe "400"?

strlen(mybuf) .

Co masz na myśli mówiąc ramka z urządzenia jest nie zmienna, co do początkowych 0 i 4 to jedyne co można ustawić jako "nagłowek" rozróżniający dwie zmienne, masę i tarę innej opcji nie ma.
Co prawda kiedyś dawien, dawna, miałem podobny problem, a jak zacząłem grzebać w bibliotekach Mirka właśnie pod kątem wykrywania ilości danych dostałem tylko burę od Mirka to sobie odpuściłem grzebanie w bibliotece. No bo gdzie indziej, można by ograniczyć długość bufora, czy sprawdzać dokładnie ile przychodzi danych jak nie w samej bibliotece. Gdyż to ona rozdziela moją ramkę na dwie linijki.
U Mirka jest niby wykrywanie kolejnych linii, ale niestety to sie nie sprawdzi, jedynie co mi przychodzi na myśl to liczenie przylatujących znaków (bo zawsze jest

PS. w sumie głąb ze mnie bo wiedziałem, że wróci ten problem jak bumerang.

Tak wygląda ramka
30
30
30
31
2E
35
30
35
0D
34
30
30
30
2E
31
35
38
0D
0A

Czyli wychodzi na to, że jest zawsze 8 bajtów, nie licząc kodów rozdzielających linie.
Z tym, że interesujące jest to, że j/w już pisałem jeżeli zrobimy przekazywanie uart0 to uart1 czyli to co przylatuje na uart0 idzie na uart1, to nie ma błędów transmisji, mimo to że bufory dla uart0 i 1 są parzyste, a jak widać całkowita ilość bajtów dla uartów nie, chociaż w sumie analizując to co parsują biblioteki Mirka już na samym poziomie odbierania z bufora sprzętowego, tak naprawdę dostajemy tylko zapisywane jest tylko te 16bajtów bez kodów CR i LF

HA, rozgryzłem, to nie debouce, czy moja część softu, to LCD po i2c miesza w sofcie, po wywaleniu obsługi LCD nic się nie wykrzacza.

PS. coś się ewidentnie kaszani podczas obsługi SuperDebounce, tj. wpływa ona jakoś na błędne interpretowanie danych nadlatujących z bufora. Bo do puki nie nacisnę klawisza, dane przelatują bez zakłóceń .