Пока да. Буду пробовать на stm32.
Если молодёжь будет использовать ch32x035, буду только рад.
Вид для печати
CityAceE учит программировать RISC-V, bitluni запилил самодельный ассемблер для ch32x035. Жизнь проносится мимо.
Подключил USB-мышь к "ПУ" Вектора.
Подробности в первом сообщении темы.
Подключил USB-мышь через "ВУ" Вектора.
Подробности в первом сообщении темы.
(Затаив дыхание жду, что же будет, когда в третий раз закинет старик невод).
Кроме мыши, я ни чего не планировал подключать.
Хотя судя по описанию:
Можно даже флешку подцепить, и вроде как уже даже готовая библиотека имеется.Цитата:
USB Host Shield 2.0 построен на микросхеме MAX3421E, которая может выступать в роли хоста USB-соединения. Общение её с основным микроконтроллером происходит по интерфейсу SPI (на скорости до 26 Мбит/с). В режиме хоста микросхема поддерживает USB 2.0 Full и Low Speed (12 Мбит/с и 1.5 Мбит/с).
Библиотека поддерживает следующие внешние устройства:
устройства Android (в режиме «периферии», ADK)
HID-совместимые устройства, такие как клавиатура, мышь и т.д.
CDC-устройства – эмуляторы COM-портов
Геймпады от PS3, PS4, Nintendo Wii, Xbox One и Xbox 360
Цифровые зеркальные камеры, такие как Canon, Nikon, Powershot и т.д.
Устройства Mass Storage хранения данных, такими как USB-накопители, устройства чтения карт памяти, внешние жесткие диски
Некоторые адаптеры Bluetooth
Другие устройства последовательной связи USB, такие как GPS, FTDI и т. д
Как я уже писал, реальных Векторов мало, и я не уверен, что кто-то повторит в железе мой "контроллер usb-мыши для ПУ" и его "адаптер для ВУ".
Но я предложил работающий вариант для реализации "адаптера" в эмуляторах.
Если эмулятор предоставит данные о положении мыши через порт "D4", то даже программы на Бейсике смогут этим пользоваться :)
Какое раздолье для фантазии, при реализации пользовательского интерфейса в потенциальных (программах) игрушках ;)
Только над идентификатором подключения контроллера, нужно подумать.
Я подключаю к FPGA, но проблема та же. Текущий план использовать для этого Pi Pico (в моем случае rp2040-zero, но разницы нет). Пока только смотрел примеры от TinyUSB. Тоже обратил внимание на то, что бесплатно можно подключить mass storage на тот же usb порт. Пока не придумал зачем, но прикольно, когда можно.
Геймпад 8bitdo SN30Pro зацепился, но требует чего-то еще, пока не разобрался. Клавиатура одна завелась, вторая нет.
Еще есть адаптеры из USB в последовательный порт на CH9350DS. Они удобные, потому что вообще ничего делать не надо. Просто выдают HID пакеты на последовательный порт. Но там если что-то не поддержалось, то уж точно никаких шансов исправить положение нет. Поэтому я пока решил что на Пипико более перспективно.
rp2040-zero - выглядит интересно, правда как по мне, выводов GPIO маловато... "не развернёшься" ;)Цитата:
... Текущий план использовать для этого Pi Pico (в моем случае rp2040-zero, но разницы нет). ...
Сначала не обратил внимания, почему ни в одном из примеров "USB-мыши" не юзают колесо прокрутки, только 3 кнопки и X/Y, хотя по протоколу от мыши приходит пакет из 8 байт.
Начал кидать все 8 байт на экран... а колесо не активно!!!
Получается так-же как и у ps/2 мыши его включать нужно... а это не гуглится.
Если сильно "зачешется" разобраться, нужно будет запускать на компе прогу с логгером USB-порта, подключать мышь и смотреть обмен, может команда включения колеса найдётся...
Нагуглилось на самом деле. Я правда не нашел твоих исходников для stm32, поэтому не уверен, что это подойдет. Но если ты используешь ту же самую библиотеку TinyUSB, то подойдет.
Протокол при инициализации выбирается Boot. На Report он переключается так из колбаска tuh_hid_mount_cb():Репорты тогда будут приходить в таком формате. Поскольку hid_mouse_report_t TinyUSB как-то сразу узурпировало под BOOT, пришлось назвать его hid_wheelmouse_report_t:Код:tuh_hid_set_protocol(dev_addr, instance, HID_PROTOCOL_REPORT)
Соответственно надо подменить этот тип в колбасках, которые обрабатывают мышиные репорты и будет хорошо. У меня колесо ожило.Код:typedef struct TU_ATTR_PACKED
{
uint8_t report_id; // mouse=1
uint8_t buttons;
int8_t x;
int8_t y;
int8_t wheel;
} hid_wheelmouse_report_t;
- - - Добавлено - - -
P.S. попробовал другую мышь и она шлет колесо в BOOT протоколе. А первая вот не слала.
Внимательнее глянул дескрипторы мыши, в них нет протоколов "приёма" данных, только "отправка".
Значит у USB-мышей не предусмотрены настройки по стандартному протоколу (каналу).
Да, надо будет смотреть обработку прерываний.
Исходник в котором я ковырялся, и из которого переделывал в "контроллер мыши", написан для "pic18f26k20" https://github.com/felis/lightweight-usb-host.
В нём предусмотрен интерфейс пользователя по UART, несколько вложенных меню, для изучения МАХ3421 и состояния подключения.
В итоге (когда немного разобрался) достаточно было переопределить pin-ы с pic-а на мой stm32, подшаманить SPI и USART, и проект завёлся. Дальше только косметические изменения под протокол "ПУ".
Мне тоже нужно попробовать другие мыши.Цитата:
P.S. попробовал другую мышь и она шлет колесо в BOOT протоколе. А первая вот не слала.
МАХ не выставляет флаг запроса прерывания при вращении колеса. Запрос прерывания выставляется только при перемещении мыши и нажатии/отпускании кнопок. При этом МАХ сообщает, что из буфера нужно забрать ТРИ байта, хотя по дескриптору мыши, в протоколе 4 байта.