Autor Wątek: Kontrolery Arduino  (Przeczytany 53277 razy)

0 użytkowników i 1 Gość przegląda ten wątek.

Odp: Kontrolery Arduino
« Odpowiedź #45 dnia: Lipca 27, 2016, 23:41:29 »
Witam

Obserwuje ten wątek i jestem bardzo ciekaw rezultatów. Czytając go wpadłem na pomysł, czy nie dało by rady stworzyć modułu wejścia i wyjścia dla Arduino do HSC. Oczywiście, jeżeli codeking by pomógł. Nawet taki najprostszy czyli odczytujemy dane z symulatora i wysyłamy na serial monitor do Arduino o odwrotnie. Później napisanie szkicu do Arduino to już da radę. Od jakiegoś czasu "bawię" się Arduino i można dużo zrobić. Wyświetlacze np 7-segmentowe czy inne oraz przyciski i encodery. Robiłem testy z encoderami i przy podłączeniu bezpośredni do Arduino korzystając z biblioteki Rotary.h bardzo ładnie działało z różnymi encoderami, tymi tańszymi również. Testy robiłem z diodami i było ok nie gubił impulsów nawet przy szybkim obracaniu. Można stworzyć projekt na innej atmedze / nie trzeba korzystać z gotowych płytek / trzeba tylko kwarc parę kondensatorów i jeden opornik i mamy własne Arduino. Sam zrobiłem takie na atmedze 328p oraz atmedze 16 gdzie jest już dużo portów wejścia wyjścia. Można jeszcze dodać dodatkowe kontrolery np do wyświetlaczy 7-segment np / MAX7219 czy TM1637 / czy układy MCP23017 i już można budować.

Pozdrawiam Zając
Zapraszam na stronę projektu www.simproject.zajac.waw.pl

Odp: Kontrolery Arduino
« Odpowiedź #46 dnia: Lipca 28, 2016, 06:01:54 »
Bardzo się cieszę, że się znowu pojawiłeś na forum.  Dla mnie Arduino jest rewelacją z kilku powodów. Najważniejszy to biblioteki drugi to cena. Mam teraz ProMicro za 23 zł i trochę droższe UNO i Leonardo. Można to zrobić samemu i będzie jeszcze taniej to fakt.
Zajmuję się Arduino od niedawna i dopiero poznaję jego możliwości. Testowałem ostatnio tak jak wspomniałem MMJoy2 i jestem pod wrażeniem. Coś podobnego do HSC codeking, ale nie tak uniwersalne, ma ograniczenia. Wg. mnie to HSC jest najlepszą platformą dla budowniczych kokpitów czy paneli dla symulatorów. Dla mnie barierą jest zrobienie programu do przechwytywania danych z symulatora BMS4 przez Arduino. To zrobił codeking w HSC. Na forum są programiści, którzy to zrobili dla swoich kontrolerów. Jest biblioteka Lightning, ale trzeba wiedzieć jak z niej korzystać.
Wracając do moich doświadczeń to mogę stwierdzić, że SimOut oraz SimIN i HSC załatwia większość spraw związanych z budową kokpitów.
Kontrolery Arduino mogą stanowić uzupełnienie ze względu na cenę oraz małe wymiary. Można je umieścić w panelach np. ICP. Stosując interfejs SPI lub I2C oraz odpowiednie układy można zrezygnować z budowy diodowych matryc.
Jedną z zalet DMkeys8 jest dopracowana platforma do konfiguracji, możliwość przypisania do przycisków sekwencji kombinacji klawiatury oraz możliwość konfigurowania enkoderów.
Co do mnie to będę nadal eksperymentował z Arduino, ale pod kątem zastosowania w symulatorach. Z DCS nie ma problemu ale jest problem z BMS4. Tutaj przydałby się programista taki jak codeking.
 Dobrze, że Zając wspomniał o Rotary.h to daje szansę na zastosowanie enkoderów. Ciekawe czemu  dekodery w MMJoy2 u mnie przekłamują. Nie chce mi się wierzyć , że twórca tego nie przewidział. Na zakończenie dodam, że jestem coraz większym optymistą, ponieważ temat zainteresował kolegów a to rokuje nadzieję.

Odp: Kontrolery Arduino
« Odpowiedź #47 dnia: Lipca 28, 2016, 09:37:19 »
cd
Dzięki pomocy kolegi 3.14 ter mogę kontynuować testy szkicu (skryptu) macieja. Ponieważ nie mam odczytu przycisków podłączonych do MCP23017 to mam pytania do macieja.
Pierwszy MCP23017 jest na adresie 20 (A0-A2 na gnd) drugi na 27 (A0-A2 na VCC) tak jak u macieja. Sprawdziłem rejestry w setup oraz loop skrypu z katalogiem MCP23017. Adresy rejestrów zgadzają się z adresami BANK = 0. Ale mam wątpliwość co do odczytu rejestru A oraz B w pętli loop.
Mam na myśli ten fragment a konkretnie linijkę z pogrubionymi literami

Wire.beginTransmission(0x20);
Wire.write(0x13); // read from port B
Wire.endTransmission();
Wire.beginTransmission(0x20);
Wire.requestFrom(0x20,1);
c = Wire.read();
Wire.endTransmission();
Jest instrukcja write a nie read. Czy możesz to wyjaśnić. Ja mam na szeregowym monitorze tylko same jedynki (pullup) i nie ma reakcji na zwieranie do gnd co sugeruje brak odczytu portu.

Odp: Kontrolery Arduino
« Odpowiedź #48 dnia: Lipca 28, 2016, 10:39:52 »
Tak wtrącając jeszcze może odnośnie programowania na ardku, ja nie posiadając kiedyś fizycznie testowałem rozwiązania na programach typu:
http://www.smashingrobotics.com/arduino-simulators-lineup-start-developing-without-real-board/ - jak zobaczyłem, że coś tam jednak potrafię napisać wtedy zakupiłem pierwsze :P co by nie marnować pieniędzy ;)

Odp: Kontrolery Arduino
« Odpowiedź #49 dnia: Lipca 28, 2016, 11:36:04 »
Witam

Chciałbym pokazać jak encoder u mnie działa - oto filmik https://www.youtube.com/watch?v=RI_ky6x1peM . Ta biblioteka rotary.h będzie działać pewnie tylko na arduino a nie na MMJoy2. Można ją wykorzystać w szkicach arduino, z tego co poczytałem to obsługuje ona różne typy encoderów. Na filmiku widać, że próby robiłem na "własnym" Arduino na Atmedze16, które również wysyła na serial monitor dane / mogą być dowolne / i teraz jakby się udało je odczytać w HSC i wysłać do symulatora ti było by fajnie. Obok Atmegi16 widać MCP23017. Na razie przyciski obsługuje, ale nie mogę odpalić biblioteki rotary.h do encodera podpiętego do MCP23017. Będę próbował i dam znać.
Zapraszam na stronę projektu www.simproject.zajac.waw.pl

Odp: Kontrolery Arduino
« Odpowiedź #50 dnia: Lipca 28, 2016, 12:21:29 »
Uprzedzę odpowiedź kolegi Macieja.

Wire.write(0x13); // read from port B

Ta instrukcja ustawia adres rejestru z którego będziemy czytać dane poźniej, w następnych krokach.
W tzw. pseudo-kodzie wygląda to tak:
- wyślij komendę I2C start, celuj w odbiornik o oadresie 0x20
- ustaw adres rejestru - musimy najpierw podać skąd chcemy pobrać dane
- wyślij I2C stop. W tym momencie wewnętrzny adres MCP23017 ustawiony jest na 0x13, czyli GPIOB (BANK=0).
Dalej startujemy transmisję jeszcze raz, ale tym razem będziemy odczytywać jeden bajt z MCP23017. Odczyt nastąpi z adresu ustawionego wcześniej.

Ustawienie BANK=0 przeznaczone jest w zasadzie do sekwencyjnego odczytywania/zapisywania portów A i B. Część kodu Macieja odpowiedzialną za odczyt z MCP23017 można uprościć i zoptymalizować do dwóch funkcji. Niestety nie mam teraz pod ręką układu, żeby go przetestować, ale powinno działać. Starałem się dokładnie komentować kod, myślę, że powinien być zrozumiały. Cała operacja czytania portów z MCP23017 zgrupowana jest w jedną funkcję, która jako argument pobiera adres I2C kości, a wyrzuca stan wszytkich przycisków w 16 bitowym słowie.

uint16_t buttonBank1, buttonBank2; //zmienne przechowujace stan przyciskow

void initMCP23017(uint8_t slaveAddr); //deklaracja funkcji inicjalizujacej
uint16_t readMCP23017(uint8_t slaveAddr); //deklaracja funkcji odczytywania stanu portow


/*
Funkcja inicjalizujaca uklad MCP23017
wszystkie piny jako input + pullup
argument: adres I2C
BANK0 = 0 - wykorzystamy sekwencyjny zapis,
adres jest automatycznie inkrementowany
po kazdej operacji zapisu bajtu
*/


void initMCP23017(uint8_t slaveAddr)
{
// IODIRA -> IODIRB
Wire.beginTransmission(slaveAddr);
Wire.write(0x00); //IODIRA
Wire.write(0xFF); //portA = wejscia, adres skacze do 0x01=IODIRB
Wire.write(0xFF); //portB = wejscia
Wire.endTransmission();

// Pull-ups
Wire.beginTransmission(slaveAddr);
Wire.write(0x0C); //GPPUA
Wire.write(0xFF); //podciagnij wejscia A do VCC,nowy adres = 0x0D=GPPUB
Wire.write(0xFF); //podciagnij wejscia B do VCC
Wire.endTransmission();
}

// Funkcja odczytujaca stany portow GPIOA i GPIOB
// stan zwracany jest w postaci 16bitowego slowa,
// gdzie jeden bit odpowiada jednemu przyciskowi

uint16_t readMCP23017(uint8_t slaveAddr)
{
uint8_t output[2];
uint8_t index = 0;

Wire.beginTransmission(slaveAddr); //I2C Start, wyslij adress
Wire.write(0x12); //ustaw wewnetrzny adres na GPIOA
Wire.endTransmission(); //I2C stop
Wire.beginTransmission(slaveAddr); //I2C Start, wyslij adres
Wire.requestFrom(slaveAddr,2,true); //grzecznie popros o 2 bajty
//po odczytaniu GPIOA wewnetrzny adres
//automatycznie zostanie zwiekszony o 1.
//czyli wyladuje na GPIOB
//"true" na koncu generuje I2C stop i zwalnia
//magistrale, Wire.endTrasmission nie jest potrzebny
while (Wire.available())
{
output[index] = Wire.read(); //wpisz GPIOA i B do tablicy
index++;
}

return uint16_t(output[0] | ((output[1])<<8)); //zgrupuj oba bajty w 16 bitowe slowo
}

Użycie funkcji wygląda następująco:
//inicjalizacja obu ukladow:
initMCP23017(0x20);
initMCP23017(0x27);

//potem gdzies w programie
buttonBank1 = readMCP23017(0x20);
buttonBank2 = readMCP23017(0x27);

W sumie właśnie odkryłem, że istnieje już biblioteka do MCP23017 . Ech.. arduino ;) Może ten kod powyżej będzie miał chociaż wartość edukacyjną :)

Być może nadeszła odpowiednia chwila, żeby odkurzyć mój stary projekt kontrolera do Iłka i pomajstrować co nieco:


W kwestii enkoderów, pan Marek w dość przystępny sposób objaśnia ich działanie, pułapki i inne kruczki, które mogą się pojawić podczas ich obsługi:
http://mirekk36.blogspot.de/2016/02/enkoder-obrotowy-od-podstaw.html

Jeśli chodzi zaś o magistralę I2C to jest ona raczej "krótkiego zasięgu". Zbyt długie kable i spora liczba odbiorników zwiększa pojemności pasożytnicze na liniach, przez to mogą pojawić się przekłamania i błędy. Trzeba mieć to na uwadze projektując systemy modułowe.

Jeszcze takie pytanie: nie macie problemów z drganiami styków w przyciskach? Typu przycisk wyzwalany jest kilka razy itp.? Eliminacja drgań styków to pierwsza rzecz jaką dodaję, jesli urządzenie ma przyciski. Jest taki dość sprytny sposób na filtrowanie drgań kilku-kilkunastu wejść naraz. Wymaga jedynie przerwania Timera ustawionego na ok. 5-10 ms.

/Piter

Odp: Kontrolery Arduino
« Odpowiedź #51 dnia: Lipca 28, 2016, 12:29:42 »
Dzięki koledzy za włączenie się do tematu. Te symulatory pod Arduino są bardzo ciekawe. Co do enkoderów to faktycznie pięknie działają nie ma przekłamań.
Zajac wspomniałeś, że twoja MCP23017 odczytuje przyciski. W szkicu macieja musi być jakiś błąd. W poprzednim post pokazałem ten fragment szkicu, który ma odczytać port A oraz B i zapisać do zmiennej c. Moje MCP23017 są na adresach 20 oraz 27. Czy możesz pokazać fragment twojego szkicu odczytującego porty A i B.
Ja próbowałem w MMJoy2 odczytywać enkodery zarówno podpięte do pinów MroMicro jak i do rejestrów CD4021. W obu przypadkach enkodery przekłamywały.

Odp: Kontrolery Arduino
« Odpowiedź #52 dnia: Lipca 28, 2016, 12:59:48 »
Cytuj
Jeszcze takie pytanie: nie macie problemów z drganiami styków w przyciskach? Typu przycisk wyzwalany jest kilka razy itp.? Eliminacja drgań styków to pierwsza rzecz jaką dodaję, jeśli urządzenie ma przyciski.
Ja stosuję rozwiązanie Damosa, czyli DMKeys8, który emuluje klawiaturę. W platformie Damosa konfigurującego DMKeys8 są różne możliwości eliminacji niedoskonałości elementów elektronicznych typu styki czy enkodery. W wspomnianym MMJoy2 są także do wyboru  3 timery w których można ustawiać opóźnienia, ale na enkodery (przekłamania) to nie ma chyba wpływu. Damos zastosował możliwość zwiększenia ilości próbowania zboczy i uśredniania wyniku. W gorszych enkoderach zbocza prawie na siebie nachodzą.
Dzięki  Piter za wyjaśnienia oraz przykłady. Muszę to przetrawić. Widzę, że mamy fachowca od programowania to jest optymistyczne

Odp: Kontrolery Arduino
« Odpowiedź #53 dnia: Lipca 28, 2016, 17:38:21 »
Już działa na szkicu macieja. Dziękuję Piter za pomoc w zrozumieniu działania MCP23017. Bez Twojej pomocy nie dał bym rady, mam na myśli zmiany wirtualnych COM przy wgrywaniu do kości. Nie mam jeszcze połączenia na TX, RX zrobię to później. Teraz korzystam z USB, ale mam prostą metodę. Przy testach które wymagają wgrania szkicu sprawdzam po wgraniu na menadżer urządzeń jaki wybrał COM i przy szeregowym monitoringu ustawiam ten COM i jest ok. Nie zawsze wraca do tego samego COM, dlatego to sprawdzanie.
Co do moich kłopotów z odczytem wejść to jak zwykle trywialny problem. Porty A oraz B mają na złączach 10 pin masy w innych miejscach (łatwiejsze połączenia na pcb). Jeśli pomylimy sznury łączące płytę z MCP23017 z płytą z 16 przyciskami to mamy problem z podawaniem masy, co wystąpiło w moim przypadku.
Teraz mogę testować szkic macieja dokładniej i już widzę szansę na jego poprawę, ale o tym później. Gratuluję Piter powrotu do zabawy w panele, ładnie wygląda ten na zdjęciu.

Odp: Kontrolery Arduino
« Odpowiedź #54 dnia: Lipca 28, 2016, 18:16:47 »
Zaraziliście mnie Panowie :)
Zacząłem już pisać własny program pod Leonardo/ATMEGA32U4 z wykorzystaniem MCP32017. A to tego powstaje już bazowa płyka z procesorem i całą resztą. Być może nieco na wyrost, ale moje podejście jest takie: jeśli buduję coś jednostkowego to projekt nie musi być maksymalnie wyżyłowany (w sensie zoptymalizowany i jak najtańszym kosztem). Warto dodać kilka różnych zabezpieczeń i dodatków, opcjonalnych konfiguracji itp. Zazwyczaj przydają się później.
Nie mam na stanie wersji PDIP MCP23017, jedynie QFN24 - za bardzo nie da się jej wetknąć w stykówkę ;) Ale to nic, nowy egzemplarz niedługo przyjedzie.
Tymczasem napisałem program, który udaje przyciskanie i wysyła to do WIN, systemowy podgląd joysticka pokazuje, że działa:



Przy okazji do podglądu co się dzieje w programie wykorzystałem bibliotekę BasicTerm i program PuTTy. Działa praktycznie jak zdalny monitor tekstowy.  Użyłem Serial1 i zewnętrzną przejściówkę Serial-USB, okazało się, że system nie odbiera danych z joysticka jeśli jestem podłączony terminalem do Serial, tego, który leci po USB Atmegi.
W sumie logiczne, port USB jest już zajęty czymś innym.

Odp: Kontrolery Arduino
« Odpowiedź #55 dnia: Lipca 28, 2016, 20:17:58 »
Robi się ciekawie. Tego brakowało , ja jutro przedstawię moją koncepcję na podstawie moich skromnych doświadczeń z Arduino oraz innych kontrolerów, które mam u siebie w kokpicie.

Odp: Kontrolery Arduino
« Odpowiedź #56 dnia: Lipca 29, 2016, 13:09:00 »
Tak jak wspomniałem próbuję określić pewne założenia projektu wspomagającego kontrolę kokpitu w symulatorach opartego na Arduino. Punktem wyjścia jest procesor  ATmega32U4. Czy to będzie własny projekt sterownika czy gotowy ProMicro lub Leonardo to nie ma znaczenia.  Pytanie podstawowe po co nowy projekt jeśli już są dostępne inne sterowniki z programami. Na podstawie swojego kokpitu mogę odpowiedzieć, że każdy zastosowany  u mnie sterownik spełnia doskonale swoją rolę, ale w ograniczonym zakresie.  Jest szansa, zaprojektowania kolejnego kontrolera na bazie Arduino, który w jakimś  stopniu zastąpi MJoy16.  Jest już doskonały program MMJoy2 z przyjazną platformą. Program ten realizuje to co realizował MJoy16, ale ma ambicje zrobić coś więcej np. sterowanie LED. Po moich testach mogę stwierdzić, że można go stosować z wyjątkiem enkoderów co jest wadą.
Po testach szkicu macieja mogę stwierdzić, że jest program, który realizuje funkcje joysticka. Analogi można dopisać. Można także dopisać bibliotekę o której wspomniał zajac i sprawdzić jak działają enkodery. Maciej zrobił swój projekt po to aby zastąpić uszkodzony kontroler Cougara. Można ten projekt rozwinąć i próbować zrobić coś podobnego do MMJoy2 dokładając rejestry MCP23017 oraz analogi. Jeśli będą problemy o których wspomniał zajac z enkoderami podłączonymi do rejestrów to można zrobić dodatkową klasyczną matrycę diodową dla enkoderów. Trzeba także zmienić w szkicu macieja funkcje realizujące HAT. Maciej potraktował HAT jak przyciski. Myślę, że znalazłem rozwiązanie, ale muszę to przemyśleć.
W platformie MMJoy2 są dołączone bardzo przydatne programy do testowania między innymi do testów przycisków oraz HAT pod nazwą VBK_Btn Tester. W odróżnieniu od Win można testować większą liczbę przycisków.
3.14 ter jakie jest Twoje zdanie na temat tego co napisałem, czy to ma sens.

Odp: Kontrolery Arduino
« Odpowiedź #57 dnia: Lipca 29, 2016, 14:09:31 »
Z całą pewnością nie mam takiego doświadczeznia z kokpitami, jak wielu z Was i dokładnie nie jestem pewien co będzie potrzebne. W sensie ilości wejści itp. Za punkt wyjściowy przyjmuję to, co może obsłużyć standardowy joystick HID w Windows.
Jeśli chodzi o używanie istniejących rozwiązań, ich adaptację - pewnie dobry pomysł, ale chyba nie dla mnie ;) Ten mały projekt joysticka nad którym pracuję powstanie na zasadzie sportu, dla odskoczni od tego co robię na codzień. Dlatego raczej postaram się stworzyć coś własnego od podstaw. Najprawdopodobniej będzie to pojedyncza płytka o dość sporych możliwosciach konfuguracyjnych, z kondycjonowaniem sygnałów analogowych, zasilania, dodatkową ochroną wejść/wyjść. Po prostu taka baza, na której można będzie zbudować joystkick albo innego rodzaju kontroler i która przetrwa różne męczarnie związane z eksperymentowaniem przy budowie kokpitów.
Projekt będzie w całości udostępniony na zasadach "open hardware".

Kwestia enkoderów:
raczej wątpię, że rozwiązania typu matryce czy odczytywanie stanów kilku enkoderów podłączonych do MCP23017 czy innego rejestru przesuwnego dadzą zadawalające rezulataty. Kręcenie enkoderem może generować dość szybkie przebiegi. W dotychczasowej wersji MCP odcztywany jest cyklicznie w pętli głównej. Procesor ma, albo będzie miał też inne zadania. Przez to na 100% dochodzić będzie do gubienia kroków, co jakiś czas procesor będzie zajęty czymś innym i po prostu nie zdąży wyłapać zmiany. Sytuację poprawić może użycie przerwań (INTA i INTB) w MCP do zasygnalizowania procesorowi, że nastąpiła jakaś zmiana na wejściach. To rozwiązanie ogólnie jest lepsze i takie zastosuję w mojej wersji. Program nie musi na okrągło odbierać danych z MCP tylko czeka na sygnał i ściąga sobie dane jeśli naciśnięty został któryś z przycisków.
Poza tym coraz bardziej skłaniam się do wersji dwuprocesorowej. ATMEGA32U4 będzie działać jako główny procesor, odpowiedzialny za wejścia analogowe i jeden bank 16 przycisków na MCP23017. Drugi procesor, jakiś mniejszy, np. ATMEGA8 będzie odpowiedzialny za 8 wejść enkoderów. Porządnych wejść z filtowaniem drgań, działających na przerwaniach przez co nie powinno dochodzić do gubienia kroków. Zapewne nie zawsze potrzebne będzie aż 8 enkoderów. Myślę, że jakiś mechanizm na zworkach mógłby przełączać wybrane wejścia między funkcją enkodera, a dwoma wejściami dla zwykłych przycisków. Ten drugi procesor generowałby zdarzenia typu "wciśnięty przycisk" sygnalizujące EnkoderN/obrót w lewo/obrót w prawo i wysyłał je do procesora głównego. Połączenie między obydwoma prcesorami będzie przez SPI, to zapewni możliwość zaprogramowania małego MCU z dużego (Arduino ISP).
Opcjonalnie (można ominąć zworkami) planuję dodanie zewnętrznego 12bitowego przetwonika A/C dla osi które wymagają większej przecyzji.
Mam już MCP23017 w DIP na stole i pewnie dziś przetestuję jak działają nowe funkcje.

Odp: Kontrolery Arduino
« Odpowiedź #58 dnia: Lipca 29, 2016, 17:10:20 »
Dzięki za wyjaśnienia oraz obietnicę udostępnienia projektu. Bardzo się przyda szczególnie w przypadku budowy własnego joysticka lub gdy zostanie uszkodzona płyta sterownika np. do Cougara (nie do zdobycia na rynku). Ja będę jeszcze eksperymentował, ale raczej w celach poznawczych. Co do enkoderów to masz całkowitą rację. Damos w swoim DMKeys8 dużo czasu poświęcił na opcję konfigurowania enkoderów (ustawianie filtrów, wybór typu enkodera 1:1, 1:2, 1:4) po to aby minimalizować przekłamania.
Na koniec pytanie związanie z programowaniem HAT w joysticku. Tak jak wspomniałem maciej nie znalazł sposobu zaprogramowania HAT, dlatego potraktował go jako zwykłe przyciski. W programie dla MMJoy2 jest możliwość zaprogramowania w konfiguracji 2 HAT i to działa. Szukałem jakiś przykładów i znalazłem pod tym linkiem http://forum.arduino.cc/index.php?topic=271306.0
Jest tam szkic dla joysticka F16 FLCS. Jest też opis dla HAT1
// Determine Joystick Hat Position
  int angle = -1;

  if (H1U) {
    if (H1R) {
      angle = 45;
    } else if (H1L) {
      angle = 315;
    } else {
      angle = 0;
    }
  } else if (H1D) {
    if (H1R) {
      angle = 135;
    } else if (H1L) {
      angle = 225;
    } else {
      angle = 180;
    }
  } else if (H1R) {
    angle = 90;
  } else if (H1L) {
    angle = 270;
  }
  Joystick.hat(angle);
Na początku jest tylko jedna deklaracja  biblioteki #include <SPI.h>
Maciej stosuje u siebie biblioteki #include <Joystick.h> oraz #include <Wire.h>
Czy można w macieja szkicu zrobić funkcje dla jego HAT1 oraz HAT2 coś podobnego do przedstawionego powyżej programu. Może jest inny sposób realizacji HAT.

Odp: Kontrolery Arduino
« Odpowiedź #59 dnia: Lipca 29, 2016, 17:39:25 »
#include <SPI.h>

dołącza jedynie bibliotekę do obsługi interfejsu SPI, który do czegoś tam jest potrzebny (nie wnikałem głębiej).
My używamy tej biblioteki:

https://github.com/MHeironimus/ArduinoJoystickLibrary

Jak zwykle w przypadku niejasności co biblioteka oferuje idziemy do pliku nagłówkowego .h, albo do dokumentacji, którą udostępnił autor:
Cytuj
Joystick - adds a single joystick that contains an X, Y, and Z axis (including rotation), 32 buttons, 2 hat switches, a throttle, and a rudder.
Jak widać biblioteka udostępnia dwa HAT, a dostęp do nich jest poprzez fukncję:
Cytuj
Joystick.setHatSwitch(byte hatSwitch, int value)

Sets the value of the specified hat switch. The hatSwitch is 0-based (i.e. hat switch #1 is 0 and hat switch #2 is 1). The value is from 0° to 360°, but in 45° increments. Any value less than 45° will be rounded down (i.e. 44° is rounded down to 0°, 89° is rounded down to 45°, etc.). Set the value to -1 to release the hat switch.

Tymczasem uruchomiłem obsługę przycisków narazie na jednym MCP23017:



Układ działa z wykorzystaniem przerwań generowanych przed MCP. Serial1, czyli ten drugi port szeregowy, dostępny na pinach D0 i D1 podłączony jest do modułu UART-Bluetooth HC-05, a ten podlądam programem PuTTy. Działa bez zająknięcia, nie traci połączenia po programowaniu procesora i nie blokuje działania joysticka w windows.



Guziki gotowe, to może teraz spróbuję dorobić dwa HATy, a potem wejścia analogowe.