Просмотр полной версии : Контроллер USB клавиатуры
Собственно, сегодня на макетке проверил - читает все клавиши. Работает с проводными и беспроводными клавиатурами. Есть так же и поддержка мышей.
Проверялось на плате STM32F4DISCOVERY, но подойдёт практически любой контроллер с USB-HOST.
Выход возможен различный, зависит от фантазии - матрица для прямого подключения, PS/2, SPI и т.д.
На данный момент планирую сделать в одном корпусе сразу два варианта - USB->PS/2+MATRIX. Таблица истинности для матрицы (в виде положение_в_матрице=скан_ко д) будет вбита в прошивку контроллера, а различные таблицы можно будет переключать DIP-переключателем (или джамперами на его месте).
Из плюсов - поддержка одновременного нажатия множества кнопок.
За основу взял готовый пример, сейчас буду корректировать его для одновременной работы и с клавиатурой и с мышью.
Это очень здорово, мы в другой теме как раз обсуждаем возможность создания корпуса для новоделов и такой контроллер существенно упростил бы и расширил возможные варианты.
По программе - уже реализовал одновременную работы клавиатуры с мышью. Разумеется, не проводных, поскольку сразу 2 встроенных USB-HOST накладно держать - проверял на Wireless Keyboard+Mouse, через 1 "свисток".
Прошивка занимает смешные 14Кб флеша и 4Кб памяти.
Сегодня ещё реализую шаблон работы с матричной клавиатурой размером до 12х12 - таблица с описанием одного варианта "раскладки" займёт 288 байт :)
Хех так может дойти до того что туда весь ZX-Spectrum заедет на пмж :)
Хех так может дойти до того что туда весь ZX-Spectrum заедет на пмж :)
Нет, это проектируется именно как адаптер для клавиатуры с мышью. Максимум - ещё как IO для всяких там UART, SPI, I2C (это будет реализовываться значительно позже, по какому-либо стандарту).
У стм-ов ресурсов то дофига, можно придумать, чем ещё занять - к примеру, сделать лоадер тапов с сд Карты через tape in или эмуляцию трдоса, кстати эмулятор трдоса где-то тут на форуме именно под стм вроде был. Или даже адаптер ргб2вга :) Правда, все это крайне трудоемко, но подозреваю, что теоретически возможно.
У стм-ов ресурсов то дофига, можно придумать, чем ещё занять - к примеру, сделать лоадер тапов с сд Карты через tape in или эмуляцию трдоса, кстати эмулятор трдоса где-то тут на форуме именно под стм вроде был. Или даже адаптер ргб2вга :) Правда, все это крайне трудоемко, но подозреваю, что теоретически возможно.
RGB-VGA сразу отпадает - на другое ресурсов не хватит уже. Да и даже это под вопросом.
А по поводу загрузки - это всё возможно, ресурсы позволят. Ведь вполне можно впихнуть какой-либо STM32F429 и рулить с него всем - имеется готовый функционал для работы с SD-картами (уже работал раньше с ними).
PS: Сейчас уже пишу обновление прошивки с USB-флешки ;) То есть закинул бинарник, подключил, запустил. По завершении прошивки зажигается светодиод и ждёт перезагрузки. Из требований - FAT32 на флешке. И теоретически возможно-таки сделать сразу 2 порта - 1 для клавиатуры и 1 для флешки, вместо SD-карты.
Выложил исходники проекта (https://github.com/andreili/USB-Keyboard) на GitHub'е. Самая "свежая" версия будет доступна именно там.
На данный момент для отладки "прикрутил" LCD-дисплей через проприетарную библиотеку uC/GUI. После завершения тестирования её удалю.
Сегодня-завтра составлю первую матрицу преобразований и протестирую её - с экраном это делать проще всего, как раз нарисовать сетку контактов там очень просто.
Хардвари там не нашёл - пока рано?
Хардвари там не нашёл - пока рано?
Пока что всё тестируется на плате STM32F4DISCOVERY. Экран необязателен - там выводятся только сканкоды и прочее. В итоге - STM32F407VGT6 с минимальным обвязом + обвязка USB-OTG-HS (страница 30 по схеме платы (http://www.st.com/content/ccc/resource/technical/document/user_manual/70/fe/4a/3f/e7/e1/4f/7d/DM00039084.pdf/files/DM00039084.pdf/jcr:content/translations/en.DM00039084.pdf)).
Из дополнительных элементов для подключения матрицей будут стоять ещё преобразователи уровней - в их качестве буду использовать SN74ALVC164245. Стоят недорого, сразу 2 группы по 8 бит, у каждой группы своё направление.
Но - пока что надо с софтом добить, хардварь в таких делах от софта очень сильно зависит (особенно трассировка).
OrionExt
18.03.2018, 16:30
А на мелком STM (ног 40) - это возможно? Контроллер USB клавиатуры интересует и мыши.
А на мелком STM (ног 40) - это возможно? Контроллер USB клавиатуры интересует и мыши.
С USB-Host (USB-OTG, если точнее) только от 64 ног идут. В более мелких корпусах - только USB-Device.
А так, можно посчитать "свободные" ноги:
1) USB - 4 вывода на полный OTGж
2) SDIO (если подключать SD/microSD-карты) - 7 ног;
3) программатор - 2 ноги;
4) выбор режима - 10 ног (с запасом, 4 бита на выбор выхода, 7 на выбор типа матрицы преобразований);
5) матрица - 24 ноги;
6) PS/2 - 2 ноги.
Уже получается 49 ног - еле укладывается в свободные GPIO 64-выводного корпуса (50-51, зависит от чипа). А если делать ещё и дополнительные функции, то уже нужен 100-ногий корпус.
- - - Добавлено - - -
Если делать в режиме эмуляции ВВ55, то выводов значительно меньше будет использовано, но это уже узкозаточенный девайс будет. Я же стремлюсь к более унифицированному варианту - по цене на чип разница будет мизерной. А паять могу и сам, отправляя готовые наборы.
Вопрос только в "хотелках" - теоретически тут можно сделать и эмулятор магнитофона и ещё что-либо, сразу в 1 корпусе.
OrionExt
18.03.2018, 17:06
Матрицу можно и под уменьшить, ДШ с ОК рулит:)
Матрицу можно и под уменьшить, ДШ с ОК рулит:)
Ну, если делать что-либо кроме клавиатуры с мышью, то только 100 ногий корпус. В противном случае 64 ноги "хватит всем", поскольку в расчётах выше я учитывал и SDIO, который в минимальной конфигурации не нужен.
OrionExt
18.03.2018, 17:12
Да понятно прогресс, епть;)
Готово преобразование сканкодов в матрицу, готовую для дальнейшего использования. Код на данный момент не самый оптимальный, но почти всё время и так отжирает отрисовка экрана, так что замерить что-либо очень тяжело.
Фото экрана (https://image.prntscr.com/image/wJAzdlQDS_Ogy2KYZ3bAXw.jpg) с отображением состояния матрицы - видно прочитанные сканкоды и закрашенные прямоугольники для них. Таблица для получения матрицы пока что "с потолка", завтра думаю вбить для тестов таблицы RK86 и MC7007.
Репа обновлена до актуального состояния.
Error404
18.03.2018, 22:09
RGB-VGA сразу отпадает - на другое ресурсов не хватит уже. Да и даже это под вопросом.
Что же ты там такое замутил, что на перекодирование массива в пару сотен байт не хвататает ресурсов 32-битного микропроцессора в почти две сотни мегагерц с количеством памяти больше чем не то что в спеке, а даже и в орионе? :) В этом 500-рублевом чипе (кстати, дороже чем PiZero за 5$ на котором целый EmulationStation пашет) можно сделать целую собственную VGA-видеокарту, цветную сделано же аналогичное в 5-рублевом STM32F030F4 (https://hackaday.com/2016/05/13/chibiterm-is-a-tiny-low-cost-vga-terminal/) - все же в ней 3 SPI-регистра (в этом и фишка - выводить SPI-регистром по 8 точек экономя ресурс ЦПУ), а не 1 как по ссылке (поэтому по ссылке монохром). Так там по ссылке еще и полный терминал VT100/52 (на графику не хватает ОЗУ, там все же 4кб, а не 192 кб как у STM32F407).
Что же ты там такое замутил, что на перекодирование массива в пару сотен байт не хвататает ресурсов 32-битного микропроцессора в почти две сотни мегагерц с количеством памяти больше чем не то что в спеке, а даже и в орионе? :) В этом 500-рублевом чипе (кстати, дороже чем PiZero за 5$ на котором целый EmulationStation пашет) можно сделать целую собственную VGA-видеокарту, цветную сделано же аналогичное в 5-рублевом STM32F030F4 (https://hackaday.com/2016/05/13/chibiterm-is-a-tiny-low-cost-vga-terminal/) - все же в ней 3 SPI-регистра (в этом и фишка - выводить SPI-регистром по 8 точек экономя ресурс ЦПУ), а не 1 как по ссылке (поэтому по ссылке монохром). Так там по ссылке еще и полный терминал VT100/52 (на графику не хватает ОЗУ, там все же 4кб, а не 192 кб как у STM32F407).
Пока что отрисовка идёт в попиксельном режиме (https://github.com/andreili/USB-Keyboard/blob/master/libs/uCGUI_LIB/GLCD/GLCD.c#L962) - завтра буду гуглить протокол контроллера дисплея, может есть копирование всей памяти сразу.
- - - Добавлено - - -
Тут проблема в том, что надо следить за USB-устройством, а так же вовремя реагировать на внешние раздражители - в нашем случае это вовремя успеть выдать данные по запрошенному адресу в матрице. А для этого надо:
1) опросить клавиатуру;
2) преобразовать HID-сканикоды в матрицу;
3) выдать запрошенную строку из матрицы.
Разумеется, все эти события происходят в разных процессах, которые периодически переключаются планировщиком.
- - - Добавлено - - -
По производительности - хочу сперва сделать полноценный вариант, а потом протестировать на скорость. Там и будут видны узкие места.
Error404
18.03.2018, 23:33
Вот это вот:
1) опросить клавиатуру;
2) преобразовать HID-сканикоды в матрицу;
Весьма не много ресурсов съест, и делать это надо всего-то 5-10 раз в секунду, постоянно актуализируя массив эмуляции матрицы (например во время кадрового бланка когда есть время простоя)
3) выдать запрошенную строку из матрицы.
А вот это ровно 3 команды на ассемблере: считать сканкод (в контроллере на Атмеге измение сканкода на порте вводе генерит прерывание), из готовой таблицы (той самой что постоянно актуализируется на шагах 1-2) используя скан код как индекс прочитать ответ, выдать этот ответ на порт.
Все остальное время обрабатывать дисплей.
Контроллер по моей ссылке тоже обрабатывает клавиатуру (там же не только видеокарта, но полный терминал), при этом на частоте в 25МГц ему хватает времени еще и на VGA с полной эмуляцией VT100/52. Исходники на git есть по ссылке в статье.
А вот это ровно 3 команды на ассемблере: считать сканкод (в контроллере на Атмеге измение сканкода на порте вводе генерит прерывание), из готовой таблицы (той самой что постоянно актуализируется на шагах 1-2) используя скан код как индекс прочитать ответ, выдать этот ответ на порт.
Все остальное время обрабатывать дисплей.
Контроллер по моей ссылке тоже обрабатывает клавиатуру (там же не только видеокарта, но полный терминал), при этом на частоте в 25МГц ему хватает времени еще и на VGA с полной эмуляцией VT100/52. Исходники на git есть по ссылке в статье.
Ээээ... Мы про разные вещи говорим, видимо...
У меня одна из целей - одновременная реакция на 6 нажатых кнопок (максимум пакета данных). А это уже требует выставления битовых масок и прочего.
Да, согласен - это очень легко оптимизируется. Но я ещё только-только получил рабочую версию. Завтра займусь в том числе и потимизациями.
И да - как я говорил выше, сейчас почти всё время отжирает отрисовка экрана, про "прожорливость" других пунктов ничего не было сказано. Пока что отрисока одного экрана (полностью, попиксельно, на каждый пиксель по пачке команд - установка координат, цвет пикселя) занимает около 400мс... Код не мой, поставлялся вместе с библиотекой uc/GUI - подделие сумеречной китайско-индусской мысли.
Error404
18.03.2018, 23:53
Ээээ... Мы про разные вещи говорим, видимо...
У меня одна из целей - одновременная реакция на 6 нажатых кнопок (максимум пакета данных). А это уже требует выставления битовых масок и прочего.
Дело не в количестве одновременно нажатых кнопок, оно может быть любым - это просто вопрос алгоритма формирования выходного результат. Говорим мы про одинаковые вещи, просто ты явно пошел не оптимальным путем (как обычно). А оптимальный (который позволил 10 лет назад на 8-Мгц 8-бит микроконтроллере с 512б (байт, Карл!) ОЗУ реализовать контроллер клавы с эмуляцией реакции матрицы в онлане, т.е. без Wait, т.е. не более чем за 4 такта реального Z80 с тактом 5Мгц) в том, чтобы когда есть вагон времени - формировать матрицу всех вариантов ответа, а по запросу хоста (когда надо отреагировать моментально) - в 3 команды брать уже готовый результат.
Если еще не понятно, я говорю в этом примере о контроллере от Caro, который в двух сотнях Орионов работает (и ХЗ сколько РК и ему подобных).
Оптимизировал как мог, в итоге получилось почти оптимальное быстродействие GUI.
https://image.prntscr.com/image/dEIvR86_Tyqynd-_XlZ5Yw.png
Отрисовка экрана библиотекой занимает около 4.4мс, вывод кадра на LCD - 17.5мс, обработка USB и преобразование в матрицу кнопок - около 8.4мкс. Если было бы больше памяти, не пришлось бы мудрить со сжатием картинки и заодно отправка данных на LCD сократилась бы до старта DMA - но для этого нужен другой "камень", от 140Кб памяти (из них 120 - под экран только).
В итоге заметно, что процессор почти всё время простаивает и можно загрузить прочей работой ;)
Разумеется, приличную часть времени будет занимать цикл реакции на входные сигналы от матрицы, что пока что не реализовано. Но всё равно запас по быстродействию приличный.
Что-то я не понимаю, может, ну его нафиг этот экран, а всю дебаг инфо гнать в сериал?
Что-то я не понимаю, может, ну его нафиг этот экран, а всю дебаг инфо гнать в сериал?
Экран есть тут и сейчас, на него не надо переключаться ;) И отображается информация удобно. А для UART надо ещё сидеть и переключаться на терминал для контроля.
Итак, дома проверю стабильность работы со свистком и добью таблицу сканкодов.
Без всяких премудростей (наподобие аппаратного прерывания при появлении запроса, решается одним большим И-НЕ при инверсной шине) частота выдачи данных по матрице составляет 1кГц.
Есть у кого-либо клавиатура, подписанная по раскладке MC7007 или RK86? А то не понимаю, что там за чудные клавиши такие :) В последний раз за такой сидел ооочень уж давно, что бы всё помнить.
- - - Добавлено - - -
Нашел этот пост (http://zx-pk.ru/threads/9294-orion-128-kontroller-ps-2-klaviatury.html?p=484947&viewfull=1#post484947). Насколько оно соответствует последней версии того контроллера?
И получается, что надо делать для каждой раскладки 2 таблицы - для английской и для русской версии.
Для теста работы сейчас заполнил таблицу для NumPad'а в раскладке MC7007 - всё работает отлично.
По поводу хардвари - можно заложить контроллер с большим количеством ног, а неиспользуемое вывести через нераспаянные буферы наружу для будущих расширений. Так же можно сразу заложить SD-карту в схему - это вообще легко (разъём, пачка резисторов для подтяжки линий, да конденсатор по питанию).
Само собой, будет пара светодиодов для индикации работы устройства - сейчас уже примерно прикидываю схему.
По деталям:
1) МК - STM32F407VET6 - 5$ за корпус; 1шт.
2) Коммутатор питания USB - STMPS2141STR - 0.6$ за корпус; 1шт.
3) Буффер 3.3v<>5v - SN74ALVC164245 - 1.2$ за корпус; 2шт (или 3 при расширении).
4) Стабилизатор питания - не определён, импульсный; 1шт.
Итого по деталям получается около $10 на 1 устройство. Если расширять сразу, то будет около 13. Стоимость платы будет около 0.5$ по максимуму.
PS: Надо определиться с "хотелками"...
- - - Добавлено - - -
Заодно сейчас придумал, как оптимизировать таблицы раскладок - при размере матрицы 12х12 каждая таблица будет занимать именно 144 байта. Для каждой раскладки надо 2 такие таблицы (LAT/RUS) и ещё 1 маленькая на 4 байта для доп. клавиш (Ctr, Alt, Shift, Win). Получается 292 байта на раскладку.
Вообще, стоит подумать над тем, чтобы девайс цеплялся максимально просто, например в zx-bus и без паяльника. Так получится охватить наибольшее количество желающих, в том числе и в забугорье. Ну а для нашего зоопарка клонов оставить гребенку чтобы подключённый разъём распаять как угодно.
А из хотелок - например, оставить возможность легкого апгрейда через USB или SD/mSD, а также завести полностью шины адреса, данных и управления для того, чтобы любую вновь появившуюся хотелку можно было легко добавить обновлением микрокода.
Вообще, стоит подумать над тем, чтобы девайс цеплялся максимально просто, например в zx-bus и без паяльника. Так получится охватить наибольшее количество желающих, в том числе и в забугорье. Ну а для нашего зоопарка клонов оставить гребенку чтобы подключённый разъём распаять как угодно.
А из хотелок - например, оставить возможность легкого апгрейда через USB или SD/mSD, а также завести полностью шины адреса, данных и управления для того, чтобы любую вновь появившуюся хотелку можно было легко добавить обновлением микрокода.
Контроллер разрабатывается не только для Speccy, поэтому жёстко привязываться к какой-либо шине сомнительно.
А обновление с флешки - сегодня как раз и собираюсь сделать.
Реализовано обновление прошивки через USB-Flash (https://github.com/andreili/USB-Keyboard/commit/9257fd618335f83b7c70bc005b5124282ae62ace).
Флешка вставляется вместо клавиатуры, после чего включается устройство. Загораются 2 светодиода режимов, по завершении обновления один из них начнёт мигать - после этого можно извлечь флешку и перезагрузить устройство для старта с новой прошивкой.
По умолчанию при старте примерно 3 секунды проверяется наличие флешки в разъёме. Если обнаружена - пытается с неё обновиться. Если не обнаружена или произошла ошибка (несовпадение контрольных сумм, файл не прочитался) прошивка отработает дальше и будет работать как клавиатура.
Нарисовал первый вариант схемы (https://raw.githubusercontent.com/andreili/USB-Keyboard/master/hw/usb_keyb.pdf), с минимальными линиями по матрице.
Отхождение от минимума пока только одно - слот для карты памяти, но это мелочь. Остальное для подключения прочей периферии выведено на сигналы (SPI, I2C, UART), будет выведено на разъёмы для возможности подключения прочих "довесков" (дисплей, например).
Так же на входах и выходах матрицы везде разместил подтягивающие резисторы - если будут лишними, просто не надо будет запаивать - это лучше, чем напаивать "на соплях" при необходимости.
Расширение для подключения к ZX-BUS возможно выполнить в виде фрагмента платы, который при необходимости можно будет отломать/отпилить от основной платы - все эти же линии будут выведены на штырьевые коннекторы на самой плате (пока что в схеме их нет, будут задействованы сигнальные лини с матрицы и ещё дополнительные через свободные выводы буферов).
Готов выслушать замечания и предложения по схемной реализации, с учётом описанного выше.
А второй usb там доступен? Ну, чтобы ещё и кемпстон маус с колесом завести заодно?
А второй usb там доступен? Ну, чтобы ещё и кемпстон маус с колесом завести заодно?
Можно и 2 развести, но тут уже надо разруливать что и где "висит". На плате разведён только OTG HS, OTG FS можно только с внешним PHY реализовать. Если подключать беспроводные, то можно и 1 разъёмом обойтись.
- - - Добавлено - - -
Попутал по USB - разведён FS, HS - это более скоростной вариант, для него нужны строго диффпары, а на плате разведено "как попало".
Обновил схему (https://raw.githubusercontent.com/andreili/USB-Keyboard/master/hw/usb_keyb.pdf).
Добавлен разъём ZX-BUS. SPI, I2C, UART выведены на свои разъёмы для подключения периферии в дальнейшем.
Основные сигналы для непосредственного подключения к шине процессора Z80 заведены в контроллер для минимизации отклика на запросы - реализовано подачей сигналов IORQ, RD, WR, MREQ на входы аппаратных прерываний, в обработчиках которых в зависимости от выбранного режима будет выполняться свой участок программы.
Так же добавил второй разъём USB - в прошивке работу с 2-мя устройствами смогу проверить только после получения плат.
Так же, поскольку есть разъём ZX-BUS, можно впихнуть и функционал из ZX Multi Card - RS232 реализован с линиями RTS/DTS, часы добавить не проблема.
В итоге будет 3 группы конфигурационных переключателей/перемычек (всё приведено примерно, пока ничего не определено):
1) 2 бита - выбор режима работы клавиатуры - матрица, ВВ55;
2) 5 бит - выбор матрицы преобразований кодов;
3) 5 бита - выбор режима выхода - матрица (непосредственный вывод данных), с декодированием адреса (по стробу IORQ, для разных устройств различные комбинации для выбора адресов отклика).
Итого - схема приняла почти финальный вид, осталось только добавить преобразователь питания и, при необходимости, оптимизировать расположение выводов в ходе трассировки.
Большое спасибо за интересный и полезный проект.
Выход возможен различный, зависит от фантазии - матрица для прямого подключения, PS/2, SPI и т.д.
В итоге будет 3 группы конфигурационных переключателей/перемычек (всё приведено примерно, пока ничего не определено):
1) 2 бита - выбор режима работы клавиатуры - матрица, ВВ55;
2) 5 бит - выбор матрицы преобразований кодов;
3) 5 бита - выбор режима выхода - матрица (непосредственный вывод данных), с декодированием адреса (по стробу IORQ, для разных устройств различные комбинации для выбора адресов отклика).
Итого - схема приняла почти финальный вид, осталось только добавить преобразователь питания и, при необходимости, оптимизировать расположение выводов в ходе трассировки.
А просто выход PS/2 будет на этой платке? Ну чтобы использовать usb клавиатуры с клонами с набортным входом ps/2 и поддержкой дополнительных клавиш (типа ZX Evolution).
Отличное устройство!
andreil, можешь еще добавить поддержку ESP-12 как здесь (http://forum.tslabs.info/viewtopic.php?p=29272#p29272)?
Было-бы неплохо ещё и VS1053 (https://www.sparkfun.com/datasheets/Components/SMD/vs1053.pdf) для проигрывания с флешки.
Большое спасибо за интересный и полезный проект.
А просто выход PS/2 будет на этой платке? Ну чтобы использовать usb клавиатуры с клонами с набортным входом ps/2 и поддержкой дополнительных клавиш (типа ZX Evolution).
Да, это вполне возможно сделать. Надо будет только определиться с формированием сигналов - надо сделать это на аппаратном уровне.
Да, это вполне возможно сделать. Надо будет только определиться с формированием сигналов - надо сделать это на аппаратном уровне.
Это было бы просто здорово! Симпатичных и компактных ps/2 клав уже днем с огнем не сыщешь, а вот usb - валом.
Отличное устройство!
andreil, можешь еще добавить поддержку ESP-12 как здесь (http://forum.tslabs.info/viewtopic.php?p=29272#p29272)?
Было-бы неплохо ещё и VS1053 (https://www.sparkfun.com/datasheets/Components/SMD/vs1053.pdf) для проигрывания с флешки.
1) UART выведен на разъём, можно к нему подключить.
2) Он подключается через SPI, который так же выведен на разъем. Дополнительно только пару GPIO с I2C можно подтянуть или линии DTS/RTS с UART'а.
Так что всё это вполне подключаемо. Проблема в том, что свободные выводы контроллера уже почти закончились ;)
Набросал примерное расположение деталей на плате - в "2 платки на 1 заготовке" уже не вписывается - нет места для организации краевого разъёма ZX-BUS. Да и при такой плотности уже будет геморная разводка. Габариты платы - 48х100мм. Думал сделать 2 платы с зазором для распиливания самому по вырезам, но видимо не судьба :)
https://image.prntscr.com/image/1MzMzhf1RuarIRlPsnnAwA.png
https://image.prntscr.com/image/AaDZp0gvSh_dqDX4QXa27Q.png
Теоретически, можно буферы на нижний слой вытолкнуть, может и получится вписаться в текущие габариты с краевым разъёмом - компоновка только-только набросана ещё. Ещё не размещал пачку резисторов подтягивающих, коих легион :)
- - - Добавлено - - -
Или я не прав и ZX-BUS на платах расширения ставится разъёмом? Просто никогда в глаза не видел такого :)
Error404
21.03.2018, 15:31
А будет ли Ethernet?
Пишут, в STM32F407VET6 оно есть. Тогда запилить туда и аналог Визнета (т.е. движок с готовым TCPIP, например на lwIP), чтобы 8-бит хосту отдавать сразу bsd-сокеты (чем больше сокетов тем лучше, память позволяет). Уже хоть какое-то оправдание ценнику в готовый комп типа OrangePI.
blackmirror
21.03.2018, 15:35
Так что всё это вполне подключаемо. Проблема в том, что свободные выводы контроллера уже почти закончились
http://zx-pk.ru/attachment.php?attachmentid=64701&d=1521634804
Это пример как к 3м ногам контроллера подключить 6 светодиодов. Но тут нужно будет делать динамическую индикацию. Еще можно повесить на эти же ноги и кнопки, которые будут опрашиваться перед переключением на другой светодиод(через резисторы чтобы не спалить светодиоды). Назначение кнопок может быть: Mode, Up, Down.
Изначально светодиоды показывают состояние устройства.
Нажатием кнопки Mode(если параметров не много) будет выбираться номер параметра подлежащего изменению, при этом светодиоды будут высвечивать его номер.
Нажатием кнопок Up/Down можно будет изменять значение параметра, при этом светодиоды будут мигать высвечивая его значение.
Длительным нажатием кнопки Mode параметра будет записываться во Flash микроконтроллера, а при коротком изменения будут отменяться и производиться переход к следующему параметру.
При такой схеме используя всего три ноги можно будет настраивать до 64 параметров по 64 значения у каждого.
64701
А будет ли Ethernet?
Пишут, в STM32F407VET6 оно есть. Тогда запилить туда и аналог Визнета (т.е. движок с готовым TCPIP, например на lwIP), чтобы 8-бит хосту отдавать сразу bsd-сокеты (чем больше сокетов тем лучше, память позволяет). Уже хоть какое-то оправдание ценнику в готовый комп типа OrangePI.
Тогда придётся ставить ещё более "жирный" по ногам чип - в текущий уже по сигналам дошло "до упора". И ещё чип ETH-MAC с обвязкой и разъемом - сразу плюс к ценнику будет около $3.
- - - Добавлено - - -
Это пример как к 3м ногам контроллера подключить 6 светодиодов. Но тут нужно будет делать динамическую индикацию. Еще можно повесить на эти же ноги и кнопки, которые будут опрашиваться перед переключением на другой светодиод(через резисторы чтобы не спалить светодиоды). Назначение кнопок может быть: Mode, Up, Down.
Изначально светодиоды показывают состояние устройства.
Нажатием кнопки Mode(если параметров не много) будет выбираться номер параметра подлежащего изменению, при этом светодиоды будут высвечивать его номер.
Нажатием кнопок Up/Down можно будет изменять значение параметра, при этом светодиоды будут мигать высвечивая его значение.
Длительным нажатием кнопки Mode параметра будет записываться во Flash микроконтроллера, а при коротком изменения будут отменяться и производиться переход к следующему параметру.
При такой схеме используя всего три ноги можно будет настраивать до 64 параметров по 64 значения у каждого.
64701
В курсе такой схемы, но у меня тут не используется ни кнопок, ни светодиодов. Думаю вот вместо буферов ставить GPIO-EXT, которые с МК будут связаны только по SPI или I2C. Тогда можно будет и трассировку упростить, и впихнуть что-либо ещё.
Одно но - для разъёмов места совсем мало, посмотрите компоновку на картинках. Но PS/2 и Ethernet ещё можно разместить, теоретически.
PS: Разъёмы и ETH-MAC у меня в "загашнике" есть в наличии, если что ;) Дело за реализацией.
- - - Добавлено - - -
Один минус у расширителей портов - их нельзя ставить на скоростные сигналы, поскольку они работаю очень медленно. Если подразумевать подключение к ZX-BUS, то вряд ли такое решение получится реализовать с расширителями =/
omercury
21.03.2018, 15:54
Теоретически, можно буферы на нижний слой вытолкнуть
То есть все пины STM32F4xx уже как бы и не толерантны к 5 вольтам?
Ещё не размещал пачку резисторов подтягивающих, коих легион
То есть встроенных pull-up, pull-down недостаточно?
То есть все пины STM32F4xx уже как бы и не толерантны к 5 вольтам?
То есть встроенных pull-up, pull-down недостаточно?
1) Принять 5В они могут, но передать - уже уровни не совпадут. И для надёжности все сразу через преобразователи уровней пропущены.
2) Все они "висят" на стороне ZX-BUS уже.
omercury
21.03.2018, 16:16
1) Принять 5В они могут, но передать - уже уровни не совпадут.
А что, простите, они должны передавать?
Шину адреса или управляющие сигналы?
2) Все они "висят" на стороне ZX-BUS уже.
Шина данных, насколько мне известно, уже имеет подтяжку на процессоре, поэтому может (а на самом деле должна) быть open-drain.
То же относится и ко всяким интам и прочим нми...
А что, простите, они должны передавать?
Шину адреса или управляющие сигналы?
Шина данных, насколько мне известно, уже имеет подтяжку на процессоре, поэтому может (а на самом деле должна) быть open-drain.
То же относится и ко всяким интам и прочим нми...
Пишутся - ШД и прерывания.
Честно - не в курсе таких нюансов, это будут знать те, кто имеет опыт разработки ПК на Z80.
omercury
21.03.2018, 16:45
Пишутся - ШД и прерывания.
Не пишутся - подтягиваются к "земле".
Туплю.
Надо глянуть ДШ на МК - если эти ноги понимают 5V, тогда их все перевести в OD и работать без буферов можно. Главное - подтяжка должна быть 100%.
- - - Добавлено - - -
Есть тут свои "грабли" у OD на STM32, обсуждалось как-то (http://we.easyelectronics.ru/STM32/gpio-vyhod-v-rezhime-opendrain.html).
Если все сигналы перевести на ОК, тогда буферные элементы удаляются и освобождается достаточно много места на плате для размещения Ethernet...
Завтра ещё заменю два USB одним сдвоенным, карта памяти тогда переместится на место нижнего разъёма, остальное разрисовал примерно на картинке (https://image.prntscr.com/image/NKXNjqn7Q1KcPtZu3WNLWQ.png).
Завтра попробую это всё скомпоновать, с учётом новых элементов для MAC.
По поводу Ethernet - добавлять полностью на плату или делать в виде подключаемого модуля? С алика заказываются готовые, стоят копейки, работают 100% - модуль DP83848 (https://www.waveshare.com/wiki/DP83848_Ethernet_Board). Стоимость платы экономит, места меньше. Кому нужен Ethernet - купит модуль и вставит в коннектор.
Если касаться цены - собранный модуль на алике стоит по сибестоимости - поищите детали на него, один только чип отдельно стоит 2,5$, а ещё разъём, кварц и рассыпуха. Да и что-то не ладится мой вариант этой же схемы на макетке - нет ответа от него, дальше сброса не идёт =/
С набортным Ethernet'ом и со всеми деталями плата примерно такая:
https://image.prntscr.com/image/5mFw7cobT5_FPCb_ow-hKg.png
Компоновка по принципу "абы всё накидать", только сгруппировано более-менее по схеме. Разъём USB использую сдвоенный - значительно экономится дефицитное место на плате. Сверху справа вне платы - блок питания для схемы, импульсный преобразователь до 3.3В. После смещения резисторов место для него появится, ест.
Завтра, если с работой надолго не застряну, обдумаю распределение сигналов для ZX-BUS и иже с ним, так же придумаю, куда пристроить выход PS/2.
- - - Добавлено - - -
PS: Сейчас на работе немного напряг, из-за ночных морозов внезапно позамораживались отопители до лопнувших труб, а утром это всё полилось ручьём по цехам =/ Искали причины и устраняли прочие найденные косяки...
Error404
23.03.2018, 01:08
По поводу Ethernet - добавлять полностью на плату или делать в виде подключаемого модуля? С алика заказываются готовые, стоят копейки, работают 100% - модуль DP83848 (https://www.waveshare.com/wiki/DP83848_Ethernet_Board). Стоимость платы экономит, места меньше. Кому нужен Ethernet - купит модуль и вставит в коннектор.
Платка DP83848 с Али = 400 руб. - смысл теряется: столько же стоит Wiznet5500 с уже готовым TCPIP на 8 сокетов.
Тогда уж ENC28J60, оно хотя бы 150р.
Но это конечно в порядке фантазии, может и не заморачиваться.
А езернет этот с программной стороны как будет доступен?
Если уж городить сеть, то можно до кучи поставить гребенку под вай-фай модуль на ESP8266, тем более что TCPIP стек оно умеет самостоятельно крутить внутри.
Платка DP83848 с Али = 400 руб. - смысл теряется: столько же стоит Wiznet5500 с уже готовым TCPIP на 8 сокетов.
Тогда уж ENC28J60, оно хотя бы 150р.
Но это конечно в порядке фантазии, может и не заморачиваться.
Ну, не я задаю цены на чипы, уж извините :(
А для ENC нужен SPI. который будет и так выведен. Только распиновку можно поменять, что бы модуль воткнуть напрямую.
- - - Добавлено - - -
А езернет этот с программной стороны как будет доступен?
Если уж городить сеть, то можно до кучи поставить гребенку под вай-фай модуль на ESP8266, тем более что TCPIP стек оно умеет самостоятельно крутить внутри.
На СТМке будет крутиться LwIP, весь стек ниже реализован на чипе.
По ESP - тут нужен SPI и/или UART, которые уже выведены наружу.
Городить кучу разъёмов для подключения различных модулей смысла нет - вся плата будет забита только ими. По факту - достаточно развести базовые интерфейсы (а SPI с парой чипселектов сразу).
Из новостей.
С HAL-библиотекой выползла неожиданная проблема - она адекватно работает только с простыми HID-устройствами, с композитными спотыкается напрочь. Буду искать причины в коде, поскольку почти весь код был переписан с SPL, на котором эти же устройства работали исправно.
А если подключать простые устройства (только клава или мышь) - всё работает как часы.
Так же надо будет пропатчить библиотеку для одновременной работы 2-х устройств с 1 порта (т.е. для составных устройств).
Так же завтра продолжу "мучать" схему с платой.
Мда, чем дальше - тем интереснее...
Оказывается, что библиотеки HAL написаны так, что криво поддерживают USB 1.0 - обнаружил сегодня (http://forum.easyelectronics.ru/styles/easyelectronics/imageset/icon_post_target.gif). Буду копать, ибо это не дело.
Можно записаться в очередь на платку?) Приобрету с удовольствием!) а может и не одну!;)
Можно записаться в очередь на платку?)
Если что, я тоже в очередь на голую платку встал бы, если свободные будут.:v2_blush:
Тут самый главный вопрос - "когда?".
Сейчас активно работаю над выходом PS/2, потом займусь организацией работы в режиме "ZX-BUS", где девайс будет "прикидываться" портами клавиатуры, джойстика и мыши - от их реализации зависит разводка платы.
Сейчас уже стабильно работают мышка + клава - всё определяется, данные получаются и преобразовываются в промежуточный формат, для дальнейшей выдачи по обработчикам.
Вся разработка отражена в коммитах репы (https://github.com/andreili/USB-Keyboard/commits/master), здесь только что-либо значимое пока что публикую.
- - - Добавлено - - -
Пока что единственная проблема - подключение к шинам ZX'а.
Если делать напрямую, переведя все необходимые пины в режим ОК (Открытый коллектор, Open Drain), тогда в момент сброса МК на этих пинах будет активный 0 висеть. То есть если при работающем спеке сбросить МК кнопкой, то получим зависанием спека по причине нулей на ШД - управляющие сигналы и ША через диоды развязываются от этого. Так что, скорее всего придётся-таки ставить управляемый буффер как минимум на ШД.
А его зачем сбрасывать отдельно? Он склонен к зависаниям? Пусть общим ресетом его дергают, не?
А его зачем сбрасывать отдельно? Он склонен к зависаниям? Пусть общим ресетом его дергают, не?
Пока что есть беда со стабильностью определения HID-устройств. Накопители определяет почти 100%, сбои очень редки. А вот с HID ситуация похуже - 3/10 неудачно. Перед инициализацией стека USB выставил задержку в 700мс, что бы всё остальное запустилось - и увеличил до 9/10. А если всё подключить после загрузки устройства - будет 100% работоспособность. В общем, пока что есть над чем поработать.
И ещё - найдена ещё одна проблема, попробую её завтра устранить. Заключается в том, что один из моих свистков, работающий по USB 1.0, слишком сильно просаживает линию D+, в итоге контроллер своим транзистором слабомощным не может поднять его до лог.1. Попробую навесить подтяжку к питанию, может и поможет.
Реализовано преобразование USB HID -> PS/2 (https://github.com/andreili/USB-Keyboard/commit/be008d43caed84cca6731df026dbf47dbe9ccb8a). Проверено пока что только логическим анализатором - попробую припаять шнурок от клавиатуры и подключить к компьютеру для полноценной проверки.
А вот с HID ситуация похуже - 3/10 неудачно
В библиотеке stm32 очень убогий USB-хост (помимо остальных проблем). И в добавок в моей практике встречалась куча клавиатур нарушающих USB стандарт самыми разнообразными способами, в том числе от именитых производителей. Казалось бы чего проще - отдай пакет из 8 байт в interrupt EP и потом пришли пакет нулевой длины как завершение передачи, что требуется по стандарту. Дык, чего только не попадалось - и честный нулевой пакет, и empty/NAK, и stall. Некоторые клавиатуры когда им нечего передавать отвечают stall вместо empty/NAK. Под это все стек от ST надо допиливать. Финалом маразма стал беспроводной комплект LG из мыши и клавиатуры. Там в конфигурации репортится два HID-а, первый клавиатура, оно нормально обрабатывается. Но при нажатии F1-F4 почему-то генерируется отчет и в канале мыши. Если софт не обрабатывает такое составное устройство (или обрабатывает только одно - клавиатуру), то канал мыши он, ессно, не вычитывает, и клавиатура нафиг зависает.
В библиотеке stm32 очень убогий USB-хост (помимо остальных проблем). И в добавок в моей практике встречалась куча клавиатур нарушающих USB стандарт самыми разнообразными способами, в том числе от именитых производителей. Казалось бы чего проще - отдай пакет из 8 байт в interrupt EP и потом пришли пакет нулевой длины как завершение передачи, что требуется по стандарту. Дык, чего только не попадалось - и честный нулевой пакет, и empty/NAK, и stall. Некоторые клавиатуры когда им нечего передавать отвечают stall вместо empty/NAK. Под это все стек от ST надо допиливать. Финалом маразма стал беспроводной комплект LG из мыши и клавиатуры. Там в конфигурации репортится два HID-а, первый клавиатура, оно нормально обрабатывается. Но при нажатии F1-F4 почему-то генерируется отчет и в канале мыши. Если софт не обрабатывает такое составное устройство (или обрабатывает только одно - клавиатуру), то канал мыши он, ессно, не вычитывает, и клавиатура нафиг зависает.
Это уже частные случаи, надо смотреть.
И по библиотеке - со времён SPL'а там многое поменялось в стеке USB, добавилось много обработчиков всяких ситуаций. Так что, может быть, что-то стало и лучше. Но такие случаи, как с упомянутым выше свистком - это вообще криворукость разработчиков железки, софтом это не исправить, при требовании полной совместимости со всем спектром устройств.
PS: Сейчас буду вспоминать, как реализована клавиатура, джойстик и мышь в спеке - надо определиться, по каким сигналам нужны будут прерывания.
- - - Добавлено - - -
Так, по клавиатуре ZX'а - её выбор идёт при лог.0 на A0, /IORQ, /RD. Это понятно. Вопрос в организации циклов сканирования - они идут по 1 строке? То есть на одной из линий A8-A15 (которые отображают состояние аккумулятора во время чтения) будет активный лог.0, если я всё правильно понял.
И стоит ли делать дешифрацию адреса порта полной, по всем линиям A0-A7? (Пока что смотрел только в схему Ленинграда).
- - - Добавлено - - -
Если мои рассуждения выше верны. то черновой вариант клавиатуры для ZX-BUS уже готов.
Обработка вызывается по внешним прерываниям на выводах МК - линии /IORQ, /RD, /WR:
void zxbus_proc(int GPIO_Pin){
switch (GPIO_Pin)
{
case ZXBUS_PIN_IORQ:
if ((ZXBUS_PORT->IDR & (1 << ZXBUS_PIN_RD)) == 0)
zxbus_proc_int_rd();
if ((ZXBUS_PORT->IDR & (1 << ZXBUS_PIN_WR)) == 0)
zxbus_proc_int_wr();
break;
case ZXBUS_PIN_RD:
if ((ZXBUS_PORT->IDR & (1 << ZXBUS_PIN_IORQ)) == 0)
zxbus_proc_int_rd();
break;
case ZXBUS_PIN_WR:
if ((ZXBUS_PORT->IDR & (1 << ZXBUS_PIN_IORQ)) == 0)
zxbus_proc_int_wr();
break;
}
}
Данная функция вызывается обработчиком прерываний, если переключателями был выбран режим ZX-BUS. И в зависимости от значения GPIO_Pin (то есть от того, по какому выводу мы ушли сюда), смотрим дальше - что у нас активно. В итоге, независимо от таймингов и задержек в логике, чтение из порта клавиатуры будет вызвано только при одновременно активных /IORQ и /RD.
Ну а поскольку со схемой этой части уже всё решено (для запаса на дальнейшие расширения под прерывания можно выделить любой из управляющих сигналов процессора - /INT, /NMI, /IORQ, /RD, /WR, /MREQ, /M1). В зависимости от других режимов на эти линии можно подключить другие сигналы.
А на порт данных для ZX-BUS всё-таки повешу двунаправленный буфер, управляемый напрямую сигналом с МК, формируемым при чтении из порта. Всё остальное время в режиме ZX-BUS он будет работать в направлении к МК. Сигнал /OE для него заведу на джампер выборки режима ZX-BUS - что бы в прочих случаях не мешал.
- - - Добавлено - - -
Обновил схему (https://andreil.by/orion/usb_keyb.pdf).
Дальше в ней осталось только пара вещей:
1) повесить светодиоды на те же ноги, что и DIP-переключатель - всё равно они используются только при запуске для считывания режимов.
2) подумать над разъёмами.
Итого у контроллера использованы все выводы, и имеем резерв на ещё 3 режима выхода (сейчас есть PS2, ZX-BUS, MATRIX) и 256 вариантов преобразований матрицы клавиатуры.
Контроллер Ethernet при необходимости подключается к разъёму.
Для подключения прочей периферии на разъёмы выведены SPI, I2C, UART. Пару выводов от переключателя выбора матрицы надо будет завести как чипселекты для SPI.
Так же выход PS/2 надо будет сделать через транзисторы, что бы поднять уровень сигналов до +5В.
Итак, обновил плату и раскидал компоненты. Назначение выводов может ещё поменяться, но это не важно ещё - разводить ещё и не начинал, пока что рано.
Вот примерный вид платы с компонентами:
Вид сверху (https://image.prntscr.com/image/g_W8TCCPQCyt4szygcojCg.png) и вид снизу (https://image.prntscr.com/image/kN3Qp6_WQ76MZc7UL7JYwQ.png).
Скомпоновал таким образом, что разъём ZX-BUS (2 ряда отверстий снизу) на верхнем виде сориентирован так, что под резистором R42 находится пин A15, а под R41 - A14. То есть плата спека и собственно сам разъем будут сзади платы при таком подключении, а все детали и разъёмы будут смотреть наружу, ничему не мешая.
Если с ориентацией разъёма напутал, дайте знать, ориентировался на фото в гугле ;)
Часть подтягивающих резисторов около разъёма излишняя - запаиваются по необходимости. Лучше иметь площадку для запайки, чем потом крутить с проводками и соплями.
Для надёжности добавил полноценную защиту USB - всё по хрен-шую ;)
https://image.prntscr.com/image/AKCpWiLARE6CLToFLqdsyA.png
Это ведёт к небольшому увеличению стоимости, но повышает надёжность - иначе при попадании статики на разъём выгорит МК. Так же защита от наводок и прочего.
Или нафиг эти защиты?
А какой функционал на данный момент задуман?
Пока - подключение клавиатуры и мыши, флешки, SD-карты.
В дальнейшем через пару разъемов можно будет повесить какой-либо дисплей (для меню плеера/эмулятора ВГ), Ethernet-контроллер (хоть по SPI, хоть по RMII).
А к сд-карте со стороны Спектрума как обращаться? Я даже не в курсе, вдруг есть уже какие-нибудь стандарты. Кстати, было бы забавно подключить модуль на мсх VS1053 (мультиформатный аудиодекодер), которая может получать по I2C поток данных (с сд-Карты) и играть из себя сякие мп3, огг и прочие миди. Надеюсь, спектрум успеет справиться с передачей данных )
А к сд-карте со стороны Спектрума как обращаться? Я даже не в курсе, вдруг есть уже какие-нибудь стандарты. Кстати, было бы забавно подключить модуль на мсх VS1053 (мультиформатный аудиодекодер), которая может получать по I2C поток данных (с сд-Карты) и играть из себя сякие мп3, огг и прочие миди. Надеюсь, спектрум успеет справиться с передачей данных )
С картой памяти можно работать как угодно, в том числе и напрямую - в режиме ZX-BUS можно сделать обработку сигналов шины для поддержки SD-карты.
Всё ограничено фантазией и быстродействием.
Аналогично и с VS - можно сделать позже.
Сейчас надо до конца "устаканить" схему и развести плату.
"Устаканил" основные вопросы по схеме USB, ничего не изменилось. Больше времени потратил на изучение трассировки диффпар :)
За вечер развёл часть 2xUSB, microSD, а так же частично затронул шину.
https://image.prntscr.com/image/6siMZEIRQNqKqyLJtYd3eA.png
Заливка показана контурами, что бы все слои были видны сразу. Пока развожу в 2 слоя, но в резерве "висят" промежуточные слои - по ним пока что проводится питание. Если получится развести "как есть" все сигналы от МК, эти 2 слоя уберутся. А нет - буду делать 4-х слойку... По финансам получается около $42 за 20 платок (10 заготовок, по 2 платы на каждой).
Вопрос ко всем - делать ли отдельные разъемы для подключения матрицы, если все эти сигналы и так выведены на разъём ZX-BUS? Если делать 2 набора разъёмов, то будет 2 ряда по 13 контактов для матрицы и сама ZX-BUS. Если делать только ZX-BUS, то для подключения к колодке придётся подпаиваться к пинам шины (или через разъём, не принципиально). Тут дело банально в удобстве - или расположенные подряд выводы или чутка вразнобой.
Если оставить только ZX-BUS, то разводка несколько упроститься.
Понемногу провожу трассировку по вечерам. Остались один набор джамперов/выключателей и шина ZX-BUS. Может быть даже чуть уменьшу габариты платы по вертикали, что бы уменьшить вероятность повреждения при разрезании заготовки - на одной заготовке будет 2 платы (цена от этого не меняется, только разрезать придётся вручную, неметализированные отверстия они не делают).
И да - плата будет 4-х слойной - в промежуточных будут только питание, все сигнальные линии будут проходить только по внешним слоям. Это значительно упрощает трассировку питания и улучшает надёжность работы :)
https://image.prntscr.com/image/2kscYMYxQaWjDJ1hJrtrmw.png
Кстати, раз там обосновались клавиатура и мышь, логично бы туда же заехать паре джойстиков, кемпстон и синклер2 например.
Кстати, раз там обосновались клавиатура и мышь, логично бы туда же заехать паре джойстиков, кемпстон и синклер2 например.
Они реализуются софтварно уже, внутри МК. Это я и так думал делать сразу. Для спектрума это в любом случае решается очень быстро, даже в варианте без использования ZX-BUS - просто некоторые сигналы на разъёме используются для джойстика (от клавиатуры там много свободных остаётся для матричного режима - у меня заложена максимальная матрица 12х12 клавиш).
А если джойстики подключать через USB? Насколько сложно их будет распарсить?
А если джойстики подключать через USB? Насколько сложно их будет распарсить?
Если это HID-устройство - то всё очень легко. Достаточно узнать структуру пакетов и написать мелки класс для их разбора. Вот, на примере мыши (https://github.com/andreili/USB-Keyboard/blob/master/fw/Middlewares/ST/STM32_USB_Host_Library/Class/HID/Src/usbh_hid_mouse.c). Так что ничего сложного ;)
Почти развёл плату. Все сигнальные лини - строго в 2 слоя, никаких сигналов в слоях питания.
Заметно, что на плате хватает свободного места - можно ещё что-либо из периферии вывести, параллельно с текущими сигналами (сейчас все линии и так максимально заняты, свободных выводов нет).
Думаю плату немного ужать по вертикали - даст дополнительную гарантию целостности при распиливании заготовки - сейчас зазор около 3мм.
https://image.prntscr.com/image/iq6SmZC6ReWMM2EY1qtugQ.png
Платы уже почти в производстве, думаю сделать ещё 1 мелкое устройство и заказать сразу оба.
Внешний вид и слои:
Верх (https://image.prntscr.com/image/pWs1-RU7TaC8ZxiazG0dKg.png)
Низ (https://image.prntscr.com/image/ihm8EiGlQ-SrFcP9xrYLGA.png)
Верхний слой (https://image.prntscr.com/image/aNZTnQdqQmqsaGCXz6Ujrg.png)
1-ый внутренний слой (https://image.prntscr.com/image/PJU-Egh4SGmu9Uq5oWeacw.png)
2-ой внутренний слой (https://image.prntscr.com/image/RbHOxTVdRX2DV4RHhe2hOw.png)
Нижний слой (https://image.prntscr.com/image/x9jnVvaoQpKRBwrgPYI8ew.png)
Тов. Black Cat что-то хотел поменять, но уже поздно - платы в производстве, подготовка была сегодня утром. Уже готовятся листы промежуточных слоёв, как понял:
https://image.prntscr.com/image/O3CfCM77RjymmCjRKQxcJw.png
- - - Добавлено - - -
Самое долгое - ожидание доставки потом. Заодно закажу мелочёвку всю для 20 экземпляров сразу, придёт примерно одновременно.
Платы готовы и уже в пути - RF537125679SG (https://t.17track.net/en#nums=RF537125679SG)
Детали уже так же частично в пути.
По плате уже пара замечаний найдено, но не столь критично, для большинства применений и этого достаточно будет.
SoftLight
14.04.2018, 13:17
На барахолке будут? )
Как соберу хотя бы 1, там и посмотрим. МК у меня на пару штук есть в наличии, остальное надо докупать с деталями, если всё будет работать нормально.
Всё покажет тестирование и отладка на реальном железе.
PS: В режиме "MATRIX" контроллер можно будет подключить вместо ATMEGA на платке для PS/2 клавиатуры - ведь там и так все выводы матрицы клавиатуры присутствуют. Надо только провода правильно припаять.
HighLander
14.04.2018, 23:21
Вопрос: Есть беспроводной комплект от A4tech, клава + мыша, но один момент, мышь определяется как мышь и клава, в итоге комп видит мышь и две клавы (на мыше доп кнопка которая выдает дикую последовательность клавиш клавиатуры, которая открывает браузер и страницу с дровами, а если дрова стоят, то они ее заменяют на то что назначишь), так вот, как на это отреагирует контроллер?
PS: Я в очередь за девайсом
PPS: Было бы неплохо реализовать функционал ZXMC2, как минимум в части своих раскладок, клавиатурных скриптов...
Вопрос: Есть беспроводной комплект от A4tech, клава + мыша, но один момент, мышь определяется как мышь и клава, в итоге комп видит мышь и две клавы (на мыше доп кнопка которая выдает дикую последовательность клавиш клавиатуры, которая открывает браузер и страницу с дровами, а если дрова стоят, то они ее заменяют на то что назначишь), так вот, как на это отреагирует контроллер?
PS: Я в очередь за девайсом
PPS: Было бы неплохо реализовать функционал ZXMC2, как минимум в части своих раскладок, клавиатурных скриптов...
1) Надо смотреть по факту и думать. А так - если не нажимать эти кнопки, то и конфликта, по идее, не будет. Каждая HID-клавиатура пишет данные в общий массив нажатых клавиш, который в дальнейшем интерпретируется в зависимости от выхода.
2) ZXMC2 - не исключено, что будет. Одна проблема - конфигурирование через USB будет невозможным в текущей конфигурации. Разве что один из переключателей завести на эдакий BootConfig-флаг, при активации которого будет загружена процедура с инициализацией USB-Device и прочим барахлом для этого. В любом случае - это вопрос чисто софтверный и решаемый, в принципе. Из аппаратных условия - необходимо будет добавить подтяжку одной линии USB к питанию транзисторным ключом, для переключения между USB-Host и USB-Device. Те же часы подключить не проблема - внутренние использовать не так надёжно, а внешние вешаются на I2C, выведенный уже.
По проекту - после выхода на связь тов. BlackCat, всё переросло до ZXMC-3, что сейчас с ним и обсуждаем активно.
Плюсы:
* Стандартный функционал ZXMC-2 сохранится полностью, с некоторыми изменениями (по части настроек и т.п.);
* Поддерживаемые функции значительно расширятся - это ещё в процессе обсуждения.
Минусы:
* Придется добавлять CPLD для организации быстрого реагирования на состояния шины - там будут адресные дешифраторы и обработка прерываний с формированием прерываний для STM32 при необходимости.
PS: Почти все детали для сборки опытного образца для отладки основных нюансов уже пришли, жду самих плат. Жаль, что их придётся списывать в утиль сразу же - под новую версию они никак не подходят. Да и с CPLD на борту плата увеличится, так что буду умещать всё в 2 слоя (а не в 4, как сейчас, ради компактности).
Платы текущей версии получены (https://yadi.sk/i/jty-IisC3Vtc7j). Сегодня начну собирать тестовый образец.
Проверять буду на "Байт"е, других спеков рабочих прямо сейчас нет :)
И вот, спустя вечер один экземпляр собран, завтра буду проверять корректность монтажа на стенде.
Фото 1 (https://yadi.sk/i/vTIvYmce3Vu7rU)
Фото 2 (https://yadi.sk/i/J92LpBD43Vu7tB)
ПО мелочи - остался стабилизатор на 3.3В и суппрессор для USB. Оба ещё идут, но можно запускать и без них.
Специально для самых нетерпеливых - текущий вариант будет продаваться и в текущем виде, "как есть". Если, конечно, не будет сильно серьёзных аппаратных косяков.
А для тех, кому не сложно потерпеть поболее - сейчас на стадии обсуждения концепт ZXMC-3. Там будет то же самое железо + CPLD, в которую будет вынесена вся дешифрация портов для работы устройства без торможения компьютера.
На данный момент очень плотно занимаюсь софтом - ушел от стандартного фреймворка ST, допиливаю библиотеки для данной серии МК.
Первые тесты на рабочей плате:
https://image.prntscr.com/image/tWWOSgIZSz2_8C3C2J5HXQ.png
Уже есть автообновление прошивки с USB-флешки с проверкой контрольных сумм. Осталось ещё сделать автопроверку версий, что бы не приходилось удалять прочитанный файл - иначе при каждом запуске будет перепрошиваться без перерыва.
Так же с редкими (очень редкими) USB-устройствами определение происходит очень редко - у меня как раз такой "свисток" от комплекта клавиатура+мышь, на нём и буду тестировать проблемы :)
Для подключения к какой-либо шине надо будет ещё переходник сваять как-то...
Итак, надо же периодически что-то писать :)
Пока что очень плотно занимаемся прошивкой CPLD (https://github.com/andreili/USB-Keyboard/commit/5f1748cfa0d8991ac013394295547343da12e4e7), за 2 дня вот сделал её предварительную версию и составил тесты. Сразу же вылезли косяки теоретической части, которые будут исправляться после вдумчивого пыхтения над бумажками :) Надо как-то оптимизировать получение 8-битного вектора прерывания с минимальными затратами логики - свободных ячеек достаточно мало.
Клавиатура и джойстики будут полностью безвейтовыми - их состояние хранится в CPLD, периодически обновляемые микроконтроллером. Всё остальное будет тормозить процессор на время обработки запроса. К сожалению, обойти это без применения "жирных" ПЛИС не получится - время до первой реакции МК на прерывание будет не ранее, чем через 200нс. А по факту (с учётом обработки параметров и выдачи сигналов на выход) - до 500нс.
HighLander
24.06.2018, 13:59
andreil, если возможно вместо usb разъема поставить гребенку как на материнках, чтобы можно было выводить в любое место корпуса, используя штатные планки или фронтальные разъемы корпуса.
andreil, если возможно вместо usb разъема поставить гребенку как на материнках, чтобы можно было выводить в любое место корпуса, используя штатные планки или фронтальные разъемы корпуса.
Только если отдельно разводить разъём - дополнительные контакты под сдвоенным USB не умещаются никак.
PS: Во вторник у BYTEMAN'a возьму клона Специалиста - буду на нём проверять режим эмуляции ВВ55, как единственный имеющий право на жизнь в текущем варианте (без ожиданий и прочего, ест). Для подключения вместо матрицы имеющейся клавиатуры такой вариант, к сожалению, не пригоден полностью - не тот принцип опроса USB-клавиатуры, что бы успеть отреагировать на изменения шины =/
Вторая ревизия делается на CPLD, как уже писалось выше. И там будет куда больше возможностей.
OrionExt
09.07.2018, 18:15
Куда девали мой бред о эмульгировании клав? Может, кому полезен будет, да и мне интересно почитать. Модераторы проказники.
Таки вернусь к простым вещам. Короче восемь бит на считывание, 4 бита на прогонку строк. раз
И два. Интересна тема в виде когда-то популярных клав. Меняем только маленькую платку в клаве. И возможности можно в разы расширить.
- - - Добавлено - - -
Это ведь просто реализуемо. А стм64 и спартаны 6 – это капец:v2_jawdr:
OrionExt,Может "эмулировании"? И что там эмулировать, кроме матрицы?
Девайс в минимуме будет эмулировать "тупую" матричную клавиатуру до 12*12. Конкретно сейчас думаю сделать на имеющемся экземпляре замену клавиатурам на ВВ55, как писал выше.
HighLander
12.07.2018, 07:21
Кстати, только сейчас обратил внимание, на плате разъем zx-bus, а не расматривается вариант подключения как zx multi card, ламели на плате? Тем более анонсировано развитие проекта как zxmc3?
Кстати, только сейчас обратил внимание, на плате разъем zx-bus, а не расматривается вариант подключения как zx multi card, ламели на плате? Тем более анонсировано развитие проекта как zxmc3?
Всё возможно. На данный момент нет времени особо заниматься многими проектами, поэтому данный пока на паузе - у нас тут пуско-наладка завода...
HighLander
27.09.2018, 10:40
Всё возможно. На данный момент нет времени особо заниматься многими проектами, поэтому данный пока на паузе - у нас тут пуско-наладка завода...
Апну, интересно как дело движется...
CodeMaster
27.09.2018, 11:33
Апну, интересно как дело движется...
Завод за два месяца не запускается, апай следующим летом ;-)
Можно готовый девайс купить? Поддержка usb клавиатуры и мыши будет с передачей на разъемы ps/2?
...просто скромно напомню о контроллере USB/AT/PS2 клавиатур в ASCII, https://zx-pk.ru/threads/29901-(usb-at)ps-2-ascii-adapter-na-pic16f684.html Проект открыт, можете использовать и переделывать как угодно. Вот с подключением мыши не заморачивался, так что вы как-нить сами ;)
Powered by vBulletin® Version 4.2.5 Copyright © 2026 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot