On 20.08.2020 14:36, J.F. wrote:

> Opis by sugerowal, ze te 245 wystawia dane na magistrale w niepożądanym
> momencie.

To było moje pierwsze skojarzenie. Chociaż dziwne jest to, że program
nie tylko rejestruje samoczynne (fałszywe) naciśnięcia klawiszy, ale też
prawidłowo reaguje na te prawdziwe.
Przypomniałem sobie też, że kiedyś już testowałem działanie tego portu,
co jakiś czas sprawdzając w pętli, czy po wciśnięciu przycisków zmieni
się wartość odczytywana z portu - zmieniała się, a program działał
stabilnie i nie wieszał się. Czyli wyglądałoby na to, że to jednak nie
sam odczyt z portu jest czynnością destrukcyjną z punktu widzenia
stabilności programu.

Moim drugim pomysłem była funkcja zajmująca się debouncingiem. Tylko jak
już pisałem, ta działa prawidłowo w innym urządzeniu opartym na tej
samej architekturze.

Funkcja sprawdzania przycisku wygląda następująco:



> Ale ... powod moze byc tez zupelnie inny.
> Chocby czysto softwareowy - jakis blad w funkcjach przyciskow, zla
> obsluga przerwania itp.

O tym też myślałem, jednak nie pasuje mi żadna z potencjalnych przyczyn,
które brałem pod uwagę. Przerwania nie są wykorzystywane do obsługi
przycisków. Wszystkie inne funkcjonalności oparte na przerwaniach (UART
RX, timer, RTC) działają prawidłowo.
Myślałem o potencjalnym nadpisaniu stosu, ale:
- Niewielki sprzętowy stos 6502 jest wykorzystywany przez kompilator
CC65 (to z niego korzystam, niewielkie fragmenty kodu pisząc w asemblerze).
- Do większości operacji wykorzystywany jest programowy stos, który
zaczyna pisać w górnej części pamięci RAM, idąc w dół.
- Układ posiada 8 kB pamięci RAM, co jest stosunkowo dużą wielkością jak
na tego typu konstrukcję.
- Do tej pory nie korzystam ze zbyt dużej liczby zmiennych i jest raczej
mało prawdopodobne, żeby stos zaczął nadpisywać pamięć.
- Zwłaszcza, że staram się ostrożnie gospodarować stosem. Nie tworzę
zbyt dużych ilości zmiennych statycznych wewnątrz funkcji (jeśli to
możliwe wykorzystując statyczne zmienne globalne, dzielone między
funkcjami), nie przekazuję zbyt dużej ilości parametrów (zamiast tego
posługuję się np. wskaźnikami na strukturę albo zmiennymi globalnymi
ustawianymi przed wywołaniem funkcji). Staram się też unikać
zagnieżdżonych wywołań funkcji i rekurencji.



> I jak zwykle - daj wolniejszy zegar, jak przejdzie ... moze cos nie
> wyrabia szybkosciowo.

Zegar już teraz jest wolny - jedynie 1 MHz. Właśnie z uwagi na duże
moduły połączone taśmą ze złączami IDC. To raczej sporo poniżej
możliwości WDC65C02 oraz wymagań współczesnych układów HCT...