Под STM32 надо ещё написать код соответствующий или хотя бы портировать конвертер от Hasu, а тут есть готовый и удобный Soarer's Converter.
P.S. Blue Pill умер (в том смысле, что геморрой от возник с китайскими клонами STM не стоит 50 р), да здравствует Blue Pill Plus от WeAct.
Это халтура. Для настоящей реставрации F XT (как и других F) нужно проверить направляющие клавиш (чёрные пластиковые модули) на люфт. Скорее всего, он будет запредельным из-за того, что уплотнитель, проложенный между направляющими и верхней пластиной, превратился в кашу. Нужно вскрыть «бутерброд», разобрать все, направляющие отмыть, зачистить полностью и покрасить верхнюю пластину, нарезать новый уплотнитель из фоамирана.
Задача подключения XT-клавиатуры в USB решается за $4 (стоимость Pro Micro), а не за $55.
Полгода пользуюсь. Начитался о проблемах с беспроводным, поэтому взял проводной. Но удобен он стал только с наклонной подставкой, модель есть на Thingverse.
Неплохо, но можно было бы проще. С привязкой к QMK терминология выглядит так:
Matrix — матрица клавиш, ряды и колонки. На неиспользуемые позиции в матрице вставляем KC_NO.
Layout — физическая раскладка. Определяет, где физически на клавиатуре расположены клавиши из матрицы. По физической раскладке мы можем узнать, например, что клавиши в верхнем левом углу подключена к 3-му ряду и 6-й колонке.
Keymap — логическая раскладка. Описывает, какие сканкоды выдают клавиши из физической раскладки.
Именно по этой причине хорошая рекомендация при проектировании рейда — это не делать его на дисках одной модели или как минимум не брать все из одной производственной партии.
Красивая рекомендация. Жаль, что никто из производителей СХД и RAID-контроллеров про неё не знает, а инженеры Adaptec и Broadcom (ранее LSI/Avago) дают противоположные рекомендации.
Чтобы заново не писать, продублирую свой комментарий к другому посту о RAID из SSD:
По моим наблюдениям (статистика обращений по гарантии и техподдержке почти за 10 лет, серверы и СХД) все эти опасения насчёт одновременного выхода из строя являются чем-то вроде старой городской страшилки. Это было с HDD и доходило до рекомендаций ставить в большие массивы диски непременно 3–4 разных моделей и от разных вендоров (!). Определённые основания такой фобии есть, они связаны с массовым отказом определённой моделей. Но, во-первых, последний очень громкий и действительно массовый случай был с Барракудами 7200.11 и это было 10 лет назад, во-вторых — не надо под серьёзный production собирать массивы из бытовых дисков, и в-третьих — не надо забывать про аксиому «RAID ≠ бэкап».
Видимо с годами эта фобия перекочевала на SSD, но тут на практике вообще ничего не подтверждается. Да, SSD мрут, в том числе и серверные, и любых вендоров/моделей (есть обширная статистика Intel, Micron, Samsung, HGST, Toshiba), но за 10 лет я ни разу не наблюдал этого мифического случая «одновременного износа».
Отметим, что через mdadm нельзя собирать массивы на VROC (собранные массивы будут Linux SW RAID)
Это не так, см. документацию. Проверял на CentOS 8, последнем Debian и Arch — работает.
Несмотря на маскировку под SAS-накопители, массивы с NVMe будут работать на скорости PCIe
Не совсем. Контроллер работает с NVMe-накопителями, но потом презентует массив, как SAS (SCSI) устройство. В результате теряются все прелести протокола NVMe: оптимизированный набор команд, работа с очередями и т.д. В синтетических тестах с парой накопителей я наблюдал на контроллерах Broadcom задержку выше на 15—20% и нагрузку на процессор примерно на 10%.
Полученным в статье результатам доверять не очень стоит, т.к. при тестировании стоило учесть следующие вещи (см. рекомендации в SNIA PTS):
Preconditioning
NUMA. Контроллер PCIe у нас живёт в процессоре, а их в данном случае два
Убедиться в стабильности результатов. Вместо одного раунда в 5 минут стоило провести десяток по 30–60 секунд, посмотреть на отклонение.
Помимо IOPS стоит обратить внимание на задержку (и её распределение) и нагрузку на процессор
Зимой перешёл с Kensington Orbit Scroll на Elecom Huge. Поначалу всё было хорошо, но через месяц начало ныть запястье, с чем я уже давно не сталкивался после отказа от обычных мышей. Помогла 3D-печатная подставка с наклоном, сразу +50 к комфорту.
Если мы говорим о QMK (Ergodox EZ работает на QMK), то ввод юникода там опирается на ОС. Никакой магии не происходит, клавиатура по-прежнему отправляет последовательности стандартных сканкодов, которые ОС интерпретирует в юникодные символы через Alt+нампад (Windows), Ctrl+Shift+U (Linux) или Compose (все ОС, поддерживающие Compose)
P.S. Меня перешивка STM не напрягает. Компилируется всё практически мгновенно, если это делать не в MSYS2, а в Linux, или в виртуалке с Linux. Шьётся с STM32duino тоже легко: никаких нажатий на reset и переключений джамперов, просто запускаю скрипт и тут же вставляю USB.
Всех перечисленных и себя в первую очередь. Например, у меня весьма приблизительные представления об архитектуре ARM и о работе ChibiOS. Я не разработчик железа и не программист. Прикрутить к ChibiOS поддержку нового устройства или написать с нуля собственную клавиатурную прошивку — для меня задача не то чтобы непосильная, но я просто не вижу необходимости во всё это погружаться, когда настоящие разработчики для таких дилетантов, как я, всё красиво обернули и задокументировали.
Я могу себе представить, что для кого-нибудь другого, находящегося на начальном этапе, столь же тяжело и, возможно, вовсе не нужно разбираться с git, msys и C — нужно быстро через GUI удалённо сгенерировать прошивку под произвольную клавиатурную матрицу и собственную логическую раскладку. Появится необходимость (например, нужно будет сделать правильный сплит или наворотить функционал, недоступный через веб-генератор) копнуть глубже — дилетант соберет QMK из исходников.
Установить среду разработки ардуино и из-под неё прошить предоставленный автором скетч
Зачем автору изобретать велосипед и писать собственную клавиатурную прошивку в рамках задачи «дилетант для дилетантов о сборке собственной клавиатуры», когда есть QMK? Это же не «дилетант для дилетантов об основах программирования МК», а реализовать в одиночку хотя бы малую часть функционала (см. Software Features в документации) будет очень сложно.
Кабель HDMI стоит примерно столько же, сколько и вторая ардуина, а удобство подключения тонким гибким кабелем вместо жесткого HDMI очевидно.
Да кто ж спорит-то. Тут просто дело в том, что веб-генератор не поддерживает такие сплиты или в том, что в самом QMK поддержку сплитов только недавно оформили по-человечески, ещё год назад там сложночитаемый для новичка лес из костылей был.
На неправильное поколение ещё Сократ жаловался 2,5 тысячелетия назад. Совсем не обязательно всё сводить к двум категориям: или ты глубоко погружаешься в предмет и через несколько лет становишься настоящим разработчиком, или у тебя вообще не может быть потребности собрать эту железку.
Цель статьи, насколько я могу судить, заключается в том, чтобы дать возможность дилетанту решить вполне определённую задачу — сделать клавиатуру под себя. Точка. Не изучить досконально в процессе цифровую схемотехнику и программирование микроконтроллеров, а сделать клавиатуру и начать её пользоваться.
Именно для этого предназначены готовые блоки. Зачем нужен онлайн-генератор плейтов, если любой настоящий разработчик напишет соответствующий скрипт для своего CAD за пару часов? Зачем нужен онлайн-генератор прошивок, если QMK можно собрать локально? Зачем вообще нужен QMK, если можно «написать свою прошивку для такой элементарной задачи, как опрос матрицы кнопок и отправки пакета в компьютер можно за неделю совершенно не напрягаясь»? Люди, толком не умеющие готовить, пользуются рецептами для мультиварок. Люди, не умеющие пользоваться ручным фрезером, собирают мебель из Икеи.
P.S. Одноклавишный пример. Полнофункциональный пример из последних: Z150.
Для Blue Pill и других плат на STM32F103C8T6 см. подкаталог bluepill.
Не забудьте про резистор и про то, что на A11 и A12 висит USB.
Загрузчик удобно использовать STM32duino. Несколько видов HID-загрузчиков у меня не заработало почему-то.
BluePill и куча других контроллеров на ARM поддерживается в QMK через ChibiOS. Сейчас там всё красиво обернули, и работать не сложнее, чем с AVR, но с поддержкой сплитов есть определённые ограничения.
Вместо Blue Pill лучше использовать Black Pill (либо сверхдешёвые noname, либо от Robotdyn). Нет проблем с неправильным номиналом резисторов, и не попадались платы на клонах STM.
Вот хоть убейте, но я практически не чувствую разницы между Aliaz и Gateron Silent Brown, кроме веса. А так, конечно, silent-свитчи лучше, чем обычные + кольцо.
Под STM32 надо ещё написать код соответствующий или хотя бы портировать конвертер от Hasu, а тут есть готовый и удобный Soarer's Converter.
P.S. Blue Pill умер (в том смысле, что геморрой от возник с китайскими клонами STM не стоит 50 р), да здравствует Blue Pill Plus от WeAct.
Это халтура. Для настоящей реставрации F XT (как и других F) нужно проверить направляющие клавиш (чёрные пластиковые модули) на люфт. Скорее всего, он будет запредельным из-за того, что уплотнитель, проложенный между направляющими и верхней пластиной, превратился в кашу. Нужно вскрыть «бутерброд», разобрать все, направляющие отмыть, зачистить полностью и покрасить верхнюю пластину, нарезать новый уплотнитель из фоамирана.
Задача подключения XT-клавиатуры в USB решается за $4 (стоимость Pro Micro), а не за $55.
Неплохо, но можно было бы проще. С привязкой к QMK терминология выглядит так:
Позанудствую немного: разместить корень на NVMe ≠ грузиться с NVMe.
Красивая рекомендация. Жаль, что никто из производителей СХД и RAID-контроллеров про неё не знает, а инженеры Adaptec и Broadcom (ранее LSI/Avago) дают противоположные рекомендации.
Чтобы заново не писать, продублирую свой комментарий к другому посту о RAID из SSD:
Это не так, см. документацию. Проверял на CentOS 8, последнем Debian и Arch — работает.
Не совсем. Контроллер работает с NVMe-накопителями, но потом презентует массив, как SAS (SCSI) устройство. В результате теряются все прелести протокола NVMe: оптимизированный набор команд, работа с очередями и т.д. В синтетических тестах с парой накопителей я наблюдал на контроллерах Broadcom задержку выше на 15—20% и нагрузку на процессор примерно на 10%.
Полученным в статье результатам доверять не очень стоит, т.к. при тестировании стоило учесть следующие вещи (см. рекомендации в SNIA PTS):
Фото 2
Всех перечисленных и себя в первую очередь. Например, у меня весьма приблизительные представления об архитектуре ARM и о работе ChibiOS. Я не разработчик железа и не программист. Прикрутить к ChibiOS поддержку нового устройства или написать с нуля собственную клавиатурную прошивку — для меня задача не то чтобы непосильная, но я просто не вижу необходимости во всё это погружаться, когда настоящие разработчики для таких дилетантов, как я, всё красиво обернули и задокументировали.
Я могу себе представить, что для кого-нибудь другого, находящегося на начальном этапе, столь же тяжело и, возможно, вовсе не нужно разбираться с git, msys и C — нужно быстро через GUI удалённо сгенерировать прошивку под произвольную клавиатурную матрицу и собственную логическую раскладку. Появится необходимость (например, нужно будет сделать правильный сплит или наворотить функционал, недоступный через веб-генератор) копнуть глубже — дилетант соберет QMK из исходников.
Зачем автору изобретать велосипед и писать собственную клавиатурную прошивку в рамках задачи «дилетант для дилетантов о сборке собственной клавиатуры», когда есть QMK? Это же не «дилетант для дилетантов об основах программирования МК», а реализовать в одиночку хотя бы малую часть функционала (см. Software Features в документации) будет очень сложно.
Да кто ж спорит-то. Тут просто дело в том, что веб-генератор не поддерживает такие сплиты или в том, что в самом QMK поддержку сплитов только недавно оформили по-человечески, ещё год назад там сложночитаемый для новичка лес из костылей был.
На неправильное поколение ещё Сократ жаловался 2,5 тысячелетия назад. Совсем не обязательно всё сводить к двум категориям: или ты глубоко погружаешься в предмет и через несколько лет становишься настоящим разработчиком, или у тебя вообще не может быть потребности собрать эту железку.
Цель статьи, насколько я могу судить, заключается в том, чтобы дать возможность дилетанту решить вполне определённую задачу — сделать клавиатуру под себя. Точка. Не изучить досконально в процессе цифровую схемотехнику и программирование микроконтроллеров, а сделать клавиатуру и начать её пользоваться.
Именно для этого предназначены готовые блоки. Зачем нужен онлайн-генератор плейтов, если любой настоящий разработчик напишет соответствующий скрипт для своего CAD за пару часов? Зачем нужен онлайн-генератор прошивок, если QMK можно собрать локально? Зачем вообще нужен QMK, если можно «написать свою прошивку для такой элементарной задачи, как опрос матрицы кнопок и отправки пакета в компьютер можно за неделю совершенно не напрягаясь»? Люди, толком не умеющие готовить, пользуются рецептами для мультиварок. Люди, не умеющие пользоваться ручным фрезером, собирают мебель из Икеи.
Для Blue Pill и других плат на STM32F103C8T6 см. подкаталог bluepill.
Не забудьте про резистор и про то, что на A11 и A12 висит USB.
Загрузчик удобно использовать STM32duino. Несколько видов HID-загрузчиков у меня не заработало почему-то.
Вместо Blue Pill лучше использовать Black Pill (либо сверхдешёвые noname, либо от Robotdyn). Нет проблем с неправильным номиналом резисторов, и не попадались платы на клонах STM.