logo elektroda
logo elektroda
X
logo elektroda
REKLAMA
REKLAMA
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

Ograniczenie ilości zmiennych w BASCOM AVR na ATMEGA32 - co robić?

Kaban 22 Gru 2007 13:00 1937 12
REKLAMA
  • #1 4613304
    Kaban
    Poziom 12  
    Posty: 67
    Ocena: 4
    Witam
    Mam następujący problem napisałem w BASCOM AVR obszerny program wszystko działo bez problem aż do momentu kiedy dodanie jakiejkolwiek zmiennej kończy się tym że zmienna przyjmuje wartość 0 niezależnie ile razy przepisze do niej wartość zadaną. Oczywiście jak tą samą zmienną zapisze w ERAM wtedy wszystko jest OK. Mam pytanie czy ilość zmiennych w programie jest ograniczona? Podczas programowania kompilator pokazuje 28% zajętej pamięci. Dodam że programuje ATMEGA32.
    Pozdrawiam
    Kaban
  • REKLAMA
  • #2 4613568
    Alchemik84
    Poziom 14  
    Posty: 100
    Pomógł: 8
    Ocena: 2
    Wrzuć listing programu, wtedy będziemy kombinować.
  • REKLAMA
  • #3 4614155
    yakuza_2000
    Poziom 21  
    Posty: 291
    Pomógł: 48
    Ocena: 10
    Zapewne brakło pamięci RAM, a to co pokazuje kompilator to ilość użytej pamięci flash - tam gdzie jest zapisany program. Żeby nie brakowało pamięci trzeba dobrze zoptymalizować kod, tak aby nie używać zbyt dużo zmiennych.
  • REKLAMA
  • #4 4614159
    Kaban
    Poziom 12  
    Posty: 67
    Ocena: 4
    Witam
    Domyślam się że zabrakło pamięci SRAM jak mogę sprawdzić ile wolnej pmięci jeszcze zostało oczywiściw w BASCOM AVR
    Pozdrawiam
    Kaban

    Dodano po 5 [minuty]:

    Witam
    W załączniku rezultat kompilacji.
    Pozdrawiam
    Załączniki:
    • bascom.txt (20.46 KB) Musisz być zalogowany, aby pobrać ten załącznik.
  • #5 4614330
    kamyczek
    Poziom 38  
    Posty: 3994
    Pomógł: 394
    Ocena: 571
    Ato jest proste czytaj co pisze kompilator :
    Source string could be too big to fit into target string in line 375 (....)
    Masz zbyt długie stringi ;) fajnie brzmi to pierwsze a możliwe ze program mimo kompilacji będzie ci nadpisywał stosem zmienne , Ramu jest tyle ile jest i trzeba nim dobrze dysponować jeśli przy każdym przerwaniu odkladasz na stos zmienne których potem nie zdejmujesz stos rośnie aż nadpisze cały ram ...Czy opdczas symulacji nie wyświetla stack ..... i program zatrzymuje sie ?
  • REKLAMA
  • #6 4614471
    zumek
    Poziom 39  
    Posty: 3352
    Pomógł: 695
    Ocena: 52
    A ja się zastanawiam , jakim cudem ...
    Cytat:
    Compiler : BASCOM-AVR LIBRARY V 1.11.8.1, DEMO Edition

    ...potrafi skompilować ...
    Cytat:

    ROMIMAGE : 24AE hex -> Will fit into ROM
    ROMIMAGE : 9390 dec
    ... tyle kodu :?:

    Piotrek
  • #7 4614748
    Kaban
    Poziom 12  
    Posty: 67
    Ocena: 4
    Witam
    Symulacji nie puszczałem działam na żywym organizmie ale fatycznie sporadycznie się zdarza że procesor się resetuje czy to może być ta przyczyna. Nie rozumie tych ostrzeżeń Source string could be too big to fit into target string in line 375 w lini 375 znajduje sie:
    S_h1_off = Format(s_h1_off , "00").
    Sory za lamerskie pytanie ale jak zdejmować zmienne ze stosu?
    Jeżeli chodzi o post kolegi Zumek to podmieniłem pliki bibliotek wiem wiem ale nie robie tego komercyjnie tylko i wyłącznie edukacja.
    Pozdrawiam
    Kaban

    Dodano po 1 [godziny] 47 [minuty]:

    Witam
    Nowe fakty dokopałem się do informacji Space left = 1872 to znaczy że pamięci SRAM pozostało mi dokładnie 1872 bajtów dlaczego więc mam problemy jak wyżej faktycznie jak zadeklarowaną zmienną przypisze do konkretnej komórki pamięci wtedy działa poprawnie.
    Proszę o pomoc
    Pozdrawiam
    Kaban
  • #8 4615295
    zumek
    Poziom 39  
    Posty: 3352
    Pomógł: 695
    Ocena: 52
    Kaban napisał:
    ... Nie rozumie tych ostrzeżeń Source string could be too big to fit into target string in line 375 w lini 375 znajduje sie:
    S_h1_off = Format(s_h1_off , "00").

    Zapewne S_h1_off = Str(Set_h1_off) , a Set_h1_off jest typu Byte , więc podczas konwersji do String'a , może składać sie z 3 znaków , a Ty zadeklarowałeś S_h1_off As String * 2 , czyli max 2 znaki i stąd ostrzeżenie kompilatora.
    Kaban napisał:

    Jeżeli chodzi o post kolegi Zumek to podmieniłem pliki bibliotek wiem wiem ale nie robie tego komercyjnie tylko i wyłącznie edukacja.

    Jakoś mnie nie przekonałeś tą podmiana bibliotek , bo to właśnie DLL-ka generuje raport ;)
    Skoro ten Twój kod jest "wyłącznie edukacyjny" , to daj go tu , bo inaczej to możemy gdybać do Sylwestra :)

    Piotrek

    PS
    Daję słowo harcerza , że go nie wykorzystam - nawet edukacyjnie ;)
  • #9 4615980
    M. S.
    Poziom 34  
    Posty: 2107
    Pomógł: 259
    Ocena: 680
    Cytat:
    A ja się zastanawiam , jakim cudem ...
    Cytat:
    Compiler : BASCOM-AVR LIBRARY V 1.11.8.1, DEMO Edition

    ...potrafi skompilować ...
    Cytat:

    ROMIMAGE : 24AE hex -> Will fit into ROM
    ROMIMAGE : 9390 dec
    ... tyle kodu


    Cuda się zdarzają przecież idą święta!
    A tak na poważnie to jest jeden z cudów miłościwie panującego.

    Przepraszam za OT, ale powstrzymać się nie mogłem.
  • #10 4616093
    Kaban
    Poziom 12  
    Posty: 67
    Ocena: 4
    Witajcie
    Wygląda to następująco:
    ‘Dim S_h1_on as String*2
    ‘Dim I as byte
    S_h1_on = Str(i)
    S_h1_on = Format(s_h1_on , "00")
    Jednak niezależnie jak zadeklaruje stringa *10, *100 jest tak samo po odznaczeniu komendy formatu jest ok tzn. kompilator nie generuje ostrzeżenie. Co do baraku pamięci SRAM i zmiennych które przyjmowały wartości zerowe to zadeklarowane zmienne przypisałem na sztywno do konkretnych komórek pamięci i wydaje się być ok. ale w takim razie dlaczego kompilator tego nie zrobił poprawnie?
    Pozdrawiam
    Michał
  • #11 4616137
    zumek
    Poziom 39  
    Posty: 3352
    Pomógł: 695
    Ocena: 52
    Kaban napisał:
    Witajcie
    Wygląda to następująco:
    
    ‘Dim S_h1_on as String*2
    ‘Dim I as byte
    S_h1_on = Str(i)
    S_h1_on = Format(s_h1_on , "00")

    Jednak niezależnie jak zadeklaruje stringa *10, *100 jest tak samo po odznaczeniu komendy formatu jest ok tzn. kompilator nie generuje ostrzeżenie.

    No to zrób tak
    Dim S_h1_on As String * 3 , Tm As String * 3
    Dim I As Byte
    Tm = Str(i)
    S_h1_on = Format(tm , "00")
    

    a pozbędziesz się ostrzeżenia.
    I to jest wszystko , co mogę poradzić "w ciemno" ;)


    Piotrek
  • #12 4616418
    Kaban
    Poziom 12  
    Posty: 67
    Ocena: 4
    Witam
    Niestety nie dział błąd cały czas się generuje już wcześnie zadeklarował te springi *20 i nic to nie dało. Tak na marginesie czy tym ostrzeżeniem powinienem się przejmować?
    Pozdrawiam
    Michał
  • #13 4616869
    zumek
    Poziom 39  
    Posty: 3352
    Pomógł: 695
    Ocena: 52
    Kaban napisał:
    Witam
    Niestety nie dział błąd cały czas się generuje już wcześnie zadeklarował te springi *20 i nic to nie dało.

    Cóż , u mnie to działa i to w programach , które zajmują 93% pamięci programu i 77% SRAM-u w M32
    Kaban napisał:
    Tak na marginesie czy tym ostrzeżeniem powinienem się przejmować?
    Pozdrawiam
    Michał

    Ja bym się przejmował .

    Piotrek

Podsumowanie tematu

✨ Problem dotyczy ograniczeń ilości zmiennych w programie napisanym w BASCOM AVR dla mikrokontrolera ATMEGA32. Autor zauważył, że po dodaniu nowych zmiennych ich wartość jest zerowa, mimo że kompilator pokazuje jedynie 28% zajętej pamięci programu (flash). Wskazano, że prawdopodobną przyczyną jest brak pamięci SRAM, która jest wykorzystywana do przechowywania zmiennych podczas działania programu. Kompilator generuje ostrzeżenia typu "Source string could be too big to fit into target string" związane z nieodpowiednim rozmiarem zadeklarowanych łańcuchów znaków (stringów), co może powodować nadpisywanie stosu i problemy z pamięcią. Zalecane jest optymalizowanie kodu i odpowiednie zarządzanie pamięcią SRAM, w tym deklarowanie stringów o odpowiedniej długości (np. String*3 zamiast String*2) oraz monitorowanie wolnej pamięci SRAM (np. Space left = 1872 bajtów). Problemy z resetowaniem procesora mogą wynikać z przepełnienia stosu lub niewłaściwego zarządzania zmiennymi lokalnymi w przerwaniach. Podkreślono, że kompilator pokazuje zużycie pamięci flash, a nie RAM, co może mylić użytkownika. Wskazano również, że przypisywanie zmiennych do konkretnych adresów pamięci może być rozwiązaniem, ale nie wyjaśnia przyczyn problemu z automatycznym zarządzaniem pamięcią przez kompilator.
Podsumowanie wygenerowane przez AI na podstawie treści dyskusji.
REKLAMA