Witam
Mam taki oto zestaw do zapisania w EEPROM

Gdy projekt miałem skompilowany WinAVR'em nInCount i nOutCount były na początku EEPROM'a. Po kompilacji toolchainem atmela te dane wylądowały na końcu zestawu danych zapisanych w EEPROM. Pomyślałem że może uda mi się wymusić kolejność za pomocą struktury.

Niestety oglądając plik eep widzę różne zawartości jednej i drugiej deklaracji.
Pytania:
1. Czy można w języku C wymusić lokalizację zmiennej w pamięci EEPROM.
2. Czy dane zapakowane w strukturę zapisują się inaczej niż te zadeklarowane niejako osobno? Raczej tak ale z czego to wynika?

_________________
sig off ;(

1. można ale lepiej powiedz do czego ci to - bo nie ukrywam że to nieco pozbawione sensu gdy programuje się w C

2. zapisują się inaczej , Ba! nawet nie masz gwarancji że po kolejnej kompilacji albo dodaniu jakiejś zmiennej zostanie zachowana lokalizacja wcześniejszych. Od czego to zależy - od optymalizatora (procesów optymalizacji) ... a ty chcesz wrócić do czasów sprzed C gdy nie było optymalizatorów.

Na szczęście właśnie programując w C nie trzeba o takich sprawach myśleć i to jest zaleta a nie wada.

Myślę, że czas najwyższy kolego obejrzeć dokładnie ten poradnik:

http://mirekk36.blogspot.com/2012/11/av ... iazek.html

i zobaczyć w jaki sposób podchodzi się do EEPROMA w C

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

Ano potrzebne jest mi to do tego, że na pececie obrabiam sobie wyciągnięty obraz pamięci EEPROM i potem tą obrobioną zrzutkę chcę wgrać z powrotem do urządzenia. Stąd potrzebna mi jest stałość położenia danych w EEPROM'ie. Wiem, wiem. Mogę to zrzucić na kontroler i wyciągać i wkładać EEPROM np. przez bootloader UARTEM. Tyle że bootloader i właściwy wsad muszą widzieć to samo. A jak mam bootloader napisany po staremu a właściwy HEX po nowemu to będą widziały co innego?. Bootloaderów nie trenowałem i jeszcze tego nie umiem, choć mam w planach ugryzienie tego tematu. Tymczasem mam taki patencik polegający na wyciągnięciu AVRDude'm z procka zawartość EEPROM'a zaczytanie to aplikacji na PC wypluciu z powrotem obrazu EEPORM'a i zapisaniu go AVRDude'm. Może to i skomplikowane ale mi działa tylko że nowy toolchain trochę mi to popsuł.

_________________
sig off ;(

No ale zaraz masz źródła do programu procka - a ty chcesz robić zrzut EEPROM'a - tzn może czegoś nie mogę zrozumieć ?

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

Mam. To jest mój kod a układ opisałem tu http://www.elektroda.pl/rtvforum/viewtopic.php?t=2207981&highlight=. Gdy go robiłem nie miałem bladego pojęcia jak ugryźć konfigurowanie tego sterownika po USART ( teraz mam trochę większe ale jeszcze nie wystarczające). Najprościej dla mnie było właśnie odczytanie USBAsp+AVRDudem EEPROM'a obrobienie go aplikacją na PC i wrzucenie go USBAsp+AVRDud'em do EEPROM'a. Tak to sobie wymyśliłem bo wtedy nawet nie miałem przejściówki USB/USART ani nie miałem wiedzy jak napisać bootloader żeby zrobić komunikację PC<->sterownik. Teraz wróciłem do projektu i po przekompilowaniu nowym toolchainem dane w eeprom zmieniły miejsce i konfigurator na PC odmówił współpracy. Stąd moje pytanie o lokalizację czy raczej organizację danych w EEPROM.

_________________
sig off ;(

No to jak to przeczytałem to (nie obraź się bo to nie złośliwie) ale jeśli chodzi o ten EEPROM to stawiasz sprawę gorzej niż DO GÓRY NOGAMI.

Rozumiem, że poradnika nie obejrzałeś, co do sposobu tam przedstawionego w ogóle nie zajmujesz stanowiska bo po co - wolisz iść drogą taką jakiej nie zaleca się podczas programowania w C ... bo już ci pisałem że zmienne mogą zmienić lokalizację w eeprom nawet bez zmiany toolchaina - ale rozumiem, że co tam ? nie ważne

a wszystko można zrobić bez żadnego dziwolągowatego kopiowania danych z eeproma za pomocą USBASP, modyfikacji binarki i ponownego programowania eeproma - to jest hmmm no gorzej niż do góry nogami - wybacz

w tym poradniku masz gotowy i 10000 x prostszy sposób, Ba pewniejszy, łatwiejszy i co ważne nie trzeba ŻADNEGO programatora aby zmieniać konfigurację w EEPROM

no tak ale po co ?

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

Mirku. Videoporadnik oglądałem. Wszystko jest ładnie i pięknie, ale w videoporadniku komunikacja USART jest na bieżąco w trakcie działania pętli głównej. Normalnie wszystkie porty I/O mam zajęte na potrzeby zasadniczej funkcji układu w tym również piny RX/TX. Tak więc nie da się prowadzić konfiguracji sterownika w trakcie normalnej jego pracy. Jedyna szansa to wymiana danych PC<->kontroler po resecie w czasie pracy bootloadera. A tego to ja jeszcze nie umiem żeby napisać sobie bootloadera. Docelowo wiem, że konfigurator na PC powinien wysłać sygnał RESET poczekać na zgłoszenie bootloadera i wysłać żądanie wysłania danych z EEPROM do PC ewentualnie wysłać żądanie odbioru danych do zapisania w EEPROM przez program bootloadera. Po uzgodnieniu ma nastąpić transmisja zawartości EEPROM w jednym lub w drugim kierunku i przejście do zasadniczego programu obsługi sterownika. Ja zrobiłem to co umiałem i mając świadomość, że jest to rozwiązanie ułomne grzecznie pytam czy jest sposób na sztywne umieszczenie konkretnych zmiennych pod konkretnymi adresami w EEPROM. To wszystko. Ponadto w poradniku nie ma ( na 99% bo może czegoś nie dopatrzyłem ) ani słowa na temat współdzielenia pamięci EEPROM przez program główny i bootloader bo o bootloaderze nie jest to poradnik. A przecież bootloader nie ma zielonego pojęcia jak program główny organizuje sobie pamięć EEPROM. Gdzieś przewinął mi się temat współdzielenia danych programu i bootloadera ale nie mogę tego teraz odszukać i nie pamiętam o jaki rodzaj pamięci chodziło. Tak więc może mi podpowiesz jak inaczej mogę programem na PC modyfikować pamięć EEPROM nie mając wolnych pinów RX/TX ( w zasadzie nie mając w ogóle wolnych pinów)?

_________________
sig off ;(

Zastanów się co jest ważniejsze? poprawne podejście ? czy zrobić coś źle a potem to łatać jeszcze gorzej ? Wszystko to tylko sprawa założeń - a w tym przypadku złych założeń To że coś źle zrobiłeś - hmmm no trudno przecież nie każdy od razu zrobi wszystko super, ja także nie.

Po pierwsze to sam widzisz, że USART to NAJWAŻNIEJSZY mechanizm i zawsze się go zostawia sobie na wszelki wypadek a szczególnie do komunikacji.

Ale ja NAWET gdybym nie miał wolnych pinów to zrobiłbym i czasem nawet robię tak że:

na czas np konfiguracji urządzenia ze strony PC czy to przez bootloader ale nie tylko może być przez program - można zrobić zworki i przełączyć te piny właśnie na potrzeby RS232 a po skonfigurowaniu przełączyć z powrotem tak jak było. To na prawdę nie wymaga wiele trudu i nawet w gotowym urządzeniu można to dodać.

poza tym po co piszesz o bootloaderze - dalej czegoś nie rozumie może jeszcze. Urządzenie można konfigurować nawet bez ŻADNEGO resetowania - po co ? wystarczy dodać procedurę która po przepięciu zworek - ot po prostu wyśle dane konfiguracyjne do PC po RS232 ale nie w żadnej toksycznej postaci binarnej tylko nawet pięknej tekstowej po to aby od razu łatwo można był obrobić czy skonfigurować - chociażby nawet przy pomocy głupiego terminala:

http://mirekk36.blogspot.com/2013/05/te ... z-lcd.html

a gdy ustawisz sobie coś to BACH! zapis do procka czyli przesyłasz znowu do procka a ten sobie zapisuje w EEPROM

przy czym odczyt i zapis do EEPROM robisz pięknie tak jak w tym poradniku

więc powiedz mi po co tu jakiś USBASP? zgroza i odczyt w ten sposób EEPROM'a ... zgroza

po co BOOTLOADER ?? po co ?

skoro wszystko z poziomu procka i normalnego w nim programu można zrobić a jak się uprzesz i podłączysz moduł Bluetooth do tych pinów Rx i Tx za zworkami to i z telefonu komórkowego przez Androida .... też jest poradnik na forum jak to zrobić gdybyś chciał

tymczasem podpowiadanie jak naprawiać to co jest DO GÓRY NOGAMI i to jeszcze w kolejny sposób, który jeszcze bardziej przerwraca wszystko - to nie nie ... sorki

lepiej naprowadzić cię na właściwą drogę

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

Genialne w swojej prostocie !!!
Nie jest to odpowiedź na moje pierwsze pytanie ale rozwiązuje mój problem. Trzeba tylko zadbać, żeby RX/TX był wspólnie na wejściach sterownika, bo jak na wyjściach to transmisja będzie mi robiła dyskotekę na wyjściu oraz zadbać, żeby w czasie odczytu/zapisu nikt nie bawił się wejściami Przynajmniej tymi od RX/TX. Wada : jak już przeleci te 2s a PC coś nada to będą mi wyjścia robiły również dyskotekę.

_________________
sig off ;(

No i widzisz - rozwiązań jest kupa że tak powiem.

A jak będziesz projektował kolejne to już bardziej zatroszczysz się o RS232 i to będą dla ciebie ważne piny - pamiętaj o tym

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