Atmega: Ręczne czy automatyczne przyporządkowanie zmiennych w SRAM?

Witam serdecznie.

Podczas pisania programu w BascomAVR dla atmegi lepiej ręcznie przyporządkować obszar w pamięci SRAM dla zmiennych wykorzystywanych w programie czy lepiej, żeby automatycznie zostały rozmieszczone w pamięci?

Chodzi o to czy lepiej tak:
Dim As Zmienna At 800,
czy tak:
Dim As Zmienna ?

Jeżeli lepiej ręcznie to czy są jakieś reguły rozmieszczania tych zmiennych? Np. tak, żeby nie zostały nadpisane przez stos itp.

To, że w EEPROM lepiej rozmieszczać samemu to przekonałem się na własnej skórze jak zaczęły znikać mi dane umieszczone automatycznie w pierwszych obszarach EEPROM.

Proszę o odpowiedzi.
Dziękuję.

po to sie uzywa jezykow wysokiego poziomu, zeby sie nie bawic takimi rzeczami. skoro znikaly ci w EEPROMie zmienne, to znaczy ze cos pomieszales w programie (albo bascom cos pomieszal [; ). kompilator sam NIGDY nie nadpisze obszaru zarezerwowanego na zmienne.

0x41 0x56 0x45!!

W AVRkach są "wbudowane" problemy z pierwszą komórką EEPROM. Dane lubią się tam pokrzaczyć w momencie zaniku zasilania.

Fredi jeśli dla ciebie bascom to język "wysokiego poziomu " to ja powiem że korzystają z niego
"wysokiego" poziomu programiści. a jak myślisz że nie nadpisze obszaru zmiennych to napisz sobie prosty programik w którym w pętli gł. odkładaj na stos byle co a następnie poddaj program kompilacji odczytaj wynik i uruchom program i policz po ilu cyklach poleciał w maliny ...Kompilator sprawdza jedynie poprawność składni i nazewnictwo na resztę jest ślepy ...

mowisz o extremalnym przypadku przepelnienia stosu i tym samym wylozenia sie programu. tymczasem kwestia tutaj podjeta jest taka, ze kompilator sam nie wstawi dwoch zmiennych w jeden adres. bascoma nie znam - wiem ze C tak nie zrobi [; do tego stos jest przewaznie powyzej zmiennych wiec tez ciezko liczyc, ze nagle zasapi jakies wpisane tam wartosci... (choc w MSP430 akurat jest to calkowicie mozliwe, bo stos leci od konca w strone poczatku RAMu).

zreszta niewazne - nie ma sie co bawic w reczne pozycjonowanie zmiennych, bo aby zrobic to lepiej niz kompilator, to trzeba sie niezle naglowic i niezle na tym znac.

0x41 0x56 0x45!!

Freddie Chopin napisał:

po to sie uzywa jezykow wysokiego poziomu, zeby sie nie bawic takimi rzeczami. skoro znikaly ci w EEPROMie zmienne, to znaczy ze cos pomieszales w programie (albo bascom cos pomieszal [; ). kompilator sam NIGDY nie nadpisze obszaru zarezerwowanego na zmienne.

0x41 0x56 0x45!!

Nie chodzi o nadpisanie przez kompilator zmiennych tylko o to czy atmega z nimi czegoś nie zrobi. Tak jak wyżej wspomniano, w atmegach jest problem z EEPROM. Najczęściej występuje w pierwszej komórce tej pamięci. Jednak z tego co się dowiedziałem, należy korzystać z pamięci EEPROM od adresu 100. Nieraz miałem problemy z danymi w EEPROM. Znikały po wyłączeniu i załączeniu zasilania. Zrobiłem nawet testy zapisując dane bezpośrednio z programatora do tej pamięci a potem kilka razy włączałem i wyłączałem zasilanie procka. Po odczytaniu EEPROM dane były zmienione lub nawet całkowicie skasowane.

Dlatego też pytam, czy nie lepiej ręcznie ulokować miejsce w RAM również dla zmiennych używanych w programie. Kiedyś miałem też problem ze zmiennymi. Miałem ich dosyć dużo w programie i występowały problemy z wyliczaniem pewnych funkcji itp. Gdy ręcznie przydzieliłem im obszar w pamięci problem zniknął.

Wcale to nie jest trudne, a wręcz banalne - wystarczy kalkulator (a nawet nie trzeba), trzeba tylko wiedzieć ile pamięci dany rodzaj zmiennych zajmuje.

PS Bascom jest językiem wysokiego poziomu, natomiast assembler niskiego poziomu

Prodig napisał:

[eeprom]

no to skoro zwalony jest pierwszy obszar, to trzeba sobie stworzyc zmienna tablicowa, ulokowac ja na poczatku i potem juz jej nie uzywac - simple.

Cytat:

Dlatego też pytam, czy nie lepiej ręcznie ulokować miejsce w RAM również dla zmiennych używanych w programie. Kiedyś miałem też problem ze zmiennymi. Miałem ich dosyć dużo w programie i występowały problemy z wyliczaniem pewnych funkcji itp. Gdy ręcznie przydzieliłem im obszar w pamięci problem zniknął.

istnieja tylko dwa mozliwe wytlumaczenia tego problemu:
1. bardzo prawdopodobne - cos pomieszales
2. malo prawdopodobne - bascom nie potrafi przydzielac miejsca zmiennym.

Cytat:

Wcale to nie jest trudne, a wręcz banalne - wystarczy kalkulator (a nawet nie trzeba), trzeba tylko wiedzieć ile pamięci dany rodzaj zmiennych zajmuje.

widze ze twoje podejscie do sprawy jest typu 'butem w twarz'. tu nie chodzi o to, aby na siebie nie zachodzily. tu chodzi o to, ze przewaznie programowi wcale nie potrzeba tylu zmiennych ile zadeklarujesz i rola kompilatora jest to, aby zoptymalizowac uzycie pamieci. i wlasnie to kompilator robi bardzo szybko, natomiast dla czlowieka jest to mocno skomplikowane zadanie. jesli twoim zalozeniem jest zajecie calego RAMu to faktycznie - nie jest to zbyt trudne.

Cytat:

PS Bascom jest językiem wysokiego poziomu, natomiast assembler niskiego poziomu

czy ktos gdzies napisal tu cos innego? widac nie zrozumiales dowcipu.

0x41 0x56 0x45!!

Cytat:

widze ze twoje podejscie do sprawy jest typu 'butem w twarz'. tu nie chodzi o to, aby na siebie nie zachodzily. tu chodzi o to, ze przewaznie programowi wcale nie potrzeba tylu zmiennych ile zadeklarujesz i rola kompilatora jest to, aby zoptymalizowac uzycie pamieci. i wlasnie to kompilator robi bardzo szybko, natomiast dla czlowieka jest to mocno skomplikowane zadanie. jesli twoim zalozeniem jest zajecie calego RAMu to faktycznie - nie jest to zbyt trudne.

Myślę, że w tym momencie się mylisz. Zmienne w pamięci rozmieszczane są automatycznie jedna za drugą. Nie ma tu znaczenia czy w danym momencie jest używana czy też nie. Można to łatwo sprawdzić, że tak jest. Poniżej zamieszczam plik w którym umieściłem 128 zmiennych typu Double. Czyli każda zmienna ma po 8 bajtów. Podczas kompilacji wyskakuje błąd, że brakło pamięci SRAM. Wystarczy jedną zmienną wywalić i program skompiluje się. A przecież nie użyłem żadnej z tych zmiennych tylko je zadeklarowałem.

No chyba, że się nie rozumiemy

Z tego co wyliczyłem ostatnia zadeklarowana zmienna wchodzi na obszar zarezerwowany dla stosu i właśnie dlatego wyskakuje błąd braku pamięci.
Zmniejsz rozmiar stosu a zobaczysz, że uda się skompilować bez błędów. Tak samo jak zwiększysz stos to jeszcze mniej zmiennych zadeklarujesz.

Bardzo dużo projektów na Bascomie zrobiłem, w większości używałem EEPROMu i nie zauważyłem, żeby były jakieś problemy z innymi komórkami pamięci niż o adresie 0, ani też żeby Bascom miał jakieś błędy z obsługą wbudowanego EEPROMu. Na 99% tak jak wyżej napisał Freddie coś pomieszałeś w kodzie. Sprawdź dokładnie każde odwołanie do EEPROMu a dojdziesz gdzie może występować błąd.

Ręcznie umieszczać zmienne w Bascomie widzę sens tylko jeśli chcemy zamapować jakąś część zmiennej dla innej. Np. zamiast używać poleceń LOW() i HIGH() odwoływać się do bajtów bardziej i mniej znaczących zmiennej WORD przez dodatkowe zmienne typu BYTE.

K_o_n_r_a_d, jeżeli masz trochę czasu to przedstaw mi swój sposób zapisu/odczytu danych do/z EEPROM. Z góry dzięki.

Ja to robię tak mniej więcej:

Prodig napisał:

... Wystarczy jedną zmienną wywalić i program skompiluje się. A przecież nie użyłem żadnej z tych zmiennych tylko je zadeklarowałem.

No chyba, że się nie rozumiemy

Ty chyba nie rozumiesz , do czego służy instrukcja Dim
Dim Zmienna As Long - to polecenie dla kompilatora , które "mówi mu' : Stwórz Zmienną Zmienna i zarezerwuj dla niej 8 bajtów pamięci RAM.O tym że jej nie użyłeś , lojalnie ostrzega

Piotrek

zumek napisał:

Ty chyba nie rozumiesz , do czego służy instrukcja Dim
Dim Zmienna As Long - to polecenie dla kompilatora , które "mówi mu' : Stwórz Zmienną Zmienna i zarezerwuj dla niej 8 bajtów pamięci RAM.O tym że jej nie użyłeś , lojalnie ostrzega

Wiem do czego służy DIM i używam go od 6 klasy podstawówki jak tylko miałem atarii Ja tylko podałem przykład, w którym widać, że zmienne mają zarezerwowane miejsce w pamięci niezależnie czy są używane w programie czy też nie. A chodzi mi o to od początku tego postu, czy lepiej pozwolić kompilatorowi przyporządkować kolejno miejsca w pamięci kolejnym zmiennym czy może lepiej samemu to zrobić.

jednak nie wiesz... to ze nie mozesz zadeklarowac wiekszej ilosci zmiennych NIE MA NIC DO RZECZY. fizyczne ograniczenie. lodowka ma pojemnosc 100l, to znaczy, ze nawet jakbys chcial, to nie wepchniesz do niej 101l. tyle ze produkty o objetosci 50l mozna ulozyc tak, aby zajely 52l, albo 84l. moze sie tak zdazyc, ze nie uda ci sie recznie poukladac 70l w srodku. rowniez prawdopodobne jest, ze 30% z tych produktow nie jest ci potrzebne, a w polowie roku dalsze 20% jest juz przedatowane i nie potrzebne. kompilator rozwiaze to w pol sekundy, a ty?

istotne jest, ze jesli w istocie skompilujesz ten program i podejrzysz wynik jego assemblacji, to zobaczysz, ze de facto tych zmiennych ktorych nie uzyles NIE MA. NIE ISTNIEJA. jesli nie sa wykorzystane w kodzie do czegos waznego, to rowniez znikna WSZYSTKIE BEZCELOWE operacje na tych zmiennych...

no chyba ze wlasnie znalazlem ostateczny argument dlaczego bascom nie nadaje sie do niczego [;

napisanie w C czegos takiego:



da w efekcie... zero kodu w assemblerze i zero zajetosci pamieci ram. (kompilator C30 [port gcc] )

czyzby bascom byl tak glupi? [;

0x41 0x56 0x45!!

Prodig napisał:

K_o_n_r_a_d, jeżeli masz trochę czasu to przedstaw mi swój sposób zapisu/odczytu danych do/z EEPROM. Z góry dzięki.

Ja to robię tak mniej więcej:

Kod: text Rozwiń Zaznacz wszystko Kopiuj do schowka

Dim pomocnicza As single At 700
Dim X As Eram Single At 100

X=pomocnicza 'zapis do eeprom
pomocnicza=X 'odczyt z eeprom

Zrobiłem już dużo sterowników i innych urządzeń ale jeszcze nigdy nie używałem zmiennych typu SINGLE. Nawet jeśli już potrzebowałem typu SINGLE to zawsze dało się zrobić to tak, żeby nie używać właśnie SINGLE a zastąpić to typami całkowitymi (BYTE, WORD, INTEGER) odpowiednio uzytymi co zazwyczaj skracało program wynikowy, szybciej się wykonywało i jednocześnie zajmowało mniej pamięci SRAM.

Twój sposób jest dobry, ale tak robiąc trzeba uważać, aby przez przypadek zmienna nie była zbyt często zapisywana - przez nieuwagę można bardzo szybko wykorzystać wszystkie 100'000 (czy 1M - nie pamiętam dokładnie ile nowe AVRy mają) zapisów gwarantowanych i właśnie później mogą pojawiać się przekłamania.
Ja zawsze używam do obsługi EEPROMu poleceń WRITEEEPROM i READEEPROM. Wstawiam je w oddzielne podprogramy (mniej zajmują wtedy pamięci programu - większy stos potrzebny, ale w moich programach zazwyczaj potrzeba wiecej właśnie pamięci FLASH a SRAMu zawsze zostaje dlatego tak robię - umieszczając w podprogramach) i jeszcze przed zapisem sprawdzam czy zapisywana zmienna uległa zmianie, jesli nie to nie zapisuję - takie dodatkowe zabezpieczenie.

Freddie Chopin napisał:

napisanie w C czegos takiego:

Kod: text Rozwiń Zaznacz wszystko Kopiuj do schowka

int main(void)
{
unsigned int a=5,b=10,c=15;
b+=a*c;
c*=a/b;
a=c-b;
}

da w efekcie... zero kodu w assemblerze i zero zajetosci pamieci ram. (kompilator C30 [port gcc] )

czyzby bascom byl tak glupi? [;

0x41 0x56 0x45!!

hmm... Bascom skompiluje to i powiększy program nawet przy włączonej optymalizacji!
Akurat C30 przy wyłączonej optymalizacji też skompiluje i też powiększy.

Prodig napisał:

...Ja tylko podałem przykład, w którym widać, że zmienne mają zarezerwowane miejsce w pamięci niezależnie czy są używane w programie czy też nie.

Ale tak być nie musi , bo możesz wykorzystać zmienne tymczasowe(LOCAL) , dla których kompilator zarezerwuje miejsce , dopiero w czasie działania programu , a nie w procesie kompilacji.

Prodig napisał:

A chodzi mi o to od początku tego postu, czy lepiej pozwolić kompilatorowi przyporządkować kolejno miejsca w pamięci kolejnym zmiennym czy może lepiej samemu to zrobić.

Jeśli chodzi o RAM to lepiej pozostawić to kompilatorowi , a z eepromem ... to różnie bywa

Piotrek

Freddie Chopin, wnioskuję z tego, że kompilator z Bascoma jest głupi bo wywala mi brak SRAM pomimo, że zmienne nigdy nie zostały użyte w programie i praktycznie cały ram powinien być wolny.

K_o_n_r_a_d, w programie odczytuję zmienne z EEPROM tylko podczas włączenia urządzenia, a zapisuję tylko po dokonaniu zmian w ustawieniach. Odczyt zatem odbywa się raz na każde włączenie procesora a zapis kilka razy w ciągu roku
W moim programie potrzebuję zmiennych typu single i zamiana ich na inne mija się z celem bo chyba powiększy się tylko program.

Wracając do lokowania w pamięci. Źle robię, że przypisuję ręcznie miejsce w SRAM dla zmiennych? Mogę coś namieszać robiąc to? W niektórych wypadkach pomogło to. Już sam nie wiem...

hehe [; no tak, ale po to wlasnie ludzie wymyslili optymalizacje [;

przeciez bez optymalizacji, to sie nic nie da napisac sensownego, szybkiego i malego <:

0x41 0x56 0x45!!

Tak sobie czytam i czytam i więdze że bardzo dużo ludzi psioczy na EEPROM w Atmegach. A ma ktoś może wiedzę czy ATMEL wypuścił oficjalną ERRATE do błędów w EEPROM, chociażby do tej komórki o adresie 0.
Czy może te wszystkie rewelacje o EEPROMIE rozchodza sie pocztą pantoflową?

Dodano po 1 [minuty]:

Jeżeli nie ma officjalnej ERRATY to wina leży tylko i wyłącznie po stronie PROGRAMISTY ewentualnie KONSTRUKTORA.

Dodano po 2 [minuty]:

Freddie Chopin napisał:

(choc w MSP430 akurat jest to calkowicie mozliwe, bo stos leci od konca w strone poczatku RAMu).

W MSP430 Stos jest tam gdzie go sobie zrobisz. Jedyne ograniczenie jest takie że zawsze rośnie od adresów większych do mniejszych, zawsze zużywa 2bajty no i oczywiście musi być w RAMie.

Dodano po 3 [minuty]:

K_o_n_r_a_d napisał:

Z tego co wyliczyłem ostatnia zadeklarowana zmienna wchodzi na obszar zarezerwowany dla stosu i właśnie dlatego wyskakuje błąd braku pamięci.
Zmniejsz rozmiar stosu a zobaczysz, że uda się skompilować bez błędów. Tak samo jak zwiększysz stos to jeszcze mniej zmiennych zadeklarujesz.

Ot i coś mądrego. Wreszcie jest coś pożytecznego co robi kompilator. Dba o to aby zostało tyle stosu ile sobie założyliśmy.

Dr_DEAD napisał:

W MSP430 Stos jest tam gdzie go sobie zrobisz. Jedyne ograniczenie jest takie że zawsze rośnie od adresów większych do mniejszych, zawsze zużywa 2bajty no i oczywiście musi być w RAMie.

w kazdym procesorze stos jest tam gdzie sobie go umiescisz - mowimy jednak o sytuacjach typowych, czyli o tym, gdzie sugeruje go umiescic producent procesora i kompilatora. tak sie sklada, ze dla 16b PICow stos w domyslnej lokalizacji po przepelnieniu wylozy program (nastapi sprzetowa pulapka od przepelnienia stosu, ktora skonczy sie resetem, chyba ze programista zadecydowal inaczej), natomiast w MSP430 domyslnie umieszczony stos, przed wywaleniem programu zmasakruje jeszcze wszystkie zmienne w ramie [;

0x41 0x56 0x45!!

Freddie Chopin napisał:

tak sie sklada, ze dla 16b PICow stos w domyslnej lokalizacji po przepelnieniu wylozy program (nastapi sprzetowa pulapka od przepelnienia stosu, ktora skonczy sie resetem, chyba ze programista zadecydowal inaczej), natomiast w MSP430 domyslnie umieszczony stos, przed wywaleniem programu zmasakruje jeszcze wszystkie zmienne w ramie

Domyśle ustawienia są po to aby je zmieniać. W MSP430 też jest niemaskowalne przerwanie NMI i flaga Memory Access Violation, więc przepełnienie stosu można obsłużyć podobnie jak w PICach.

domyslne ustawienia PICow akurat sa calkowicie sensowne i bezpieczne, wiec po co je zmieniac <: w MSP... w sumie mniej bezpiecznie, choc tak bardziej naturalnie dla stosu idacego w dol... (IMHO oczywiscie) [;

dla dobrze napisanego programu to zadna roznica, bo skad przepelnienie stosu w poprawnym programie?

0x41 0x56 0x45!!

Prodig napisał:

Freddie Chopin, wnioskuję z tego, że kompilator z Bascoma jest głupi bo wywala mi brak SRAM pomimo, że zmienne nigdy nie zostały użyte w programie i praktycznie cały ram powinien być wolny.

Hmmm... Tak sobie czytam i się zastanawiam... Nasunęły mi się pod wpływem powyższych postów takie pytania:
PO CO deklarować zmienne, których się później nie używa
Czy głupi jest kompilator, który na zadeklarowane przez programistę zmienne rezerwuje miejsce, czy programista, który takie zmienne deklaruje..?

Tylko bardzo proszę mnie źle nie zrozumieć - nie napisałem tego pod niczyim adresem i absolutnie nie szukam zaczepki

Osobiście zapisuję swoje dane do EEPROM zawsze pod konkretne, wybrane przez siebie adresy, natomiast wybór lokalizacji zmiennych w RAM pozostawiam zazwyczaj kompilatorowi.

Dr_DEAD napisał:

A ma ktoś może wiedzę czy ATMEL wypuścił oficjalną ERRATE do błędów w EEPROM, chociażby do tej komórki o adresie 0.
Czy może te wszystkie rewelacje o EEPROMIE rozchodza sie pocztą pantoflową?

Też się kiedyś nad tym zastanawiałem i nawet poświęciłem sporo czasu na poszukiwanie odpowiedzi na to pytanie. Z tego co mi się udało wtedy ustalić problem "felernej" komórki 0 w EEPROM dotyczył raczej kontrolerów serii AT90Sxxxx, i został wyeliminowany w ATmega-ch.
Dane w komórce o adresie 0 ulegały uszkodzeniu/nadpisaniu jeśli w momencie zapisu do dowolnej innej komórki EEPROM nastąpił reset procesora. Cykl zapisu podczas resetu był kontynuowany, a w międzyczasie zerował się wskaźnik adresu EEPROM, przez co uszkodzeniu ulegały dane w aktualnie zapisywanej komórce, oraz w komórce o adresie 0.
ATMEL przyznaje się do istnienia tego problemu. Przykład:
Errata dla AT90S8515 - patrz akapit "Reset During EEPROM Write"
Natomiast w ATmega8515 problem już nie występuje:
AVR085: Replacing AT90S8515 by ATmega8515
Według tego co tam piszą uszkodzeniu mogą ulec tylko dane w komórce, do której akurat zapisywano dane w momencie resetu.

Jedynym procesorem z serii ATmega dla którego udało mi się znaleźć erratę opisującą możliwość wystąpienia problemu z zerową komórką jest ATmega103, więc układ "dość stary". Nie mogę teraz namierzyć tego pliku...

EDIT
Znalazłem: doc1436.pdf

Pozdrawiam
Andy

Andy74 napisał:

Z tego co mi się udało wtedy ustalić problem "felernej" komórki 0 w EEPROM dotyczył raczej kontrolerów serii AT90Sxxxx, i został wyeliminowany w ATmega-ch.
......
ATMEL przyznaje się do istnienia tego problemu. Przykład:
Errata dla AT90S8515 - patrz akapit "Reset During EEPROM Write"
Natomiast w ATmega8515 problem już nie występuje:
AVR085: Replacing AT90S8515 by ATmega8515
Według tego co tam piszą uszkodzeniu mogą ulec tylko dane w komórce, do której akurat zapisywano dane w momencie resetu.
......
Znalazłem: doc1436.pdf

Wielkie dzięki za konkrety. A tak swoją drogą to niektóre błędy w tej Atmega103 przerażają
A co sie tyczy EEPROMA wbudowanego w MTMEGI to wynika że jest on tak samo bezpieczny jak zewnętrzny, oczywiście przy zachowaniu wszelkich zaleceń producenta.

Cytat:

Hmmm... Tak sobie czytam i się zastanawiam... Nasunęły mi się pod wpływem powyższych postów takie pytania:
PO CO deklarować zmienne, których się później nie używa Question
Czy głupi jest kompilator, który na zadeklarowane przez programistę zmienne rezerwuje miejsce, czy programista, który takie zmienne deklaruje..?

Ja tylko podałem przykład.

Problem z zerową komórką występuje nadal w atmegach. Osobiście przeprowadziłem testy, które to ujawniły.
Poza tym znalazłem tłumaczenie dokumentacji dla Atmega32 i jest tam mowa o możliwości uszkodzenia danych w EEPROM podczas operacji na tych danych gdy spadnie napięcie zasilania procka. Zabezpieczyć można się przed tym aktywując BODa.

Dodam jeszcze, że odechciewa mi się Bascoma. Dziś zrobiłem inne ciekawe testy. Napisałem program, który wykonuje obliczenia m.in. na zmiennych single. W programie mam tablicę:

Dim Wartosc(30) As String * 5

Podczas wykonywania programu, jest wyświetlana wartość z pozycji Wartosc(1). W tym momencie wykonywane są również różne obliczenia. I co się dzieje? Wartość zapisana w zmiennej Wartosc(1) cały czas się zmienia (ulega na bieżąco niszczeniu). Problem znika gdy zrobię takie coś:

Dim Wartosc(30) As String * 5 At $200

I co teraz mam o tym myśleć? Już nie wiem.
Może lepiej przerzucić się na C? Co możecie mi polecić?

Defnitywnie polecam C...fakt ze to troche "naginany" C, bo dla AVR...a ten ma budowe każdą inną niż taką dla której C został rdzennie stworzony, ale i tak jest dobrze
Szybkie latwe i przyjemne jest CodeVision AVR, niestety, komercyjny...Albo moze byc tez i WinAVR

Prodig napisał:

Problem z zerową komórką występuje nadal w atmegach. Osobiście przeprowadziłem testy, które to ujawniły.

Nie ma ERRATY nie ma BŁĘDU - to jest niepodważalna prawda dla tak starej rodziny jak ATMEGA.

Prodig napisał:

Poza tym znalazłem tłumaczenie dokumentacji dla Atmega32 i jest tam mowa o możliwości uszkodzenia danych w EEPROM podczas operacji na tych danych gdy spadnie napięcie zasilania procka. Zabezpieczyć można się przed tym aktywując BODa.

Nie musieli tego pisać, każdy elektronik zajmujący się uC powinien to wiedzieć. Bo zjawisko takie występuje w każdym uC, który nie ma kontrolowanego napięcia zasilania. I to obojętnie czy to EEPROM, Flash itd.

Prodig napisał:

Dodam jeszcze, że odechciewa mi się Bascoma. Dziś zrobiłem inne ciekawe testy. .....
Podczas wykonywania programu, jest wyświetlana wartość z pozycji Wartosc(1). W tym momencie wykonywane są również różne obliczenia. I co się dzieje? Wartość zapisana w zmiennej Wartosc(1) cały czas się zmienia (ulega na bieżąco niszczeniu). ....
Może lepiej przerzucić się na C? Co możecie mi polecić?

Nie traktujcie uC jak komputera PC z systemem operacyjnym. Nie da się pisać pod uC nie wiedząc jak on działa i jak działa kompilator.
Przejście na C nic Ci nie da, będziesz miał takie same problemy. Zacznij od ASSEMBLERA to przynajmniej nauczysz sie jak działa uC.

nsvinc napisał:

Defnitywnie polecam C...fakt ze to troche "naginany" C, bo dla AVR...a ten ma budowe każdą inną niż taką dla której C został rdzennie stworzony, ale i tak jest dobrze

czy aby na pewno tak jest? przeciez uwaza sie, ze ogolnie bardziej C-friendly sa architektury ktore posiadaja duzo rejestrow GPR (a AVRach z tego co wiem az 32!), liniowo adresowana pamiec (to akurat malo ktory uC ma, bo przewaznie jest podzial na RAM i ROM, choc czeso tak rozwiazane, ze w zasadzie pamiec jest liniowa) i programowy stos o (a z tego co mi wiadomo z popularnych procesorow tylko =< PIC18 maja stos sprzetowy). tak wiec nie jest zle [;

C jest bardzo dobry, zawsze warto sie nauczyc C z tego prostego powodu, ze mozna potem programowac K_A_Z_D_Y uC i DSP oraz aplikacje na PC. basic moze i jest na wiele platform, to jednak na wszystkie chyba nie,,, pozatym C - jak juz bylo tu powidziane - jest wysokopoziomowym jezykiem niskiego poziomu [; nie ma w nim zadnych wynalazkow, ktore ukrywalyby przez programista sprzet (rejestry sterujace) - wszystko najlepiej i najszybciej zrobic przypisujac odpowiednie wartosci do odpowiednich rejestrow. przez to przeczytanie datasheeta jest koniecznoscia, bez tego ani rusz... pozatym C jest proste i mozna znalezc mniej wiecej miliard kursow, czy to w ksiazkach czy na necie za free. porownujac wydajnosc assemblera z wydajnoscia C moge powiedziec, ze przy wlaczonej optymalizacji O1 (pierwszy poziom) w C30 (gcc) kod JEST duzo wiekszy, poniewaz kompilator zwiazany jest konwencjami wywolywania funkcji i zwracania wartosci (~150% assemblerowego dla mojej konkretnej aplikacji w C zajmuje 2.2k, w assemblerze 1.5k), natomiast kluczowe funkcje od ktorych zalezy szybkosc wykonywania sie aplikacji maja predkosc porownywalna z assemblerem - sa wolniejsze o ok 2-3% (~54k cykli vs ~55k cykli). oczywiscie ze wstawkami assemblerowymi tu i owdzie [;

abstrahujac calkowicie od jakosci bascoma i innych basicow, C po prostu jest standardem i koniec - nic nie zapowiada w najblizszm czasie zmiany tego standardu na cos innego. producenci staraja sie robic procesory jaknajbardziej przyjazde dla C, projektujac ich architekture i zestaw instrukcji pod ten jezyk. na kazda platforme istnieje conajmniej kilka roznych kompilatorow C, natomiast jesli juz jest w ogole basicowy, to jest jeden.

najwazniejsza zaleta wiekszosci kompilatorow C jest jednak to, ze nie sa dodawane do nich bliblioteki, ktore robia wszystko za programiste (LCD, termometry DS18xx, zegary RTC itp.) - wszystko trzeba sobie napisac samemu, pomyslec i pomeczyc sie troche, uczac sie jednoczesnie [;

0x41 0x56 0x45!!

Nie traktuję mikrokontrolera jak PC. Obawiam się tylko o kompilator z Bascoma. Bo niby dlaczego pomaga ręczne zadeklarowanie miejsca w pamięci dla tablicy? Moim zdaniem kompilator w tym wypadku popełnia jakiś błąd.

Prodig napisał:

Nie traktuję mikrokontrolera jak PC. Obawiam się tylko o kompilator z Bascoma. Bo niby dlaczego pomaga ręczne zadeklarowanie miejsca w pamięci dla tablicy? Moim zdaniem kompilator w tym wypadku popełnia jakiś błąd.

Wiesz jaki obszar RAMu przydzielony jest dla Stosu? Wiesz jaki obszar RAMu przydzielony jest na zmienne? Konkretnie adresy od XXXX do XXXX. Nie znam Bascoma, może ma on jeszcze inne zdfinowane obszary pamięci. Znasz je wszystkie?

Prodig napisał:

Nie traktuję mikrokontrolera jak PC. Obawiam się tylko o kompilator z Bascoma. Bo niby dlaczego pomaga ręczne zadeklarowanie miejsca w pamięci dla tablicy? Moim zdaniem kompilator w tym wypadku popełnia jakiś błąd.

Jeśli nie jest to jakiś tajny projekt to pokaż kod, z którym masz problemy a postaramy się dojść dlaczego tak się dzieje. Albo wygeneruj nowy kod z którym będziesz miał ten sam problem.
Nigdy nie miałem takich problemów a używam prawie zawsze EEPROMu, może jednak stos lub coś innego tego typu tym bardziej, że używasz zmiennych SINGLE.

Miewałem problemy różne ale zawsze po dokładnym przyjrzeniu się okazywało się, że coś źle zrobiłem, dlatego myślę, że i tu coś takiego występuje.