Dokładnie jak mówi kolega wyżej - a nie chodzi tu o to żeby na siłę ciebie przekonywać do zmiany końcepcji bo zrobisz jak zechcesz - ale żeby ci pokazać - podpowiedzieć jak można inaczej .... a przy okazji nie zakatować eeproma

_________________
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 i to jest to ,

Mirku mam jeszcze jedno pytanie odnoście tego kawałka kodu:



Rozumiem, że teraz flash_params znajduje się w pamięci flash, ale co by było gdybyśmy usunęli parametr PROGMEM ? Wtedy struktura będzie przechowywana w RAM?

No a jak myślisz - dlaczego jeśli zmienna ma być w eeprom to dodaje się np EEMEM ???

to jest podstawa podstaw w AVR GCC



nie ma innej możliwości - jak skasujesz powyżej specyfikatory POGMEM i EEMEM to wszystkie zmienne zostaną utworzone w RAM. To trzeba znać w dzień i w nocy

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

Więc gdybyś zrobił kolejny eksperyment i napisał to samo w asemblerze - to okazałoby się że jeszcze mniej miejsca zajmie cały program, zakładając że dobrze piszesz w asemblerze. Tylko czego to dowodzi? Co to jest 125 bajtów ? Liczy się wygoda, pewność i co ważne przejrzystość programowania i kodu. Dzięki temu idzie szybciej. W asemblerze też można - i to wszystko zrobić - tylko po co? Dlatego jeszcze raz podpowiadam, kolejną rzeczą, którą trzeba zrozumieć programując w C, że tu nie chodzi o to aby największą wagę odgrywało czy program zajmie o 125 bajtów więcej czy mniej - bo to kosmiczne nieporozumienie. Biorąc pod uwagę dyrektywy dla kompilatora, które np wykluczają z kodu jeszcze wszystkie nie używane funkcje ze stosowanych bibliotek, bardzo dobrą optymalizację w trybie -Os to takie rozważania na pewno mijają się z celem.

Wystarczy spojrzeć np na kod transmisji I2S w mojej drugiej książce, opisuję po kolei jak mało istotne jest np to, że w wyniku takiego rozwiązania jakie stosuję - zmarnowane zostanie o wiele więcej pamięci Flash ale za to szybkość wzrośnie nieporównywalnie więcej. Różnica wyszła jeszcze więcej niż 125 bajtów i co z tego. Kolejny przykład - funkcje typu INLINE .... toż one zdecydowanie wpływają na zwiększenie zajętości pamięci programu i co z tego?

Takich oszczędności o każdy bajt we flash to można było hmmm i nawet TRZEBA było szukać jak się pisało programy w Bascomie .... sam to bardzo ale to bardzo dobrze pamiętam (piszę z autopsji a nie jakieś tam pomówienia) .... dlatego tak szybko zacząłem szprycować Bascoma asemblerem żeby można było z niego jeszcze więcej wycisnąć.

Reasumując trzeba się przyzwyczaić że podczas programowania w C nie ma co się martwić tym czy program zajmie 100,200,300 czy 400 bajtów więcej czy mniej Każdy kto dłużej programuje w C w końcu to zrozumie. A jeśli zaraz ktoś podałby mi tu przykład że w ATtiny i to np ATtiny10 400 bajtów to już prawie połowa jego pamięci to mam inną odpowiedź ..... dla takiego procesora to się pisze programy w asemblerze i koniec i kropka W C też można ale coś delikatnego.

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

W ramach tego tematu... od początku śledzę ten temat, bo sam miałem z tym problem. Mój problem rozwiązałem (wydaje mi się) w bardzo prosty sposób:



Czy wszystko działa poprawnie ? mimo deklarowania na początku np. EEMEM int a=99;

Jeszcze raz WYRAŹNIE podkreślę, coś takiego w C:



to po prostu istna maskara amerykańską piłą tarczową (jak ktoś na tym forum się wyraził ) .... w biały dzień

sorki ale w tym wątku nawet już tyle razy pisałem o tym aby NIGDY nie dokonywać odwołań do bezpośrednich adresów w EEPROM ale jak groszkiem o ścianę .... jak widzę

no trudno - sorki ale po raz kolejny nie będę już tłumaczył - zabrakło mi sił - proszę więc dalej sobie tak działać - toż to zapis RODEM z Bascoma i bez żadnego przemyślenia niestety no przykro mi.

------------------------ [ Dodano po: 1 minucie ]

chodzi oczywiście o to 0x100, jakby ktoś się jeszcze nie domyślił

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

Spokojnie, robiłem tylko testy, oczywiście że wolałbym żeby kompilator sam znalazł odpowiednie miejsce.

Nie wiem dlaczego takie coś mi nie działa...

Kompilator nie jest po to żeby się zajmował znajdowaniem miejsca ..... To ty jako programista musisz się tym zająć.

Teraz już nieco lepszy przykład - tylko napisz co to znaczy że ci nie działa ??? opisz to jakoś ? napisz co miałeś na celu, a jaki efekt osiągasz i co ciebie nie satysfakcjonuje ? (tyle razy piszę żeby dokładniej opisywać swoje kłopoty) ... często dokładny opis pomaga w ogóle zrozumieć swój błąd ... a nie - "dlaczego TO nie działa" .... co nie działa ??? dla mnie tu wszystko działa .... Jak zrobiłeś tak masz. Zrozum, że nie każdy odczyta intencje programisty tym bardziej jeśli programista popełnia błędy w swoim kodzie - dlatego potrzeba dokładniejszego opisu.

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

W poprzednim przykładzie program co sekundę podwyższa wartość o 1 i zapisuje ją w pamięci. Po restarcie, najpierw ładuje wartość z pamięci a następnie kolejno podnosi o 1.

Natomiast w ostatnim przykładzie wszystko się kompiluje, nie ma błędów. Jednak nie wpisuje wartości do pamięci, a może wpisuje, ale nie odczytuje ? nie wiem, po restarcie zaczyna od 0.

Skoro w poprzednim przykładzie wszystko działało popranie, to nie sądzę żebym miał źle ustawione fusy. Problem pewnie w programie. Jednak próbowałem różnych kombinacji - bez sukcesu.

W nocie katalogowej oryginalna funcja zapisu i odczytu też wymaga podania adresu...




Nie testowałem tego jeszcze, ale w tych funkcjach też musiałbym podać adres.

Hass-pol Masz włączonego BOD? Bez tego na prawdę ciężko utrzymać dane w EEPROM. Sporo myszkowałem w internecie i dużo ludzi poleca układ ds1813 do resetu uC. Np atmega 8 ma tylko dwa bodlevele : 2,7V i 4V natomiast ds1813 potrafi zresetować uC przy spadku 5,10,15,20% od napięcia znamionowego(5V) Czy ktoś z forumowiczów testował ten układ ? W sieci jest wiele pozytywnych opinii zwłaszcza jeśli korzystamy z wewnętrznego EEPROM.

Normalny econo-RESET cz ęsto ich używam przy układach zasilanych z baterii lub pakietów
Jest ECO-Resetów kilka różnych zawsze można coś dobrać zależnie od potrzeb

Mam włączony BOD na 4V0. Nie sądzę żebym miał problem z zasilaniem, w poprzedniej wersji programu z bezpośrednim adresowaniem 0x100 wszystko działało.

taaak to dziwne że mi taki kod działa i po każdym restarcie zlicza od kolejnej wartości



żeby nie było niejasności - nie mam nawet włączonego żadnego BOD'a ani żadnych tam kontrolerów RESETu .... taki program MUSI działać. Nie będę robił i wklejał tu filmiku z działania bo to bez sensu przy tak prozaicznym przykładzie.

a jak by mi coś takiego nie działało - to bym szukał aż do bólu dlaczego nie działa - aż dotąd - dokąd bym znalazł rozwiązanie zamiast cofać się do epoki kamienia łupanego że tak powiem czyli do pisania obsługi eeproma prawie w czystym asemblerze

tylko tyle na to powiem

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

Postaram się wyjść z jaskini... i znajdę błąd. U mnie nie działa ten kod. Co prawda jeśli w ten sposób zapiszę uint16_t x EEMEM = 10; to zmienna "a" jest wyświetlana 10, więc odczyt z pamięci EEPROM i wpisanie wartości do "a" działa, problem z wpisaniem nowej wartości już w programie, tak myślę.

Jutro dalej będę dłubał... dziś już skończyła się jasność umysłu a włączyła pomroczność jasna Dziękuje Mirek za sprawdzenie, wierze że działa bo tak właśnie powinno to wyglądać, ale u mnie jak zwykle nie działa.

No dokładnie to podłub i napisz - bo nie ma co wracać do asemblera

poza tym jak już minie ci pomroczność jasna to zrób taki prosty program - bo mi się zdaje że ty to wplatasz w jakieś monstrum w którym coś jeszcze innego się dzieje ....

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

Jednak świeży umysł czyni cuda. Pomroczność jasna minęła i przyszło oświecenie.
Siedzę nad (jak na mnie) dużym projektem i czasami zapominam że pewne zmienne są tam od zawsze i jakoś je pomijam/zapominam.
Zapomniałem że mam już zmienne x i y - do współrzędnych panelu dotykowego... także wystarczyło zmienić

na

i poszło za pierwszym razem... ale głupota...
Dziękuję za pomoc.

To się zdarza, i ja to bardzo dobrze rozumiem, bo ileż razy i mnie zdarzy się zrobić taki błąd .... dokładnie taki ....

ale warto z tego wyciągać jeden wniosek i nie zapominać o nim .....

Gdy coś nie wychodzi tak jak powinno być to:

1. nie szukać przyczyn błędów w sprzęcie lub kompilatorze
2. nie szukać coraz prostszych a jednocześnie gorszych rozwiązań (bo coś tam działa)
3. DO UPADŁEGO szukać błędu we własnych poczynaniach

ja tu nie chcę mówić że ty szukałeś błędów w sprzęcie (pkt.1) nie o to mi chodzi - chciałem tylko po raz kolejny na forum w takim przypadku przypomnieć ważne CREDO jakie każdemu powinno przyświecać.


Ale też rozumiem że czasem jak człowiek jest zmęczony to różne myśli przychodzą tu też masz rację.....

Za to zawsze nowy dzień i wypoczęta mózgownica pomaga nam usunąć "pomroczność jasną" i o to 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 ]

Może by tego posta topic1591.html#p15892 jakoś przykleić, albo umieścić na twoim Blogu Mirku?. Brakuje troszkę takiego łopatologicznego opisu obsługi struktur, flash-ram-eeprom-ram. Czyli właśnie jakiejś konfiguracji zapisywanej w eepromie, domyślnej w flash, przywracania jej potem do eeproma itd.

Struktury i eeprom to praktycznie jedyne słuszne podejście, a na początku bardzo ciężko to zrozumieć, szczególnie, że odwołujemy się do zmiennych za pomocą & operatora wyłuskania adresu, oraz samo odwoływanie się do tablic w strukturach jest troszkę zagmatwane, przynajmniej na początku.

eeeh nie wyrabiam się normalnie - ale i to jest tematem przyszłego poradnika video jaki ma się ukazać. Na razie jednak cały czas trwają przygotowania do kręcenia tych poradników .... ale będą, będą jako uzupełnienia ćwiczeń do książek.

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

Witam,

Jestem tu nowy, aczkolwiek już kilkukrotnie skorzystałem z wiedzy wyczytanej na tym zacnym forum, za co niniejszym dziękuję.

Mam pytanie o powyższy zapis, wydaje mi się, że zawiera błąd. Zgodnie z dokumentacją avr-libc Reference Manual 1.4.7

6.13.3.4 void eeprom_write_block (const void  pointer_ram, void  pointer_eeprom, size_t n)
Write a block of n bytes to EEPROM address pointer_eeprom from pointer_ram.

pozdrawiam,
Grzegorz

Ale ja zwykle jak na szybko odpowiadam to prawie ZAWSZE się mylę z kolejnością argumentów do tych funkcji i zawsze też zalecam zajrzenie do właśnie PDF'a o którym wspominasz .... to jest podstawa.

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

Pyt 1. Jak i czy można samemu wybrać pod który adres chce sie umiescic swoją strukture ??


Pyt 2. Mam taką oto postać







i zeby powyzsze odczytać to musze to robić po koleji , czyli w takiej kolejnosci jak było zapisywane ??
czy mogę odczytywać na "życzenie" np detektor ?? ktory jak widzimy byl zapisany jako drugi

Pyt 3.

Jak chce zapisać dane do eepromu to wystarczy uzyć

czy muszę np w eclipsie właczyć opcje w ustawieniach projektu albo użyć avrdude ??

z tego co zrozumialem to nie da sie odczytać dowolnej struktury funckcją epprom_readblock ?
a co z tym zapisem do eppromu musze zapisać dwa razy , tnz. czy zapis eeprom_write... jest równoważny z zapisem np programem avrdude ?

Rozumiem, że dostęp przez strukturę jest wygodny i polecany, jeśli w EEPROMie zamierzamy trzymać jedynie jakieś ustawienia konfiguracyjne itp. - np. 100 czy 200 bajtów.

Ale co w sytuacji, gdy mamy na przykład ATMEGĘ 1284P z 4 kB EEPROMU i chcemy wykorzystać je w całości? Mam zmarnować 4 kB SRAM-u i 4 kB Flasha na powielanie struktur w taki sposób? Użytkownik zmieni 1 parametr z kikuset, a ja już mam wysyłać do EEPROMu całe 4 kB? Przecież to trwa.

Albo lepiej - zewnętrzny EEPROM 128 kB. Dla mnie świetna sprawa, żeby zapisywać historię zdarzeń itp. Jak to wtedy obsłużyć?

Czy zatem zapis bezpośredni zawsze jest złem? A może sugerujecie podzielić w takiej sytuacji przestrzeń EEPROMu na przykład na wiele struktur po 1 kB? Nie krytykuję, pytam.

Pozwolicie,że się podepnę z pamięcią FLASH

Mam zadeklarowane trzy struktury w d_led.h. Każda z tych struktur steruje parametrami innej diody RGB,


Następnie mam zadeklarowane trzy struktury w w pliku memory.h

Oraz ich definicję w memory.c


Kompilator zwraca mi ostrzeżenia do pierwszych linijek (0,0,0,125,255,255,//defoult_set_color,) we wszystkich trzech strukturach w postaci:


Jakich nawiasów on się domaga?

Odgrzeję troszkę kotleta

Po wykonaniu tego kodu:



pamięć przedstawia się następująco:



co by oznaczało, że do EEPROMU zapisała się tylko jedna zmienna t1=1. Dlaczego reszta zmiennych się nie zapisała zaraz po niej? Przecież są zorganizowane w ramach jednej struktury i dlaczego wpisało się akurat w tamen adres a nie od pierwszego zgodnie z tym co mówił Mirek?

Podajesz w złej kolejności parametry do eeprom_write_block. Powinno być: adres_w_ram, adres_w_ee, długość_danych.

Ok, zmieniłem kolejność i teraz nic nie zapisuje się do EEPROM. Wszystkie komórki pamięci przyjmują wartość 0xFF.

Czym sprawdzasz zawartość eeprom?