Diagnozer joysticków (np. do Pegasusa) na Atmega 8

Diagnozer joysticków (np. do Pegasusa) na Atmega 8

Projekt
Przyszedł wreszcie czas naprawić posiadane przeze mnie joysticki do Pegasusa. Zwykle uszkodzeniu (urwaniu) uległ kabel lub taki niesprawdzony/niesprawny joystick został zakupiony bez znajomości jego przeszłości. Jeśli kable się urwały, to mamy mały problem, bo płytka PCB joysticka składa się z jednego glutowego układu scalonego (rejestr przesuwny + generator do przycisków TURBO) i ciężko stwierdzić, gdzie co podłączyć.



A podłączanie jak leci aż za którymś razem zadziała może się zakończyć tragicznie:
- zewrzemy dwa wyjścia,
- podłączymy odwrotnie VCC i GND.

Protokół komunikacyjny z joystickiem Pegasusa
Kontrolery mają czteropozycyjny krzyżak (d-pad), przycisk select, start, A, B, czasem Turbo A, Turbo B. Złącze joysticka składa się z 5 pinów:
- GND: masa,
- VCC: zasilanie +5V,
- STROBE: strob zapisu – konsola generując opadające zbocze rozpoczyna odczytywanie stanu klawisy
- CLK: sygnał zegarowy – kolejne zbocza narastające generowane przez konsolę powodują wystawienie przez joystick na złącze DATA stanu kolejnych przycisków w kolejności: A,B, SELECT, START, GÓRA, DÓŁ, LEWO, PRAWO
- DATA: wystawiane przez konsolę stany przycisków (0 – przycisk wciśnięty, 1 – przycisk zwolniony, otwarty kolektor)

Założenia
Postanowiłem więc stworzyć mini-diagnozer do joysticków, który w zamyśle ma działać tak:
1. podłączamy do niego joystick od Pegasusa,
2. w diagnozerze wybieramy, jaki klawisz joysticka testować,
2. na joysticku trzymamy wciśnięty wcześniej ustawiony klawisz (np. START),
3. wciskamy przycisk na diagnozerze,
4. diagnozer testuje wszystkie możliwe kombinacje połączenia przewodów i:
- jeśli znajdzie działającą kombinacje i jest ona poprawną – wyświetla komunikat OK,
- jeśli znajdzie działającą kombinacje, ale nie jest ona poprawna – wyświetla, które połączenia są zamienione, np. G9 – na 9 pinie jest MASA, S5 – na 5 pinie jest sygnał Strobe, c3 – na 3 pinie jest sygnał CLK;
- jeśli żadna kombinacja jest niepoprawna – wyświetla komunikat: ER (error).

Wystarczy więc – jeśli kabelki w joysticku się oderwały – przylutować je, jak leci, a następnie podłączyć do diagnozera. Wszystkie sygnały w diagnozerze mają w szeregu rezystor 180 ograniczający prąd, więc podczas testowania nie ma zwarć i joystick nie ulegnie uszkodzeniu. Procesor ze swoich wyjść zasila (VCC+gnd) badany joystick. Diagnozer ma możliwość wysterowania dowolnych z 9 pinów DB9, więc w przyszłości można dodać implementację testowania innych rzeczy (np. myszki COM, klawiatury – z przejściówką, itp).

Efekt
Dzięki urządzeniu udało się uratować 4 joysticki, a 2 zostały wykryte jako uszkodzone – pewnie słusznie, bo na teście diod w mierniku jeden z pinów joysticka w ogóle nie ma połączenia do żadnego z pozostałych.


Ciekawostki
Chciałem, aby PCB joysticka było jak najmniejsze – stąd na PCB tylko:
- jeden przycisk do rozpoczęcia testu,
- wyświetlacz LED 7 segmentowy w minimalistycznym połączeniu – jedynie 2 rezystory ograniczające prąd dla każdej z cyfr, wadą jest oczywiście jaśniejsze świecenie cyfry gdy mniej segmentów jest zapalonych (można to programowo zminimalizować przez PWM)
- AVR Atmega 8 taktowana wewnętrznym kwarcem 8 MHz
- całość zasilana z portu programatora ISP
- bardzo chciałem wszystko zmieścić na jednej warstwie











Kłopoty
Od dłuższego czasu napisałem sobie specjalne makra pod AVR definiujące wszystkie porty, aby np. zamiast pisać:


móc napisać:



Makra te definiują w stałej np. A0 wszystkie informacje o tym porcie, tj:
- adres rejestru DDR dla A0 (DDR),
- adres rejestru PORT dla A0 (PORTA),
- adres rejestru PIN dla A0 (PINA),
- numer portu dla A0 (0).
Każda z tych zmiennych jest 8-bitowa, potrzebujemy więc 32 bity:


i teraz, jeśli chcemy się dowiedzieć np. jaki jest rejestr DDR dla końcówki A0, po prostu wyłuskujemy to, np. makrem:


zatem makro as_output wygląda tak:


Ponadto sprytny kompilator C widząc, że wszystko dzieje się na stałych, zoptymalizuje kod tak, że wywołanie tych funkcji ograniczy się do dwóch rozkazów assemblera, np:


czyli w zasadzie wyjdzie tak samo, jakbyśmy napisali.



Dużo czytelniej, a tak samo szybko. Często jednak kusi nas do tego stopnia, że zamiast przekazywać takie końcówki wprost do funkcji, chcielibyśmy stworzyć ich tablicę, np:

.
Słowem klucz jest tutaj const – jeśli dodamy je przed deklaracją tablicy, kompilator uzna, że wartości tablicy nie będą się zmieniać, więc będzie mógł od razu stwierdzić, że powyższe wywołanie będzie równoznaczne temu z przykładu wyżej. Często jednak chcemy np. iterować po takiej tablicy lub wręcz zmieniać jej wartość w trakcie programu – wtedy nie możemy dać const. I tutaj pojawia się mój kłopot – kompilator wtedy nie może rozwinąć takiego makra do jednej instrukcji assemblera, lecz musi te wszystkie przesunięcia bitowe zamienić na rozkazy procesora. I tu pojawia się problem – kompilator zamienia to w taki sposób, że już instrukcja ustawienia bitu nie jest tożsama z instrukcją sbi/cbi z Assemblera. Kompilator najpierw odczytuje do rejestru wartość np. zmiennej DDRC, portem ustawia w niej odpowiedni bit, a potem tak zmodyfikowaną wartość z powrotem zapisuje do rejestru DDR. Problem jest jednak taki, że gdy działamy na przerwaniach, to takie ciągi instrukcji mogą być przerwane przerwaniami i w rzeczywistości dostajemy niezłą sieczkę na portach – sam tego doświadczyłem, bo gdy program testował joystick, to wartość na wyświetlaczu siedmiosegmentowym, sterowanym w przerwaniu zmieniała się jak szalona. W obecnej chwili rozwiązałem to tak, że przed każda z instrukcji np. as_input(...), as_output(...), out(.., 0), out(..., 1), in(...) wyłączam przerwania, a po – włączam. Jest to jednak nieekonomiczne, macie jakiś pomysł jak zmusić kompilator, aby kompilował te instrukcje z wykorzystaniem rozkazów sbi/cbi ?

W obecnej chwili – np. gdy przed deklaracją tablicy wręcz dodam „volatile”, kompilator kompiluje mi to do: