Ponieważ jest to mój pierwszy post tutaj witam wszystkich forumowiczów oraz Pana Mirka, dzięki któremu moja przygoda z mikrokontrolerami nabrała tempa.

Piszę ponieważ borykam się z pewnym problemem i nie wiem jak sobie z nim poradzić, albo z czego on wynika.

Otóż w programie mam zdefiniowaną banalną wręcz strukturę o takiej postaci:


strukturę wykorzystuje ako formatkę do zapisywania danych w eeprom. Stąd takie definicje:


w momencie startu aplikacji dokonuje weryfikacji czy zawartość EEPPROm jest ustawiona i jeśli nie wczytuje wartości domyślne, dokonuje również weryfikacji poprawności zakresu


Po debugach jakie wykonałem, sam zapis danych ze struktury param_ram do pamięci EEPROM zachodzi prawidłowo.

Problem jest natomiast z przepisaniem wartości param_ram = param_tmp;

Niewiedzieć czemu gdy program wykryje, że pamięć eeprom nie jest ustawiona i dokonuje przypisania wartości domyślnych do zmiennych w ram (a później do eeprom) to struktura param_ram nie ma danych z param_temp tylko jakies z kosmosu.

trochę eksperymentowałem i co ciekawe mogę ten problem wyeliminować na dwa sposoby, ale uważam je nie do końca za właściwe rozwiązanie, stad też mój post w tej sprawie.

Pierwsze rozwiązanie to zastąpienie przypisania całkowitego struktury na takie cząstkowe, zmienna po zmiennej


ale wiadomo tracimy w ten sposób pełna elastyczność tego rozwiązania i gdy tyko dojdzie kolejną zmienną, to musimy ją w tym mechanizmie uwzględnić.

Drugie rozwiązanie które w tym przypadku wyeliminowało problem to zamiana typu pierwszej zmiennej z uint8_t na uint_16t tak żeby wszystkie zmienne w strukturze miały ten sam typ:


Ale oczywiście nie zawsze jest to możliwe do wykonania.

Przypuszczam ze mechanizm miesza typy albo stosuje jakies dziwne rzutowanie przez co wartości w rejestrach są w jakiś nieprzewidywalny sposób mieszane ze sobą.

Pytanie dlaczego?

_________________
Producent stopu do cynowania PCB we wrzątku.

A może wyjaśnij co to jest: ReadStructureFromEeprom()? u ciebie
bo ta konstrukcja

param_tmp = ReadStructureFromEeprom();

wygląda mega przedziwnie i to tu rodzą się pewnie same problemy. Przy okazji oglądałeś dokładnie to?
http://mirekk36.blogspot.com/2012/11/av ... iazek.html

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

Tak czytałem to właśnie wczoraj łącznie z uważnym obejrzeniem filmu żeby sprawdzić czy czegoś nie przeoczyłem.

Definicja tych funkcji jest następująca:



czyli jak mi się wydaje standardowy sposób zapisu i odczytu z i do eeprom.

Jednak jak pisałem robiłem sobie debuga na wyświetlaczu LCD przed instrukcja:



i stwietrdziłem że po podpięciu sobie takiego debuggera:



parametry pobrane na starcie z eeprom (param_tmp) są następujące 255 i 65535 czyli prawidłowo.
parametry domyślne zapisywane do param_ram (param_def) wynoszą 1 i 0 czyli również prawidłowo.
natomiast odczyt wartości z param_ram zaraz po ich zapisie wynoszą nie wiedzieć czemu 0 i 12288.

definicja lcd_uint jest taka:



i jest drobną modyfikacją funkcji lcd_int z Twojej biblioteki dołączonej do książki (jedyna różnica to zmiana sposobu konwersji zmiennej itoa() na utoa().

_________________
Producent stopu do cynowania PCB we wrzątku.

No niestety - tak jak zauważyłeś - "wydaje" ci się

szczególnie to jest koszmarek



Tak się nie robi, co to ma być return temp ? Przenosisz "po stosie" całe struktury może i tablice ? A w środku (o zgrozo ) jeszcze odwołanie się do zmiennej globalnej param_eem - to można nazwać prawdziwym "salto mortale" i praktycznie pokazuje ten przykład jak NIE NALEŻY pisać funkcji.

Zobacz można to było (zamiast tej twojej funkcji zrobić tak)



i już byłoby dobrze, a ty powołujesz zmienną globalną param_temp, potem jeszcze w środku funkcji drugi raz temp (to samo) i jeszcze chcesz przekazywać rezultat (tą strukturę) przez wartość a nie przez wskaźnik ....

jeśli funkcja to np:



Tyle tylko - że to wychodzi takie troszkę masło maślane bo powtórzenie funkcji eeprom_read_block()

No ale po wykonaniu jednej z tych dwóch wyżej podanych funkcji uzyskasz napełnienie swojej zmiennej globalnej param_temp danymi z eeprom

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

faktycznie dane z pamięci eeprom można przekazać bezpośrednio do zmiennej param_temp oszczedzając parę bajtów pamięci ram, ale by zyskać na czytelności kodu wyżej postanowiłem zostawić jeszcze jedna tymczasową wartość tak by w kodzie zwrot danych był wykonany w sposób jawny.
Niemniej mimo że wykorzystywany jest do odczytu "potworek" to ten fragment kodu działał bez zarzutu.

Moje pytanie dotyczyło fragmentu kodu który generalnie nie ma później już nic wspólnego z odczytem i zapisem w pamięci EEPROM (bo problem pojawia się pomiędzy prawidłowym odczytem danych z eeprom a przed zapisem ich do pamięci).

Na chwile obecną dokonałem zmiany swoich funkcji zapisu/odczytu do/z eem na "książkowe"



a wlasciwy fragment przywracający zmienne z eem wygląda tak:



oczywiście niezmiennie definicje:


z debuga otrzymuje infomracje że zapisuje wartości domyślne 1 i 0 ale po zapisie ich do ram (nawet jeszcze zanim zapiszuje je do eemem - co wynika z kodu) kolejny debug podaje mi ze w do ram nie zapisano 1 i 0 a 0 i 12288.

dodatkowo na książkowej metodzie otrzymuje obecnie warningi:



wskazują one odpowiednio na linijki:

eeprom_read_block( &param_ram, &param_eem, sizeof(param_ram) );
oraz:
eeprom_write_block( &param_ram, &param_eem, sizeof(param_ram) );

_________________
Producent stopu do cynowania PCB we wrzątku.

Ja nie rozumiem o co tu chodzi

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

Nie wiem jak to prościej wyjaśnić, ale nie rozumiem dlaczego gdy w strukturze mam zmienne różnych typów i operuje na grupie wartości tego i samego typu (T_PARAMS) to po zapisie wartości param_def = {1,0} do param_ram i natychmiastowym odczytaniu wartości z param_ram mam zamiast wartości {1,0} mam {1,12288}

_________________
Producent stopu do cynowania PCB we wrzątku.

No skoro masz LCD do dyspozycji to jest o wiele łatwiej szukać babolka, pokaż ten fragment po którym rzekomo "same" się zmieniają wartości. Poza tym sam sobie też wyświetl na LCD wartość przed i wartość po.

Wklej później ten fragment kodu tutaj

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

już wklejałem ale wkleję jeszcze raz:



fragment kodu z linijki od 27 do 30 wyswietla prawidłowe wartości domyślne ze struktury param_def i otrzymuje w wyniku tego prawidłowe wartości {1, 0} zdefiniowane one sa w linijce 6 kodu.

natomiast po przypisaniu zmiennej param_def do param_ram w linijce 32 i wyświetleniu zawartości zmiennych w strukturze param_ram w linijkach 36 do 39 otrzymuje nie wiedzieć czemu wartości {0, 12288}

jeśli przepisania zmiennych pomiędzy param_ram i param _def wykonuje po sztuce (dokładnie w taki sposób jaki pokazują to zakomentowane linijki 33 i 34) to zmienne w drugim kroku debuga zwraca prawidłowe wartości.

dodam ze problem nie występuje jeśli w definicji struktury zamiast uint8_t zastosuje uint16_t dla pierwszej zmiennej (czyli wtedy gdy wszystkie zmienne w strukturze są tego samego typu)

Co robie nie tak ? Czy zapis

jest nieprawidłowy ?
Nie wydaje mi się że sytuacja gdzie zmienne w strukturze są różnych typów to sytuacje niedopuszczalne ? Ale z AVR'ami dopiero zaczynam więc mogę mieć w wielu miejscach spore braki :/

_________________
Producent stopu do cynowania PCB we wrzątku.

Sorki wcześniej umknął ten babol mojej uwadze.


No widzisz - sam doszedłeś do błędu. Oczywiście że tak nie można sobie kopiować struktur w C .

Tak można robić ze zwykłymi zmiennymi, a nie ze złożonymi strukturalnymi .

------------------------ [ Dodano po: 2 minutach ]

możesz skopiować np za pomocą memcpy().

To mniej więcej tak jakbyś chciał stringi obsługiwać w ten sposób w C



Jak myślisz dlaczego tak nie można? i dlaczego są funkcje kopiujące zawartości stringów itp ?

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

A no właśnie to mi umknęło, pokombinuje i myślę że powinno działać lepiej.

_________________
Producent stopu do cynowania PCB we wrzątku.

Mówię na szybko będzie można użyć i łatwo funkcji 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 ]

użyłem tej funkcji i działa prawidłowo

Co ciekawe jeśli stosuje książkowy zapis:


To otrzymuje takie warningi :



gdy natomiast stosuje te zapisy dodatkowe które gdzieś wyszperałem (ale jeszcze nie bardzo rozumiem ich istotę działania)


Warningi znikają, a wtedy funkcje nieweiel się różnią od tych które na wstępie zostały uznane za potworki ... jedyna różnica to bezpośrednie odwołanie się do struktury param_ram bez pośrednictwa struktury tymczasowej T_PARAM temp.

Jeszcze raz dziękuje za pomoc.

_________________
Producent stopu do cynowania PCB we wrzątku.

Już któryś raz powtarzasz coś o książkowym zapisie - mógłbyś wyjaśnić w czym rzecz ? o jaki książkowy zapis chodzi albo z jakiej książki ? tak z ciekawości pytam

Poza tym zwróć uwagę jakiego babola robisz w tym niby książkowym zapisie - pokażę to tak:



Nie brakuje ci na oko przed tym argumentem pokazanym na czerwono operatora pozyskiwania adresu & ??? ... bo to właśnie przez to masz ten błąd:


jeśli to poprawisz:



to MUSI się dobrze skompilować

------------------------ [ Dodano po: 10 minutach ]


No ale może nie zrozumiałeś poprzedniej mojej wypowiedzi. Ta "potworkowatość" nie wynikała z tych rzutowań na niejawny typ wskaźnikowy

(const void*)

bo to jest normalne ale wolałbym tego nie używać jeśli nie trzeba - a jak widać - co pokazałem wyżej, nie trzeba

tylko "potworkowatość" wynikała właśnie z tego powołania na stosie zmiennej automatycznej (lokalnej) strukturalnej i przekazaniem za pomocą return struktury przez wartość (a nie wskaźnik) co właśnie WPROST prowadziło cię dalej na manowce do zapisu typu



rozumiesz ?

Zaś taki zapis:

jest jawnym rzutowaniem na nieokreślony typ wskaźnikowy void* .... i jeśli nie trzeba go stosować - to ze względu na dobrą praktykę programowania nie warto go używać bo zaciemnia obraz. Lepiej przyjrzyj się nagłówkowi tej funkcji



proszę bardzo:



widzisz ? już tu masz na poziomie argumentów typ wskaźnikowy void* .... wiesz dlaczego ? Ano dlatego żeby nie było warningów podczas przekazywania wskaźników różnych typów do tejże funkcji czyli zmienna np __src przed wywołaniem funkcji może być zarówno np typu char jak i uint8_t albo i uint16_t albo int i inne i za każdym razem nie będzie zgłoszenia warninga, ponieważ argumenty są typu void* czyli TYP argumentu określany jest na etapie wywołania funkcji w kodzie. Musisz troszkę jeszcze podczytać o typie void* ... albo obejrzeć zdaje się mój poradnik:

http://mirekk36.blogspot.com/2012/12/ws ... a-bez.html

tam poruszam to ważne zagadnienie - o co chodzi z void* i kiedy ew warto/można czy powinno się użyć takiego rzutowania (void*)

_________________
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 dokładnie, mi chodzi o to, że ten typ "nieokreślony" skoro już jest użyty dla argumentów tej funkcji to właśnie po to aby mogły one przyjąć dowolny typ gdy funkcję wywołujemy. Dlatego wydaje mi się, że nie ma sensu pisać w ten sposób



bo spokojnie można tak:



niezależnie jakiego typu będzie buf[].

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

Nawet jeśli kompilator zwraca z tego powodu warninga ?

_________________
Producent stopu do cynowania PCB we wrzątku.

Nie no jak warning to zdecydowanie wolałbym zrobić rzutowanie. Ale przecież przy tej funkcji nie masz warninga

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