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

Atmel Mega32 losowe wpisy do RAMu

PeterBernard314 13 Lut 2011 09:42 3013 37
  • #1 9144145
    PeterBernard314
    Poziom 15  
    Wprawdzie wiem, żę za wszystko co czyni mikrokontroler odpowiada programista, lecz po wielokrotnym przejrzeniu mojego softu, nie mogąc dopatrzeć się błędu, ośmielam się zadać koleżeństwu pytanie: czy ktoś z Was spotkał się problemem, że w RAM-ie mikrokontrolera pojawiają się dość sporadycznie i losowo, losowe pojedyncze bajty na losowych adresach?
  • #2 9144276
    MirekCz
    Poziom 35  
    Ile pamięci RAM zajmuje twoja aplikacja?
    Jak dużo to prawdopodobnie biedny AVR nie ma już gdzie upychać danych i zaczyna zapisywać jedne na drugie. To powoduje wrażenie zupełnej losowości błędów i dziwnego zachowania mikrokontrolera.

    Pamiętaj, że pamięć zajmują nie tylko twoje dane globalne, ale też dane lokalne i odkładanie zmiennych na stos przy wywoływaniu funkcji/przerwania.
  • #3 9144326
    piotrva
    VIP Zasłużony dla elektroda
    Zmienne zapełniają ram od początku, a stos od końca. Jak stos napisze obszar zmiennych i na odwrót to wtedy są takie rzeczy
  • #4 9144383
    PeterBernard314
    Poziom 15  
    Jest to program obsługi wyświetlacza LED, który piszę w asemblerze. Stos zaczyna się od RAM-endu, każda zmienna ma osobno swoją komórkę RAM-u, wydaje mi się, że nad wszystkim panuję, nie mam żadnych procedur rekurencyjnych mogących przeciążyć stos, zresztą mam nad nim kontrolę, gdyż mogę go podejżeć na wyświetlaczu i jeszcze nigdy się nie zdarzyło aby wyszedł poza przewidziany dla niego obszar.
  • #5 9144411
    tmf
    VIP Zasłużony dla elektroda
    No cóż - jak sam napisałeś, wydaje ci się, że nad wszystkim panujesz :) Najpewniej masz błąd w programie, gdyby procesor sam od siebie zachowywał się w sposób jaki opisujesz, to jak myślisz - do tej pory nikt by z takimi rzeczami nie miał problemów?
  • #6 9144666
    mirekk36
    Poziom 42  
    PeterBernard314 napisał:
    Wprawdzie wiem, żę za wszystko co czyni mikrokontroler odpowiada programista, lecz po wielokrotnym przejrzeniu mojego softu, nie mogąc dopatrzeć się błędu, ośmielam się zadać koleżeństwu pytanie: czy ktoś z Was spotkał się problemem, że w RAM-ie mikrokontrolera pojawiają się dość sporadycznie i losowo, losowe pojedyncze bajty na losowych adresach?


    A ja ośmielam się zasugerować , że nadszedł już czas aby zacząć pisać swoje aplikacje w języku C. To są właśnie uroki pisania tylko w asemblerze. Nie twierdzę, że się nie da.... ale pomyśl ile czasu musisz tracić na poszukiwania takich bug'ów.

    W C masz także pełną kontrolę nad wszystkim natomiast aplikacje powstają ZDECYDOWANIE szybciej. Polecam.

    Moim zdaniem, to żadna wina procesora, tylko czarna rozpacz z powodu niemożliwości znalezienia błędu w sofcie i to własnie powoduje takie myśli o uszkodzonym sprzęcie.
  • #7 9144805
    PeterBernard314
    Poziom 15  
    Hmm... Słynne 'Si' ... kiedyś w końcu zrobię ten krok i się nauczę tego hebrajskiego dziwoląga ... :P
  • #8 9146837
    asembler
    Poziom 32  
    Zapodaj program, przyjrzę się.
  • #9 9149156
    PeterBernard314
    Poziom 15  
    Cóż cały program jest dość duży (źródło 200kB, 11kB kodu po kompilacji), a że stanowi moją pracę autorską z którą wiąże plany zarobkowe, toteż na razie nie chcę go puszczać w świat...
  • #10 9149733
    Konto nie istnieje
    Poziom 1  
  • #11 9150212
    you-zek
    Poziom 15  
    Używasz przerwań? Drugie pytanko: czy zasilane procesorka ma porządne kondensatory osprzęgające i czy zasilanie jest stabilizowane? A i czy błędy pojawiaja sie też w symulatorze?
  • #12 9150283
    asembler
    Poziom 32  
    mirekk36 napisał:


    A ja ośmielam się zasugerować , że nadszedł już czas aby zacząć pisać swoje aplikacje w języku C. To są właśnie uroki pisania tylko w asemblerze. Nie twierdzę, że się nie da.... ale pomyśl ile czasu musisz tracić na poszukiwania takich bug'ów.

    W C masz także pełną kontrolę nad wszystkim natomiast aplikacje powstają ZDECYDOWANIE szybciej. Polecam.


    Czy zdecydowanie szybciej to nie wiem ale też bym sugerował przejscie na wyższy poziom. Bo jak chcesz zapełnić programe w ASM 32kB kodu to szacun.
    No cyba ze połowa to stałe,czcionki i inne takie.
  • #13 9150496
    PeterBernard314
    Poziom 15  
    Symulatora nie używam, gdyż nie wiem jak mam wprowadzać do niego transmisję z klawiatury PS2, za pomocą której uruchamiam różne fragmenty mojego programu. Rzeczywiście domyślam się że następuje interakcja przerwań z programem głównym. Przerwaniami odbieram PS2, Timer0 uruchamia 1600x/sek przerwanie zajmujące się odświeżaniem wyświetlacza i opcjonalnie wykonuje inne czynności. Będę nadal szukał chochlika :)

    Nie wiem ile zapełnię na razie mam 10700B kodu i spodziewam się że jeszcze dopiszę z kilka kilobajtów. Potem przesiadka na 644 albo Xmegę, gdyż mają więcej RAMU,a i do Romu więcej czcionek i tablic wejdzie. Program jest rozwojowy...
  • #14 9150577
    asembler
    Poziom 32  
    Program jest raczej chochlikowy. Cos chyba złe założenia programu masz skoro aż na Xmega chcesz przejsc i to w ASM?
    Skoro chcesz zarobkować to kierunek masz dobry że w ASM ale po co pchac sie w takie nadmiarowe prockki skor zwykla atmega168 obsłuzy wysztko spokojnie, a czcionki to mozna przeciez przechowywac we falszce ustawionej w szeregu. No ale ty masz koncepcje programu i pewnie słuszną na dodatek.
    A może czas sie zaopatrzyć poprostu w porzadny kompilator który nie dopusci do powstawania takich chochlików?
    Nie podejrzewam żeby ci symulator w tej sytuacji pomógł.
  • #15 9150733
    PeterBernard314
    Poziom 15  
    Mam już projekt PCB pod Megę i XmegęA3 alternatywnie. XM zapewni szybszą pracę. A propos czytałem, chyba na AVR freeks, że ktoś przetaktował Xmegę do 48MHz; pytanie tylko jak stabilnie...

    Czy koncepcja jest słuszna... pewnie można by zrealizować zadanie na 10 innych sposobów, ale skoro to moja koncepcja to się jej będę trzymał :)

    Zasilacz jest stabilizowany, kondensatorki są, szum na Ucc około 50mVpp, ale się temu dokładniej zaraz przyjrzę.

    Przy okazji mam pytanie: jeśli dobrze zrozumiałem z lektury manuala, w XM rejestry R0-R31 nie stanowią już spójnego obszaru z pamięcią tak jak to jest w Megach?
  • #16 9150755
    asembler
    Poziom 32  
    No to pewnie robisz telebim LED VGA.
  • #17 9150792
    PeterBernard314
    Poziom 15  
    Telebim to jeszcze nie jest, ale spory wyświetlacz monochromatyczny :)
    Chińskie telebimy kolorowe są już tak tanie, że ostatnio sam byłem w szoku po wizycie u jednego z dystrybutorów takich sprzętów.
  • #18 9150857
    asembler
    Poziom 32  
    No to skoro nie jest to telebim to musisz miec złe z gruntu załozenia że chcesz na xmega przechodzic. W chinskich telebimach chodzą rdzenie '51 czyli widocznie nie moc sie liczy ale własnie program.
  • #19 9151105
    PeterBernard314
    Poziom 15  
    Wiesz gdyby był to wyświetlacz tylko tekstów to rzeczywiście M32 i spoko, ale jeszcze trochę grafiki na nim liczę dla urozmaicenia prezentacji no i przy rozdzielczościach powyżej 64x64, fps juz spada, więc mocy pod maską nigdy zbyt wiele, a zresztą co to za moc nawet w takiej XM w porównaniu do Pic32, że o ARM-ach i OMAPach nie wspomnę.
  • #20 9151208
    asembler
    Poziom 32  
    Hehe i grafike wprowadzasz z klawiatury?
    Atmega da rade 400x320 oczywiscie bez szarosci:-)
    64x64? to attiny85:-)
    Jednak masz skopane założenia.
  • #21 9151410
    PeterBernard314
    Poziom 15  
    Wiem, że da rade, mam działający driver LCD 640x480 zrobiony na Medze64, (autorstwa pewnej firmy z Pomorza), który wyświetla 43FPS o ile dobrze pamiętam.

    Wszystko zależy od tego co liczysz w tej grafice, gdyż nie o same wyświetlanie tutaj chodzi. Np. wygeneruj obraz interferencji dwóch fal sinusoidalnych na płaszczyźnie 64x64pix, Ile Fpsów wyliczysz ?

    Tak na marginesie, to nie przedstawiłem tutaj żadnych założeń więc nie wiem o czym dyskusja. Bo na pewno nie w temacie :)

    A jakaż to różnica między T85 i M32 przecież to ten sam rdzeń tylko różne peryferia...
  • #22 9153978
    LordBlick
    VIP Zasłużony dla elektroda
    PeterBernard314 napisał:
    A jakaż to różnica między T85 i M32 przecież to ten sam rdzeń tylko różne peryferia...
    Pokaż mi w ATtiny85 sprzętowe mnożenie... :P Do do mieszania w RAM, to miewałem takie przypadki, najzabawniejszym było pomylenie "ldi XL, XX" z "lds XL, XX" (w inicjalizacji pętli) przed zapisem indeksowym "sts X, Rxx". Najprościej to zdebugować , zakomentowując etykietę w .dseg i sprawdzić po kolei każdą linijkę, w której jest błąd wywołany brakiem deklaracji tej etykiety.
    mirekk36 napisał:
    W C masz także pełną kontrolę nad wszystkim [...]
    <flame>Samo przejście na "C" nie gwarantuje "kontroli nad wszystkim"... W asm też się da, tylko trzeba się nauczyć pełni jego możliwości, po to są makra i podział kodu na mniejsze pliki... Z tego co zauważyłem większość ludzi piszących w asm sobie utrudnia pracę pisząc bezpośrednie wartości numeryczne, nie nadaje symboli rejestrom, nie używa preprocesora, wrzuca cały kod w jeden plik... Tymczasem współczesny asembler to w połowie C, z tym, że jest to dla mnie ta fajniejsza połowa ;)</flame>
  • #23 9154040
    asembler
    Poziom 32  
    Light-I napisał:
    Tymczasem współczesny asembler to w połowie C, z tym, że jest to dla mnie ta fajniejsza połowa ;)</flame>

    No nie wiem czy mam się obrazić ?

    Czy kompilator ASM zadba o przekroczenie pamieci RAM?
    Pomyłki typu LDI,LDS to chyba kazdy robi:-), Ale dobry kompilator powinien to wychwycić i nawet nie pytaj jak bo nie ma na rynku takich kompilatorów.
  • #24 9154054
    LordBlick
    VIP Zasłużony dla elektroda
    asembler napisał:
    Czy kompilator ASM zadba o przekroczenie pamieci RAM?
    Jak najbardziej :
    ATtiny2313 memory use summary [bytes]:
    Segment   Begin    End      Code   Data   Used    Size   Use%
    ---------------------------------------------------------------
    [.cseg] 0x000000 0x0005f4   1024    500   1524    2048  74.4%
    [.dseg] 0x000060 0x0000d7      0    119    119     128  93.0%
    [.eseg] 0x000000 0x000000      0      0      0     128   0.0%
    
    Assembly complete, 0 errors. 0 warnings
    Może nie szturchnie w bok, krzycząc, "Eee... RAM Ci się kończy...", ale jak dla mnie to wystarczy... :)
  • #25 9154073
    mirekk36
    Poziom 42  
    Light-I --> oczywiście nie mam zamiaru i nie będę się kłócił czy spierał o to który język jest lepszy bo to bez sensu ;) .... Każdy jest tak dobry jak sam programista ;) Jeśli jesteś b.dobry w C i dobrze ci się pisze to czemu nie. Nikt na siłę nikogo nie zmusza przecież.

    Tylko już tak troszkę żartobliwie powiem, że skoro piszesz że współczesny asm to w połowie już prawie C .... to tym bardziej świadczy o tym, że warto przejść na C , natomiast krytyczne miejsca programu jeśli okaże się to konieczne pisać w ASM. To troszkę jak z tą reklamą margaryny o smaku prawie jak masło. Skoro wzorcem jest masło to po co katować się margaryną ? ;)
  • #26 9154075
    asembler
    Poziom 32  
    To dla mnie odpada po błedzie "ram" kompilator powinien conajmniej wyłączyć prąd w połowie dzielnicy to bym sie nauczył pisac porządznie. Jak nie ma bata to musi byc przynajmnije nagroda. Z drugiej strony to bardzo rzadkie przypadki by brakowało RAM-u. Na początku zwracałem na to uwagę ale teraz to tak spowszedniało że dopiero jak coś nie działa to sie patrzy, wieć szturchniecie byłoby pożądane.

    Widomo że język 'C' jest lepszy.

    Kto w ogóle jada to świństwo?
  • #27 9154076
    tmf
    VIP Zasłużony dla elektroda
    Ale problemem nie jest detekcja sytuacji w której zmienne statyczne powodują zajęcie całej pamięci. To zadanie dla przedszkolaka. Pokaż mi program, który uwzględni dynamicznie tworzone struktury danych, w tych chociażby stos? I tu pojawia się problem - zresztą dokładnie taki sam jak w języku C.
  • #28 9154098
    LordBlick
    VIP Zasłużony dla elektroda
    Jeśli C zacznie używać rejestrów w taki sposób, jak tego będę chciał, to bardzo chętnie się przesiądę... Czy w C istnieje szybsza obsługa przerwania niż :
    TIMER0_COMPA: ;Timer0 Clear on Compare
    	in isSREG, SREG		;save SREG
    	mov is0, DataAcc	;save DataAcc
    ;********************************************************
    cLedFlashDelayDecr	; LEDFlash.asm
    cKeyPinDelayDecr	; Key.asm
    ;********************************************************
    	mov DataAcc, is0	;restore DataAcc
    	out SREG, isSREG		;restore SREG
    	reti
    tmf napisał:
    Pokaż mi program, który uwzględni dynamicznie tworzone struktury danych..
    Co prawda dynamicznej nie mam, ale mam statyczną strukturę, praktycznie programowanie obiektowe ;) :
    .dseg
    Speed2BCDStruct:
    	Speed2BCDStatus:
    	.byte 0x01
    	uSpeedBin:
    	.byte 0x02
    	SpeedBCD:
    	.byte 0x03
    Speed2BCDStructEnd:
    [...]
    .cseg
    PrepareSpeed:
    	sts Speed2BCDStatus, Zero	; BIN2BCD_READY
    	LoadX_I_Addr Speed2BCDStruct
    	ldi cL, SpeedBCD-uSpeedBin	; size of uSpeedBin
    	ldi cH, Speed2BCDStructEnd-SpeedBCD	; size of SpeedBCD
    	_call Bin2BCDMultiAdd
    	ret
  • #29 9154112
    asembler
    Poziom 32  
    OK Zmieniam zadanie.
    Wiadomo że ASM jest lepszy.:-)
  • #30 9154125
    mirekk36
    Poziom 42  
    Light-I napisał:
    Czy w C istnieje szybsza obsługa przerwania niż


    Tak ;) tylko powiedz mi czy w 90% przypadków jest to aż tak istotne, że takie przerwanie będzie realizowane ciut wolniej bo po drodze prolog i epilog (czyli odłożenie i pobranie kilku dodatkowych rejestrów na stosie) będzie dłuższy ? Chyba nie. Za to jak potrzeba to co za problem napisać dokładnie taką samą, identyczną procedurę takiego przerwania jako wstawkę w asm ??? co za problem? Czasem właśnie korzystam z takich wstawek gdy jakieś parametry czasowe muszą być "wyżyłowane".

    Mi chodzi o takie zalety C jak właśnie tworzenie takiego powszedniego kodu na co dzień jak pętle, funkcje, operace mnożenia, dzielenia itp itp itd ..... bo to stanowi o tym, że w C szybciej tworzy się i testuje własny kod. Ja tak myślę, że gdyby kolega spróbował tak na poważnie kiedyś - to potem by się nie oderwał. Ja też kiedyś pisałem tylko w asemblerze - ale w tamtych czasach nie było jeszcze takich bajerów jak C dla mikroklocków ;)
REKLAMA