Jak już parę razy pisałem od jakiegoś czasu eksperymentuję ze starymi
systemami mikroprocesorowymi. Powody nie są praktyczne, a czysto
dydaktyczne - to okazja do bardziej niskopoziomowego wejścia w tę
tematykę i rozpoczęcie zabawy z asemblerem.
Jakiś czas temu wykonałem płytkę bazową z WDC65C02:
https://hackaday.io/project/163671-6502-retro-contro
ller-board
Potem zacząłem dodawać do niej moduły, np.
https://hackaday.io/project/167980-retrogeiger

W roli portu wejściowego wykorzystuję zwykle układ 74HCT245. Z jednej
strony np. przyciski rezystorami podciągającymi, z drugiej magistrala
danych, wejście aktywujące sterowane bramką NAND do której wejść
podłączony jest dekoder adresów i sygnał RD (6502 go co prawda nie
generuje, ale na głównej płytce dodałem kilka odpowiedzialnych za to
bramek, żeby dało się bezpośrednio podpiąć również układy przeznaczone
do pracy na magistrali intela.

Zarówno stronę sprzętową, jak i programową udało mi się już przetestować
na jednym projekcie - przyciski działają w nim prawidłowo.
Problemy zaczęły się natomiast, gdy spróbowałem przenieść to samo
rozwiązanie do innego projektu. Tam zastosowałem ten sam układ, z tą
jedną różnicą, że przyciski i magistrala są podłączone do 245 z
odwrotnej strony, ale to nie powinno mieć znaczenia, bo odpowiednio
zmieniony został stan na wejściu DIR.

Okazało się jednak, że w tym drugim urządzeniu to rozwiązanie nie chce
już działać. To znaczy przyciski niby działają - ich wciśnięcia sa
rejestrowane przez program, ale jednocześnie pojawia się niestabilność
systemu. Po pierwsze pojawiają się fałszywe sygnały z przycisków, po
drugie urządzenie zaczyna działać niestabilnie i co jakiś czas resetuje
się. Problem znika, jeśli zakomentuję linie odpowiedzialne za
sprawdzanie stanu przycisków.

Na chwilę obecną sprawdziłem już następujące kwestie:
- Na pewno port wejściowy jest podłączony do prawidłowego wyjścia
dekodera adresów i w programie sprawdzany jest właściwy, odpowiadający
mu adres.
- Na pewno na wejściu DIR wymuszony jest właściwy stan i przyciski
podłączone są do wejść układu 245, a magistrala danych do jego wyjść.
- Do tego samego dekodera adresów (74HCT138) na płytce podłączone jest
także jeszcze jedno urządzenie (wyświetlacz hd44780) i ono działa
prawidłowo.
- Przyciski są podciągnięte do VCC. Próbowałem zmniejszyć wartości
rezystorów podciągających z 10k do 3,3k - nie pomogło.
- Próbowałem wymienić 245 na inny egzemplarz. Wymieniłem także
towarzyszące mu bramki 74HCT00. Nie pomogło.

Spróbuję jeszcze wymienić dekoder adresów (138), ale powoli już kończą
mi się pomysły. Ktoś ma może pomysł, gdzie jeszcze mogę szukać przycyzny?

do góry

Użytkownik "Atlantis" napisał w wiadomości grup
dyskusyjnych:5f3e204e$0$520$6...@n...neostrada.
pl...
>Jakiś czas temu wykonałem płytkę bazową z WDC65C02:
>https://hackaday.io/project/163671-6502-retro-contr
oller-board
>Potem zacząłem dodawać do niej moduły, np.
>https://hackaday.io/project/167980-retrogeiger

>W roli portu wejściowego wykorzystuję zwykle układ 74HCT245. Z jednej
>strony np. przyciski rezystorami podciągającymi, z drugiej magistrala
>danych, wejście aktywujące sterowane bramką NAND do której wejść
>podłączony jest dekoder adresów i sygnał RD (6502 go co prawda nie
>generuje, ale na głównej płytce dodałem kilka odpowiedzialnych za to
>bramek, żeby dało się bezpośrednio podpiąć również układy
>przeznaczone
>do pracy na magistrali intela.

>Zarówno stronę sprzętową, jak i programową udało mi się już
>przetestować
>na jednym projekcie - przyciski działają w nim prawidłowo.
>Problemy zaczęły się natomiast, gdy spróbowałem przenieść to samo
>rozwiązanie do innego projektu. Tam zastosowałem ten sam układ, z tą
>jedną różnicą, że przyciski i magistrala są podłączone do 245 z
>odwrotnej strony, ale to nie powinno mieć znaczenia, bo odpowiednio
>zmieniony został stan na wejściu DIR.

>Okazało się jednak, że w tym drugim urządzeniu to rozwiązanie nie
>chce
>już działać. To znaczy przyciski niby działają - ich wciśnięcia sa
>rejestrowane przez program, ale jednocześnie pojawia się
>niestabilność
>systemu. Po pierwsze pojawiają się fałszywe sygnały z przycisków, po
>drugie urządzenie zaczyna działać niestabilnie i co jakiś czas
>resetuje
>się. Problem znika, jeśli zakomentuję linie odpowiedzialne za
>sprawdzanie stanu przycisków.

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

Cos mi chodzi po glowie, ze 245 byla "wzmocniona" w stosunku do
"standardowy TTL", aby mogla lepiej sterowac magistralą, i cos mi
chodzi po glowie, ze moze nie bylo to symetryczne ... czyli jedna
strona byla "magistralowa" ... ale to bylo LS, HCT trzeba by doczytac.

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

>Na chwilę obecną sprawdziłem już następujące kwestie:
>- Na pewno port wejściowy jest podłączony do prawidłowego wyjścia
>dekodera adresów i w programie sprawdzany jest właściwy,
>odpowiadający
>mu adres.
>- Na pewno na wejściu DIR wymuszony jest właściwy stan i przyciski
>podłączone są do wejść układu 245, a magistrala danych do jego wyjść.

Na stale ? Choc to w sumie bez znaczenia - czytac chcesz, to kierunek
umozliwia zaklocenie magistrali.

>- Do tego samego dekodera adresów (74HCT138) na płytce podłączone
>jest
>także jeszcze jedno urządzenie (wyświetlacz hd44780) i ono działa
>prawidłowo.

Dobrze by bylo obejrzec sygnaly sterujace na oscyloskopie - czy OE
dociera do 745 odpowiednio szybko, i odpowiednio szybko zanika.

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

J.

do góry

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...

do góry

Brakująca funkcja do sprawdzania przycisku:

https://pastebin.com/E5PU9uPN

do góry

Atlantis <m...@w...pl> napisał(a):
> - 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)

Tego nie łapię. Zmienne statyczne w funkcjach nie są stosie. Gdyby były na
stosie, nie mogłyby być statyczne.

--
Grzegorz Niemirowski
https://www.grzegorz.net/

do góry

On 20.08.2020 16:44, Grzegorz Niemirowski wrote:

> Tego nie łapię. Zmienne statyczne w funkcjach nie są stosie. Gdyby były
> na stosie, nie mogłyby być statyczne.

Błąd wynikający z pisania z rozpędu. Oczywiście miałem na myśli
niestatyczne zmienne lokalne. Zamiast nich stosuję albo statyczne
zmienne globalne (jeśli można oszczędzić trochę pamięci, np.
współdzieląc między funkcjami bufory albo zmienne przechowujące wartości
tymczasowe) albo statyczne zmienne lokalne.

do góry

Wymiana układy 74HCT138 też nie pomogła. Tym samym wymieniłem wszystkie
układy współpracujące z 74HCT245. W akcie desperacji podmieniłem też
wszystkie "mostki" z kynaru, jakie miałem na płytce - w razie gdyby
któryś nie łączył. Też nic.

Sprawdziłem też, czy przypadkiem winy nie ponosi kod w funkcjach
obsługujących naciśnięcie przycisku. Podmieniłem go na proste zapalanie
i gaszenie diody. Pomimo tego problem ciągle występuje. Znika dopiero
wtedy, gdy zakomentuję w pętli głównej funkcje sprawdzające stan przycisków.

Tak więc albo problem jest programowy i biblioteka do obsługi przycisków
coś miesza (co byłoby dziwne, bo na innym urządzeniu działa), albo coś
jest nie tak ze stosem, albo faktycznie chodzi o kierunek transmisji
74HCT245. Tyle tylko, że zanim zabiorę się za przeprojektowywanie
modułu, wolałbym wykluczyć przyczyny programowe.

do góry

W dniu 20.08.2020 o 16:37, Atlantis pisze:
> 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.

Czy strobujesz sygnał OE w 74LS245 z sygnałem zegarowym FI2 w 6502 ?

Z dekodera adresów prawdopodobnie dostajesz stan niski przez cały czas
trwania stabilnego adresu na magistrali adresowej. Wyjścia buforów
powinny być aktywne tylko w czasie gdy jest adres, stan wysoki na R/W i
stan wysoki na Fi2



--
Pozdrawiam
Grzegorz

do góry

On 20.08.2020 20:09, Grzegorz Kurczyk wrote:

> Czy strobujesz sygnał OE w 74LS245 z sygnałem zegarowym FI2 w 6502 ?

Nie bezpośrednio. Na głównej płytce z CPU mam prosty układ z bramek
74HCT00, który z sygnałów RW oraz PHI2 generuje "intelowskie" sygnały RD
i WR, które są wyprowadzone na magistralę systemową. Dzięki temu łatwiej
korzystać z pamięci i peryferiów zaprojektowanych dla tej magistrali.
Sygnał RD działa prawidłowo, bo wykorzystuję go do komunikacji z innymi
peryferiami. np. układem RTC M6242B.

Ten właśnie wygenerowany sygnał RD, razem z wyjściem dekodera adresów
steruje wejściem OE 245, za pośrednictwem bramki NAND. Oczywiście obydwa
sygnały są wcześniej zanegowane, ponieważ są aktywne w stanie niskim.


> Z dekodera adresów prawdopodobnie dostajesz stan niski przez cały czas
> trwania stabilnego adresu na magistrali adresowej. Wyjścia buforów
> powinny być aktywne tylko w czasie gdy jest adres, stan wysoki na R/W i
> stan wysoki na Fi2

I właśnie taka kombinacja sygnałów R/W i Fi2 generuje sygnał RD, który z
kolei razem z wyjście dekodera adresów steruje wejściem OE 245.

W podobny sposób mm to zrealizowane w drugiej konstrukcji (tej, która
działa prawidłowo). Jedyna różnica to fakt, że wejścia/wyjścia A i B
pracują w odwrotnej konfiguracji. No i fakt, że w tym nowszym urządzeniu
zrobiłem dekoder adresów na GAL-u, a nie 74HCT138 i paru bramkach.

do góry

Użytkownik "Atlantis" napisał w wiadomości grup
dyskusyjnych:5f3e8abf$0$520$6...@n...neostrada.
pl...
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.

Chyba sie nie rozumiemy - mowie o przedluzeniu dzialania portu o np
pol impulsu zegara, co powoduje, ze w nastepnym cyklu dane z portu
nakladaja sie na dane z pamieci i procesor odczytuje smieci jako
rozkaz.
Albo dekoder adresow uruchamia 245 dodatkowo w zlym momencie.

>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.

Byc moze, ale ... mozliwe tez, ze wtedy program uzywa niekolidujacych
adresow ...

>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:

>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).

Wpisz w obszar stosu np 55h, a ppotem zobacz ile ich zostalo.

>> 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...

Daj 500kHz czy 250kHz i sie zobaczy czy to w tym problem.

Po tylu systemach powinienes miec juz taki generatorek gotowy do
podpiecia :-)

J.

do góry