Od kilku lat kolekcjonuję ośmiobitowe komputery. Przypadek sprawił że w ostatnio w moje ręce trafiła w całkiem niezłym stanie Amiga CDTV. Po gruntownym sprzątaniu i kilku drobnych naprawach odpaliłem komputer i wtedy dopadła mnie nieodparta potrzeba posiadania myszki. W komplecie myszki ze sprzętem nie było, prawdopodobnie dlatego że Amiga miła fabrycznie niesprawny port do jej obsługi. Nie było łatwo namierzyć uszkodzenie ale naprawa była prosta.

Wracając do tematu:
Klika lat temu przerobiłem sobie "stoło-kulo-toczną" mysz od PC na myszkę do Atari XE zgodną z protokołem myszki AMIGI 500 (wyjątkiem jest prawy klawisz który był zwierany do Vcc a nie masy).
Skoro myszkę już miałem to pierwszym pomysłem była instalacja Interfejsu joysticków do CDTV.
Postanowiłem wybrać jednak nieco trudniejszą drogę.
Posiadam kilka uszkodzonych myszek laserowych znanej firmy. Po ich otwarciu okazało się że są oparte o układ który ma dość dobrą i łatwo dostępną w internecie dokumentacje. Należało tylko wyrzucić interfejs USB a w jego miejsce wstawić interfejs dla Amigi 500. Niestety wymagało to zaprojektowania nowego PCB odpowiedniego do obudowy. Następnie pozostała już tylko sama przyjemność przy programowaniu i testowaniu interfejsu. W ten sposób po ok 1 m-cu zabawy po nocach miałem gotową laserową myszkę do AMIGI 500.

Zamiast dokończyć budowę portu joysticków postanowiłem pójść krok dalej. W sklepie elektronicznym zakupiłem odpowiednią 4-pinową wtyczkę DIN i przeszedłem do realizacji kolejnego projektu pt.: Laserowa myszka do Amigi CDTV. Projektując PCB myszki starałem się zapewnić jak największą kompatybilność dzięki czemu nie musiałem projektować nowego układu. Po wlutowaniu dwóch zworek i 3 żyłowego kabelka przystąpiłem do programowania interfejsu. Niestety pierwsza próba wykonania interfejsu w oparciu o protokół pilota CDTV okazała się nie do końca udana.
Czas poświęcony spędzony w internecie nie przełożył się na uzyskanie satysfakcjonujących informacji dotyczących komunikacji pomiędzy myszą a CDTV, zmuszony byłem samodzielnie rozpracować wykorzystywany protokół (o dziwo zajęło mi to mniej czasu niż szukanie po internecie :)). Następne kilka wieczorów poświęconych na programowanie oraz testy i mogłem ogłosić sukces.
Zastanawiałem się czy jest sens „chwalić się” moim dziełem ale myślę że też właśnie takim celom służą to forum internetowe.
Więc oficjalnie, drodzy koledzy oto moje dzieło:
Laserowa mysz AMIGA CDTV.


Opis sprzętu.

• Prawy i lewy przycisk - standardowe działanie .
• Przycisk na górze obudowy - przełącznik rozdzielczości (400,800,1200,1600 CPI)
• Cztery niebieskie diody - wskaźnik aktualnej rozdzielczości.
• Przycisk środkowy / kółko - aktualnie nie wykorzystywany (w trybie CDTV może emulować wciśnięcie prawego i lewego przycisku naraz).
• Dwa Przyciski boczne - aktualnie nie wykorzystywane.

Co jeszcze chciałbym zrobić/poprawić:

• Obniżyć czułość muszki - projektując myszkę do Amigi 500 programowo obniżyłem czułość/rozdzielczość o połowę (200,400,600,800 CPI).
• Zastanowić się nad możliwością i sensem wykorzystania dodatkowych przycisków i rolki.
• Znaleźć/wykorzystać bardziej wzorniczo odpowiednią obudowę.

Ostatnia aktualizacja: 17.07.2015 11:03:56 przez krystian77

Zapomniałem jeszcze dodać zdjęcia z góry.

Jest to zdjęcie myszki do Amigi 500 ale od CDTV różni się tylko grubością przewodu :)

Chwalić się zawsze możesz, bo to zawsze jakieś osobiste osiągniecie.

A do CDTV robił ktoś taki adapter niedawno, który obsługiwał zdaje się standardowe myszy Amigowe, od CDTV i chyba joysticki, tylko nie pamiętam, kto to był.

Ostatnia aktualizacja: 17.07.2015 12:20:31 przez sanjyuubi

Ale gdzie schemat, płytka, dokumentacja, program, wsady, źródła? Szybciej, mocniej, więcej! ;)

Brawo ten Pan! :)
Czy będziesz gdzieś dokumentował część techniczną? :)

Jeśli chodzi o schemat to postaram się go udokumentować, ale z sama płytką będzie problem bo robiłem ją praktycznie pilnikiem pod obudowę, no i zawiera dwa błędy które będę musiał usunąć w pierwszej kolejności w finalnej wersji.

Świetny interfejs obsługujący myszy: Amigi, CDTV, 2 joye oraz mysz optyczną (od PC PS/2)
wykonał socha6. Opis i zdjęcia w wątku z 2014 roku "Interfejs joystików do CDTV".
morian

Właśnie zabierałem się do opisania moich bojów z myszą laserową firmowana przez znaną firmę komputerową, ale opis myszy którą tutaj znalazłem do złudzenia przypomina moją:

Opis sprzętu.
Prawy i lewy przycisk - standardowe działanie .
Przycisk na górze obudowy - przełącznik rozdzielczości (400,800,1200,1600 CPI)
Cztery niebieskie diody - wskaźnik aktualnej rozdzielczości.
Przycisk środkowy / kółko - aktualnie nie wykorzystywany (w trybie CDTV może emulować wciśnięcie prawego i lewego przycisku naraz).
Dwa Przyciski boczne - aktualnie nie wykorzystywane.

Poniżej na zdjęciu z koleżanką "w negliżu".




Po otwarciu okazało się że faktycznie mysz składa się ze specjalizowanego optycznego czujnika pozycji XY (AVAGO ADNS-7550), i mikrokontrolera który komunikuje się z czujnikiem przez SPI, oraz obsługuje port USB. Wystarczyło więc wymienić sam kontroler na taki który wytworzy sygnały kwadraturowe i mamy gotową mysz do Amigi.



Problemem pozostaje tylko odpowiedni kabel 8 (może 9) żyłowy. Poleciłby ktoś odpowiedni?

s.

Jeśli chodzi o przewód to kiedyś udało mi się kupić w sklepie elektronicznym dość miękki przewód 8-żyłowy z 9 przewodem (ekranowaniem) i do tego standardowe złącze rs-232 niestety dość gruby. Jest jeszcze inne i jak na razie tańsze rozwiązanie. Zakup tzw. przedłużacz kabla do Joystcków z chińskiego ali i obcięcie gniazda z jednej strony. Tyle że pozostaje nadal problem sztywności przewodu.

Problem kabla (chyba) rozwiązałem. Zaryzykowałem i zamówiłem game-pada do konsoli "coolbaby game-console" z pewnego portalu z drobnicą na dalekim wschodzie. Na zdjęciach kabel wygląda dość delikatnie, więc mam nadzieje że będzie wystarczająco giętki do myszy. Do tego pasuje kolorem.

Kilka dodatkowych uwag dotyczących układu ADNS-7550:

Według instrukcji sam układ nie przechowuje kalibracji lasera, która jest przeprowadzana podczas produkcji by być zgodnym z regulacjami "Class 1 Eye Safety Requirements of IEC 60825-1":

In order to stay below the Class 1 power requirements, LASER_CTRL0 (register 0x1a), LASER_CTRL1 (register 0x1f ), LSRPWR_CFG0 (register 0x1c) and LSRPWR_CFG1 (register 0x1d) must be programmed to appropriate values. The ADNS-7550 integrated molded lead-frame DIP sensor which comprised of the sensor and VCSEL; is designed to maintain the output beam power within Class 1 requirements over components manufacturing tolerances [..]

Wartości w tych komórkach muszą być tam umieszczone po każdorazowym wywołaniu komendy power-up (zapis 0x5a do 0x3a) układu przy starcie.

Doczytałem ten fragment dopiero po usunięciu oryginalnego kontrolera, więc w prototypie ustawiłem zakres mocy na najniższy, a regulację płynna zacząłem od 0x80 (ok 65%). Mniejsze wartości powodowały niepewne działanie sensora.

Mam jeszcze jedną taką myszkę kompletną, więc tam już podsłucham jakie wartości ma zapisane oryginalny kontroler.

Sam proces odczytu deltaX/deltaY jest w moim kontrolerze podpięty pod przerwanie wywołane opadającym zboczem sygnału MOTION (na wykresie poniżej sygnał IRQ) wygenerowanego przez sam ADNS, i potrzeba około 100us by zareagować na przerwanie i odczytać 4 bajty w trybie BURST (komórka 0x42, zegar SPI 1MHz).



Podczas eksperymentów nie zauważyłem żeby którakolwiek delta była większa niż jeden krok, ale może to z powodu domyślnych ustawień CPI (800CPI). Przykładowy wykres z transakcjami SPI i odpowiadającymi im zboczami na liniach kwadraturowych XA/XB oraz YA/YB załączyłem w poprzedniej wiadomości. Jak szybko można ruszać myszką? 1m/s? Profesjonalni gracze tak grają? LISA odczytuje stan portu myszy co 4.5us (okres MLD), więc to jest ta dolna granica której nie można przekroczyć.

W planach mam zaimplementowanie obsługi rolki, ale nie chcę podłączać dodatkowych sygnałów do portu JOY, jak w projekcie Henryka Richtera:

[..] While a two port design will not win an award for first glance elegance compared to 1 port solutions like Cocolino (serial transfer of extra information) or Micromys (analog extra information) [..]

Gdybym tylko miał możliwość "podsłuchania" protokołu Cocolino... a ponoć w 3.2 obsługa rolki jest już zaimplementowana w OS, więc protokół powinien być gdzieś udokumentowany.

Czy ktoś wie może jak wygląda ten protokół?

Na EAB znalazłem taki stary wpis użytkownika robinsonb5:

I think the Cocolino is an evolution of Eyetech's EZMouse, which was originally my design. What I did was have the microcontroller use PotX as a select signal, similar to how a Megadrive joypad works. a VBlank interrupt runs on the Amiga which briefly pulls PotX low. This signals the adapter to put alternative data on the mouse button lines and two of the direction lines (whichever two are mapped to the least significant bits of the mouse counters - I forget now), then an input handler generates NewMouse-style mousewheel events from these signals.

If memory serves, the Punchinello Mk II did some kind of simulation of analogue signals. The problem with this method is that the analogue counters on the Amiga count at different rates depending on the current screenmode.

Pozdrawiam,
Szymon

Kolejna garść informacji o nowej myszy laserowej do Amigi (każdej niestety poza CDTV).

Oryginalny kontroler nie jest podłączony do linii MOTION, a ruch wykrywany jest przez cykliczne sprawdzanie (co ok 5ms) rejestru 0x02 (Motion). Przy okazji za każdym razem jest też odczytywany rejestr 0x00 (Product_ID), który za każdym razem potwierdza że podłączony układ nie został od podmieniony ;). W porównaniu z prędkością odczytu w moim kontrolerze (maksymalny czas od opadającego zbocza MOTION, do reakcji na liniach kwadraturowych jak już pokazywałem w poprzedniej wiadomości) to ok 100us.

Pytanie do Ciebie Krystian: czy cyklicznie sprawdzasz rejestry delta, tak jak w oryginalnej myszy, czy obsługujesz przerwanie wywoływane linią MOTION? Na jakich ustawieniach CPI najwygodniej Ci się pracuje na Amidze? Jaką masz rozdzielczość ekranu i jak dużo miejsca używasz do operowania na blacie?. Pisałeś że zaimplementowałeś obsługę diod i klawisza na myszy: Czy przechowujesz ustawioną wartość w pamięci nieulotnej (tak jak oryginalny kontroler)? Wspomniałeś też o problemach z odczytem pozycji przy ruchu na ukos - czy sprawdzałeś flagę OVF w rejestrze Motion 0x02?

W dwu myszach które jeszcze mam sprawne, podsłuchałem jakie wartości wpisywane są podczas uruchamiania (i przy okazji za każdym razem gdy wciśnięty jest klawisz zmiany czułości) do komórek rejestrów konfiguracji lasera. Były to wartości zbliżone, ale różne (czyli jednak jakaś kalibracja jest przeprowadzana dla indywidualnych egzemplarzy myszy). Dla obu rejestr 0x1A (zakres pracy) wskazywał wartość 0xC0 - co daje najwyższy zakres prądu lasera (4 do 10mA), natomiast wartość prądu w jednej jest ustawiony na poziomie ok. 80% (0xB2), a w drugiej 84% (0xC2), by nie przekroczyć przepisowego 506uW.
Wartość 0x70 i zakres 0.9-3mA które dobrałem eksperymentalnie dla myszy w której nie miałem okazji odczytać kalibracji lasera, okazały się bardzo konserwatywne, ale pozostawię bo nie mam możliwości kalibracji.

Szymon

p.s. dodawanie obrazków przez imgur zablokowane?

Przepraszam ale chwilowo mam utrudniony dostęp do źródeł dlatego nie pamiętam jak często sprawdzam rejestry - postaram się do nich dotrzeć.
Na razie to co pamiętam:
1. Odczytuje rejestry cyklicznie - okresu nie pamiętam:(
2. Jeśli zbyt często czytałem rejestry delta to myszka przestawała mi chodzić na ukos.
3. Próbowałem też korzystać z przerwania wywoływanego linią MOUTION - i tu też ruch miałem kanciasty bez skosów .

Wydaje mi się że powodem braków skosów jest sposób działania chipa. O ile dobrze pamiętam z instrukcji odczyt rejestrów powoduje wyzerowanie ich zawartości.
Wyobrażam sobie że to działa niestety tak jak w algorytmie poniżej:
1. Użytkownik wykonuje ruch myszką po skosie powiedzmy 30stopni.
2. Przy przesunięciu o jeden "DPI" w prawo następuję wpisanie do rejestru przesunięcia w poziomie wartość '1'. W tym czasie w rejestrze ruchu pionowego pozostaje '0' bo przesunięcie nastąpiło tylko o < 0,5 "DPI".
3. Linia MOUTION zgłasza przerwanie.
4. CPU odczytuje rejestry przez co następuje zerowanie wartości przesunięcia -
5. chip liczy przesunięcie znów od wartości (0 , 0) a nie (0 , 0.5)
6. Goto pkt. 2

Czyli pomimo ruch z delikatnym ukosem myszka przesuwała mi się wyłącznie w poziomie.
Podobny efekt kanciastych ruchów uzyskiwałem przy zbyt szybkim czytaniu rejestrów z tych samych powodów jak wyżej.

Ok. Udało mi się odpalić RaspberryPi poniżej zrzut moich źródeł w części dotyczącej prądu lasera:

//Ustawienie prądu lasera
        write2A7550(0x1a,0xc0);         //11= Laser current range from approximately 4mA to 10mA
        _delay_us(30);/* min 30 us delay */
        write2A7550(0x1f,0x00);
        _delay_us(30);/* min 30 us delay */
        write2A7550(0x1c,0x92);         //70%
        _delay_us(30);/* min 30 us delay */
        write2A7550(0x1d,0x6d);
        _delay_us(30);/* min 30 us delay */

Ostatnia aktualizacja: 02.09.2021 22:26:23 przez krystian77

Dzięki za uwagi do tej pory.

Kontynuowałem próby z czujnikiem ruchu przy różnej szybkości przesuwania myszy. Czujnik w/g DS jest w stanie obsłużyć do 30 cali na sekundę, co dla najwyższej rozdzielczości dałoby 60000 impulsów na sekundę. Liczniki delta X/Y są 12 bitowe, więc żeby uniknąć przepełnienia (flaga OVF w rejestrze Motion 0x02) odczyt stanu musiałby się odbywać nie rzadziej niż co 33ms: 100us obsługi przerwania w moim układzie w zupełności wystarcza. Problemem jest powolność reakcji samego ADNS-7550:

Linia Motion nie generuje przerwania częściej niż co ok 2ms i za każdym odczytem zeruje rejestry. Do takiego najkrótszego okresu dopasowałem generacje sygnałów na liniach kwadraturowych, ograniczając od dołu najkrótszy stan na ok 5us (okres próbkowania układu LISA), a rozciągając zmiany by najlepiej "wypełnić" okresy między aktualizacjami danych z czujnika (nowe dane o delta X/Y).


Dla zainteresowanych cały kod powstał na MSP430G2553 w Energii

Pozdrawiam,
Szymon

p.s. przydałby się bbcode [spoiler][/spoiler]

/*
  AVAGO ADNS-7550

 The circuit:

 // Default SPI pinout for MSP430G2553
// MISO P1.7
// MOSI P1.6
// CLK  P1.5
// set pin 8 as the slave select for the digital pot:
// CS   P2.0

*/

//#define DEBUG 1

#define  REG_PRODUCT_ID   0x00
#define  REG_INV_PRODUCT_ID   0x3E
#define  REG_REVISION_ID  0x01
#define  REG_INV_REVISION_ID  0x3F

#define  REG_MOTION       0x02
#define  REG_DELTA_X      0x03
#define  REG_DELTA_Y      0x04
#define  REG_DELTA_XY_H   0x05

#define  REG_SQUAL        0x06
#define  REG_MAX_PIXEL    0x09
#define  REG_PIXEL_SUM    0x0a
#define  REG_MIN_PIXEL    0x0b

#define CONFIG2_400CPI    0x08
#define CONFIG2_800CPI    0x28
#define CONFIG2_1200CPI    0x48
#define CONFIG2_1600CPI    0x68
#define  REG_CONFIGURATION2  0x12

#define  LASER_3MA        0x00
#define  LASER_5MA        0x30
#define  LASER_10MA       0xC0

#define  LASER_RANGE      LASER_3MA
/* 0x00 -> 33.6%, 0xff -> 100%*/
#define  LASER_POWER      0x70

#define  REG_LASER_CTRL0  0x1a
#define  REG_LASER_CTRL1  0x1f
#define  REG_LSRPWR_CFG0  0x1c
#define  REG_LSRPWR_CFG1  0x1d

#define  REG_OBSERVATION  0x2e
#define  REG_MBURST       0x42
#define  REG_POWER_UP_RESET 0x3a


// include the SPI library:
#include <SPI.h>

const int slaveSelectPin = SS;

// MOTION pin set to trigger IRQ
#define MOTION_PIN PUSH2

// quadrature outputs
#define QXA P2_1
#define QXB P2_2
#define QYA P2_3
#define QYB P2_4

unsigned int motion = 0;
unsigned int quad_x, quad_y;
signed delta_x, delta_y;

void setup() {
  // set the slaveSelectPin as an output:
  pinMode (slaveSelectPin, OUTPUT);

  // configure RED LED for output
  pinMode(RED_LED, OUTPUT);

  // initialize SPI:
  SPI.begin(); 
  SPI.setClockDivider(16); // 1MHz SPI

//  Serial.begin(9600);
//  Serial.println("AVAGO SPI demo.");

  delayMicroseconds(250);

  digitalWrite(slaveSelectPin,LOW);
  delayMicroseconds(25);
  digitalWrite(slaveSelectPin,HIGH);
  delayMicroseconds(25);
  digitalWrite(slaveSelectPin,LOW);
  delayMicroseconds(25);
  digitalWrite(slaveSelectPin,HIGH);
  delayMicroseconds(25);

#if DEBUG
  get_reg(REG_PRODUCT_ID); // 0x00 -> 0x32
  get_reg(REG_INV_PRODUCT_ID); // 0x3e -> 0xfc
  get_reg(REG_REVISION_ID); // 0x01 -> 0x03
  get_reg(REG_INV_REVISION_ID); // 0x3f -> 0xcd
#endif // DEBUG

//  delayMicroseconds(250);

  set_reg(REG_POWER_UP_RESET, 0x5a); // (0x80 | 0x3a = 0xba)

/* LASER_3MA LASER_5MA LASER_10MA */
  set_reg(REG_LASER_CTRL0, LASER_RANGE); // 0x1a
  set_reg(REG_LASER_CTRL1, ~LASER_RANGE); // 0x1f
  set_reg(REG_LSRPWR_CFG0, LASER_POWER); // 0x1c
  set_reg(REG_LSRPWR_CFG1, ~LASER_POWER); // 0x1d

/* CONFIG2_400CPI, CONFIG2_800CPI, CONFIG2_1200CPI, CONFIG2_1600CPI */
  set_reg(REG_CONFIGURATION2, CONFIG2_1200CPI); //   0x12

  // wait for at least one frame ?
  delayMicroseconds(250);

  // clear observation register
  set_reg(REG_OBSERVATION, 0x00);

  // wait for at least one frame
  delayMicroseconds(250);
  // and check observation register, all bits 0-3 must be set
  while((get_reg(REG_OBSERVATION) & 0x0F) != 0x0F)
    delayMicroseconds(500);

  get_reg(REG_MOTION);                     // read from registers one time regardless of the motion pin state 0x02
  get_reg(REG_DELTA_X);                    // 0x03
  get_reg(REG_DELTA_Y);                    // 0x04
  get_reg(REG_DELTA_XY_H);                 // 0x05
 
  set_reg(0x3c, 0x27);    // 0xbc
  delayMicroseconds(10);
  set_reg(0x22, 0x0a);    // 0xa2
  delayMicroseconds(10);
  set_reg(0x21, 0x01);    // 0xa1
  delayMicroseconds(10);
  set_reg(0x3c, 0x32);    // 0xbc
  delayMicroseconds(10);
  set_reg(0x23, 0x20);    // 0xa3
  delayMicroseconds(10);
  set_reg(0x3c, 0x05);    // 0xbc
  delayMicroseconds(10);
  set_reg(0x37, 0xb9);    // 0xb7

  delayMicroseconds(250);

  // set motion pin as interrupt input FALLING
  pinMode(MOTION_PIN, INPUT_PULLUP);
  attachInterrupt(MOTION_PIN, set_motion, FALLING);

  // quadrature outputs
  pinMode(QXA, OUTPUT);
  pinMode(QXB, OUTPUT);
  pinMode(QYA, OUTPUT);
  pinMode(QYB, OUTPUT);

  digitalWrite(QXA, LOW);
  digitalWrite(QXB, LOW);
  digitalWrite(QYA, LOW);
  digitalWrite(QYB, LOW);

  quad_x = 0;
  quad_y = 0;

  delta_x = 0;
  delta_y = 0;
}

unsigned int reg_val, change_period;
unsigned int delta_x_raw, delta_y_raw, delta_xy_raw;
const unsigned int quad_state[] = { 0, 1, 3, 2 };

void loop() {
  if(motion) {
    digitalWrite(RED_LED, HIGH);
#if 0
//    get_reg(REG_OBSERVATION); // 0x2e
//    reg_val = get_reg(REG_MOTION); // 0x02
    delta_x_raw = get_reg(REG_DELTA_X); // 0x03
    delta_y_raw = get_reg(REG_DELTA_Y); // 0x04
    delta_xy_raw = get_reg(REG_DELTA_XY_H); // 0x05
#else
    get_burst();
#if DEBUG
    get_reg(REG_SQUAL); //    0x06
    get_reg(REG_MAX_PIXEL); //    0x09
    get_reg(REG_PIXEL_SUM); //    0x0a
    get_reg(REG_MIN_PIXEL); //    0x0b
#endif // DEBUG

#endif

    delta_x_raw |= (delta_xy_raw >> 4) << 8;
    delta_y_raw |= (0x0F & delta_xy_raw) << 8;

    if(delta_x_raw < 0x800) {
      delta_x += delta_x_raw;
    } else {
      delta_x += ((signed int)delta_x_raw - 0x1000);
    }

    if(delta_y_raw < 0x800) {
      delta_y += delta_y_raw;
    } else {
      delta_y += ((signed int)delta_y_raw - 0x1000);
    }

    digitalWrite(RED_LED, LOW);
    --motion;

    change_period = min(750, max(5, 1650 / max(abs(delta_x),abs(delta_y))));
  } else {
    if((delta_x != 0) || (delta_y != 0))
      delayMicroseconds(change_period);
  }

  if(delta_x != 0) {
    if(delta_x > 0) {
      ++quad_x;
      --delta_x;
    } else {
      --quad_x;
      ++delta_x;
    }
    quad_x &= 0x03;
    digitalWrite(QXA, (quad_state[quad_x] & 0x01)?HIGH:LOW);
    digitalWrite(QXB, (quad_state[quad_x] & 0x02)?HIGH:LOW);
  }

  if(delta_y != 0) {
    if(delta_y > 0) {
      ++quad_y;
      --delta_y;
    } else {
      --quad_y;
      ++delta_y;
    }
    quad_y &= 0x03;
    digitalWrite(QYA, (quad_state[quad_y] & 0x01)?HIGH:LOW);
    digitalWrite(QYB, (quad_state[quad_y] & 0x02)?HIGH:LOW);
  }

}

void set_reg(int address, int value) {
  // take the SS pin low to select the chip:
  digitalWrite(slaveSelectPin,LOW);
  //  send in the address and value via SPI:
  SPI.transfer(0x80 | address);
  SPI.transfer(value);
  // take the SS pin high to de-select the chip:
  digitalWrite(slaveSelectPin,HIGH); 
}

int get_reg(int address) {
  unsigned int value = 0xFF;
  // take the SS pin low to select the chip:
  digitalWrite(slaveSelectPin,LOW);
  //  send in the address and value via SPI:
  SPI.transfer(address);
  value = SPI.transfer(0xFF);
  // take the SS pin high to de-select the chip:
  digitalWrite(slaveSelectPin,HIGH); 
  return value;
}

void get_burst() {
  unsigned int value = 0xFF;
  // take the SS pin low to select the chip:
  digitalWrite(slaveSelectPin,LOW);
  //  send in the address and value via SPI:
  SPI.transfer(REG_MBURST);
  delayMicroseconds(4);
  value = SPI.transfer(0xFF); // MOTION 0x02
  delta_x_raw = SPI.transfer(0xFF); // REG_DELTA_X 0x03
  delta_y_raw = SPI.transfer(0xFF); // REG_DELTA_Y 0x04
  delta_xy_raw = SPI.transfer(0xFF); // REG_DELTA_XY_H 0x05
  // take the SS pin high to de-select the chip:
  digitalWrite(slaveSelectPin,HIGH);
}

void set_motion() {
  ++motion;
}

Widzieliście ten projekt? Może tam coś podejrzycie lub przeprojektujesz/ecie. Zbudowałem 2 szt i działają dobrze na tyle na ile korzystałem.
link

Pewne postępy poczyniłem przy obsłudze rolki skrolla. Niestety nie znając protokołu robię to trochę "na czuja" i próbuje zastosować coś co zauważyłem obsługując trój-klawiszową mysz w przeglądarce IBrowse (chyba MUI): trzymając wciśnięty klawisz MMB i poruszając mysz w górę i dół przewija się zawartość okna. Zastosowałem ten sam mechanizm w swoim kontrolerze: po wykryciu ruchu rolki (QRA i QRB), linia MMB jest ustawiana na stan niski (uwaga na GPIO - to nie są linie OC, więc trzeba zastosować diodę) i wystawiany jest zmieniony stan na wyjściu kwadraturowym Y (QYA i QYB - pionowy). Po pewnym czasie linia MMB jest zwalniana.

Niestety zachowanie pod IBrowse jest nieco odmienne od moich oczekiwań: kursor zmienia się w pionową strzałkę z ostrzami obie strony i uruchamia się powolny scroll już bez mojej ingerencji. Do tego czas jaki MMB musi być w stanie niskim musi być bardzo długi - kilka ms. Wykrywanie MMB jest też mało skuteczne w AmigaTestKit - łapie dopiero po kilku próbach.

Ma ktoś sugestie w jaki sposób przetestować (3.2 już jedzie), w jakim programie? Uruchomienie FreeWheel powoduje całkowite wyłączenie powyższej reakcji IBrowse na skrolowanie (włącznie z myszą trój-klawiszową).

p.s. ładna obudowa do a4k

s.

Myszka uruchomiona, z obsługą rolki, środkowego i dwu dodatkowych klawiszy (4th, 5th). Kod drivera dzięki uprzejmości nogginthenog i robinsonb5 z eab:

kod kontrolera myszy
kod drivera

s.

Może ktoś uruchomi jakąś mini linię produkcyjną takich myszek?

Cały projekt oparł się na zmodyfikowaniu istniejącego układu. Całość zamknęło się na kilku mostkach, przecięciu paru ścieżek:

Tak, w prawym dolnym rogu jest rezystor SMD wlutowany między dwie nogi kontrolera ;) jest to część drabinki ważonej do obsługi dwu dodatkowych klawiszy.
Zmieniłem jednak zasilanie z dostępnego 3.0V z układu ADNS na regulator 3.3V - by móc uruchomić MSP na 16MHz:

Największym problemem jednak pozostał kabel 9-żyłowy. I tego mi jeszcze brakuje do uruchomienia takiej "mini linii produkcyjnej"... no może poza samymi myszkami moczul.

Co do kabelka ... myślę że tu jest rozwiązanie i to dość tanie i nowe ;)
https://www.aliexpress.com/item/4000598804090.html
lub tutaj
https://www.aliexpress.com/item/1005002929099114.html

Ostatnia aktualizacja: 16.10.2021 21:32:43 przez Rafael/ARMO

Na poniższym zdjęciu widać problem:

od lewej:
oryginalny kabelek USB - średnica poniżej 3mm
kabelek z importu zza wielkiego muru, średnica 4.5mm
Z prawej widać wnętrze obudowy z dość ciasnym zakrętem który ów kabelek musi pokonać i nie sprawić problemu zamknąć górną część obudowy.

Rozumiem, ale to może np: docinanie "dolnej" części myszki, żeby zmieścić grubszy kabelek. Albo może ktoś by zaprojektował ten spód myszki na nowo do wydruku 3D? Nawet koszt wydruku takiego spodu był by w miarę "niski".
Ja osobiście bym docinał obudowę ...

Tutaj masz przewód sieciowy wg opisu 3.5mm. Nie wiem czy się nada, bo nie miałem takiego w ręku i czy ma ekranowanie (9 przewodów)
https://allegro.pl/oferta/kabel-lan-patchcord-cat-6-u-utp-slim-czarny-15m-9854746489

Ostatnia aktualizacja: 16.10.2021 23:54:58 przez snifferman

Jeśli rolka niepotrzebna to można puścić kabelek prosto bez tego zagięcia. A jego większa średnica utrzyma go ciasno na miejscu.

To jakich konkretnie myszek trzeba szukać?

m0czul

Ech. Wszędzie znajduję same srebrne albo niedostępne... Poczekam na czarne.

A czy rozważa ktoś przerobienie myszki bezprzewodowej (IR) do współpracy z kontrolerem IR Amigi CDTV?
To byłby sukces gdyby zbudować zamiennik CD-1252.

Ostatnia aktualizacja: 25.10.2021 13:44:24 przez Rafał A-3000

Najprawdopodobniej Krystian byłby w stanie podołać takiemu zadaniu, skoro protokół IR jest podobny do transmisji po kablu w CDTV. Samo opanowanie zasilania nie powinno być problemem - akumulatorek albo pojemnik na baterie paluszki.

Po krótkich poszukiwaniach znalazłem chyba coś co mogło by zostać zastosowane do transmisji przez nadajnik IR w takiej myszy: CDTV_PS2Mouse_Joy

s.

Rozważałem temat przerobienia myszki na IR. Niestety z uwagi na nadmiar innych zajęć projekt musiałem odłożyć na "później". A dodatkowo przyszedł mi do głowy jeszcze jeden pomysł związany z samym sterownikiem ir/klawiatury/myszy/joy. Dla znających temat chce popracować z tym 6500/1 :) Niestety wymaga to zastosowania dodatkowego osprzętu do inżynierii wstecznej i sporo wolnego czasu.