eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.misc.elektronikaPamięć nadpisuje stos (choć powinno być mnóstwo miejsca)Pamięć nadpisuje stos (choć powinno być mnóstwo miejsca)
  • Path: news-archive.icm.edu.pl!news.icm.edu.pl!newsfeed.pionier.net.pl!2.eu.feeder.erj
    e.net!feeder.erje.net!newsfeed.xs4all.nl!newsfeed7.news.xs4all.nl!feeds.phibee-
    telecom.net!border2.nntp.ams1.giganews.com!border1.nntp.ams1.giganews.com!nntp.
    giganews.com!newsfeed.neostrada.pl!unt-exc-01.news.neostrada.pl!unt-spo-a-02.ne
    ws.neostrada.pl!news.neostrada.pl.POSTED!not-for-mail
    Newsgroups: pl.misc.elektronika
    X-Mozilla-News-Host: news://news.tpi.pl:119
    From: Atlantis <m...@w...pl>
    Subject: Pamięć nadpisuje stos (choć powinno być mnóstwo miejsca)
    Date: Tue, 29 Sep 2020 21:35:19 +0200
    User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
    Thunderbird/68.12.0
    MIME-Version: 1.0
    Content-Type: text/plain; charset=utf-8
    Content-Language: pl
    Content-Transfer-Encoding: 8bit
    Lines: 95
    Message-ID: <5f738c77$0$17355$65785112@news.neostrada.pl>
    Organization: Telekomunikacja Polska
    NNTP-Posting-Host: 83.27.224.139
    X-Trace: 1601408119 unt-rea-a-01.news.neostrada.pl 17355 83.27.224.139:33424
    X-Complaints-To: a...@n...neostrada.pl
    Xref: news-archive.icm.edu.pl pl.misc.elektronika:757550
    [ ukryj nagłówki ]

    Walczę teraz z pewną dziwną zagadką, która teoretycznie nie powinna mieć
    miejsca. Chodzi o jeden z moich projektów retro na 6502, ale
    teoretycznie nie powinno mieć to nic wspólnego z procesorem.

    Oprogramowanie napisane w C i skompilowane kompilatorem CC65.
    Kod źródłowy jest dostępny tutaj:
    https://github.com/marekw1986/RetroEG/tree/master/co
    de

    Wszystko zaczęło się od tego, gdy dodałem do projektu funkcje do obsługi
    przycisków - funkcje, które w innym projekcie (na takiej samej płytce,
    tylko z nieco innymi peryferiami) działały bez problemu, a tutaj nie
    chciały. Po ich dodaniu układ zaczął się zachowywać skrajnie nie
    stabilnie - samoczynne resety co kilkadziesiąt sekund, co chwilę
    detekcja fałszywych wciśnięć przycisków itp.

    Dość długo szukałem błędu w kodzie, ale nie mogłem go znaleźć. Upewniłem
    się, że winy nie ponosi uszkodzony RAM albo procesor. Aż w końcu
    zacząłem eksperymentować ze zmiennymi - zmniejszyłem rozmiar niektórych
    buforów, część zmiennych zmieniłem z globalnych na lokalne. Pomogło!
    Samoczynne resety ustały, fałszywe wciśnięcia przycisków występują, ale
    bardzo rzadko.

    Sprawa jest jednak bardzo dziwna, bo wygląda to tak, jakbym teraz był na
    skraju maksymalnego wykorzystani RAM-u. A tak nie powinno być. Układ ma
    8kB pamięci RAM, więc naprawdę dużo jak na taki "kontroler". W pamięci
    nie ma za dużo zmiennych globalnych. Są tylko dwa większe bufory (po 256
    bajtów każdy), poza tym parę mniejszych buforów, trochę stosunkowo
    niewielkich struktur i umiarkowna ilość zmiennych. Nie ma szansy, żeby
    to nagle zajęło zdecydowaną większość RAM-u. Nie widzę też niczego, co
    mogłoby pożerać stos - nie używam nigdzie rekurencji ani nie stosuję
    większych zmiennych globalnych, zbyt zagnieżdżonych wywołań funkcji też
    nie ma.

    Gdyby ktoś wpadł na pomysł, że to wina niewielkiego sprzętowego stosu
    6502 (zaledwie 256 bajtów w pierwszej stronie pamięci) to tłumaczę, że
    CC65 korzysta z programowego stosu, który działa tak, jak we
    współczesnych MCU, zapisując dane od końca pamięci w dół.

    Fragment pliku .map wygenerowanego podczas linkowania projektu
    potwierdza, że zmienne globalne zajmują bardzo małą część pamięci:

    Segment list:
    -------------
    Name Start End Size Align
    ----------------------------------------------------
    ZEROPAGE 000000 000019 00001A 00001
    DATA 000200 00024A 00004B 00001
    BSS 00024B 0004FF 0002B5 00001
    STARTUP 00804B 008066 00001C 00001
    ONCE 008067 008072 00000C 00001
    CODE 008073 00A022 001FB0 00001
    RODATA 00A023 00A1D6 0001B4 00001
    VECTORS 00FFFA 00FFFF 000006 00001

    Plik cfg wygląda następująco:

    MEMORY {
    ZP: start = $0, size = $100, type = rw, define = yes;
    RAM: start = $200, size = $1E00, define = yes;
    ROM: start = $8000, size = $8000, file = %O;
    }

    SEGMENTS {
    ZEROPAGE: load = ZP, type = zp, define = yes;
    DATA: load = ROM, type = rw, define = yes, run = RAM;
    BSS: load = RAM, type = bss, define = yes;
    HEAP: load = RAM, type = bss, optional = yes;
    STARTUP: load = ROM, type = ro;
    ONCE: load = ROM, type = ro, optional = yes;
    CODE: load = ROM, type = ro;
    RODATA: load = ROM, type = ro;
    VECTORS: load = ROM, type = ro, start = $FFFA;
    }

    FEATURES {
    CONDES: segment = STARTUP,
    type = constructor,
    label = __CONSTRUCTOR_TABLE__,
    count = __CONSTRUCTOR_COUNT__;
    CONDES: segment = STARTUP,
    type = destructor,
    label = __DESTRUCTOR_TABLE__,
    count = __DESTRUCTOR_COUNT__;
    }

    SYMBOLS {
    # Define the stack size for the application

    __STACKSIZE__: value = $0200, type = weak;
    }

    Ktoś ma jakiś pomysł co do tego, gdzie można szukać przyczyny? Na chwilę
    obecną urządzenie działa w miarę stabilnie, jednak chciałem dodać
    jeszcze kilka funkcji, które będą wymagały trochę RAM-u, więc przedtem
    muszę rozwiązać ten problem.

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: