Comments 18
Перевод делал явно не схемотехник. Читаешь, слова вроде русские, а смысла нет совсем. Например:
Две клавиши соединены между каждой из шин клавиш и общей шиной

P.S. Можно же было схему сделать кликабельной.
Дескрипторы DMA расписаны неплохо, но 50 восклицательных знаков в тексте, это 50 восклицательных знаков.
16 бит на пиксель тоже не особо заметно. В лучшем случае, палитра на 64 цвета.

В целом, еще раз доказано, что 32 бита с машинным циклом в 1 такт — это мощь.
когда общая шина меняет состояние, а шины данных меняют своё состояние утягивания вверх/вниз, нужно вставить какую-то задержку, чтобы встроенный утягивающий вверх/вниз резистор сменил контракт и установил паразитную ёмкость на нужный уровень. Но мы не хотим ждать!

В таких случаях я делаю проще. У нас уже есть необходимая задержка для устаканивания всех переходных процессов — сам период опроса.
Вы СНАЧАЛА читайте состояние кнопок, потом переключайте шину. Первое чтение скорей всего будет нерелевантным, но шину можно выставить в начале инициализации периферии — пока она пройдёт первое чтение произойдет уже после успокоения всех процессов. А скорей всего можно сделать ещё проще — игнорировать первые нажатия в течении 2-3 кадров после старта.
акцентировали один из самых ужастных участков перевода.
Там паразитная емкость — фемтофарады, даже не пико. Разработчик просто не в курсе про дребезг контактов и способов его лечения.
Увы, пикофарады набираются очень быстро. И если прочитать кнопку сразу после установки уровня на шине чрез пару тактов на 48Мгц то будут проблемы. Я даже так «сенсорную кнопку» изобретать, резистор подтяжки в 500К и без проблем неторопливо можно ловить переходный процесс на тактовой частоте всего в 8Мгц. Причем отличие палец/не палец в 16 единиц из 64. И это простой проводок длиной 5 сантиметров до сенсора. А если на плате, да в соседстве с земляными полигонами, возможно пришлось бы ещё и от помех фильтровать. По расчетам исходя из емкости порядка 10пФ ожидалась задержка в максимум 16 тактов, в реальности на макетке получилось 128 тактов на паразитную ёмкость, если прикинуть это не менее сотни пикофарад.
Там вобщем-то не про дребезг контактов, а про то что нельзя сразу же считать значение на порту и цепи с ним связанные сразу после установки уровня в регистр — силовые транзисторы не такие быстрые, особенно при работе на емкостную нагрузку. А проблема дребезга у них решается автоматом — именно этим самым считыванием один раз за кадр — максимум чем грозит дребезг в момент считывания это то что зарегистрируем нажатие кнопки в следующем цикле. Единственное условие — минимальный период между считываниями не должен быть меньше длительности дребезга кнопки. Что тоже выполняется автоматом и с приличным запасом. Только когда кнопки значительно износятся проблема может стать актуальной, но она решится легко — заменой кнопки.
В электронике — чем ближе земля, либо питание тем меньше помех же. Поэтому все заливается по максимуму землей и питашкой. Скорей всего, у вас была не паразитная емкость, а паразитная индуктивность монтажа и не очень удачной разводки. Лечится обычно резисторами в районе 51 Ома в проходе. Убирает звон, немного задерживает фронт. Чудес от макетки (bread board, поди?) лучше не ждать, хотя они иногда случаются.

Дребезг можно убрать и часиками, т.е. подождать время n после первого импульса (на плохих кнопках доходит до 100мс и это не 1 кадр, между прочим), либо усредняющий фильтр первого порядка (можно и биквад, если хочется).

Когда делается потребительская вещь у нас на работе железячники сразу ставят кнопки типа «ушат». На вопрос, что мол, вам кнопки жалко? Приходит ризонный ответ, что ушат дается чтобы написать софт так, чтобы он работал и на механически подолбаном железе. Ушатанных кнопках и подубитых потенциометрах-энкодерах.
100мс задержка на распознавание кнопки это уже будет заметно и раздражать. Кроме того отсчитывать задержку от нажатия или реагировать на первый фронт а задержку использовать для того чтобы не реагировать повторно на нажатие той же кнопки это неоправданное усложнение программы и сложности с её отладкой. Это стоит делать только в случае когда остро стоит проблема времени реакции на нажатие — т.е. важно быстро среагировать(физическая безопасность, аварийные датчики) но и не зависеть от дребезга.
В конце концов, ушатанные кнопки будут раздражать даже если софт будет работать — уменьшится скорость реакции на нажатия, будут пропускаться какие-то быстрые нажатия и т.п. в любом случае возникнет необходимость поменять их для комфортной работы.
Ушатанные кнопки отличаются от обычных большим дребезгом. Поэтому, тайминги подстраиваются под ушат. Кнопок без дребезга — небывает. Даже самые правильные нет-нет, да и дают 3-7 всплесков. Это самые азы схемотехники.

100 мс — это между повторными опросами, конечно. Так-то реакция на первый спад. Но есть еще двойные клики, долгие нажатия («hold») и т.п., поэтому придется уделить время и написать библиотеку.

Нет неоправданных усложнений программы. Обработка дребезга есть абсолютно в любом продукте. Просто в ПК этим занимается выделенный контроллер клавиатуры, если в какой поделке контроллера нет, то все вешается на основной процессор, как в старых 8-битках и современных девайсах на МК.

Если есть задача, то она решается разными способами. Если она не решена — будет отток пользователей. Да и дребезг — банально.

А так, очень удобно быть любителем и делать вид, что нет дребезга контактов, или АЦП передают нормальный сигнал (а там разброс 4-6 бит — легко, и тоже надо все фильтровать).
Да и пусть даёт кнопка дребезг, ведь не на счетчик аппаратный она заведена. Считываем мы её состояние только один раз на цикл — там никакой определённости нет. Или нажата или нет. А то что она делает импульсы в промежутках между опросами нас не волнует совершенно. Единственный недостаток — время реакции на кнопку варьируется от 0 до периода опроса, но в случае интерфейса с человеком в этом нет никакой проблемы — заметить задержку реакции меньше 40мс смогут единицы.
Опрос по интервалу решает проблему дребезга на корню и простыми средствами. Когда надо регистрировать двойные и длинные нажатия реакцию на кнопку по первому фронту уже не сделаешь, а значит и тут простой опрос по интервалу хуже не сделает но проще чем другие подходы к подавлению дребезга.
У меня когда-то была идея сделать похожее устройство в форм-факторе визитки и толщиной не более 5 мм, чтобы потом раздать друзьям и знакомым. Но увы, мечты разбились о жестокую реальность — даже «малопотребляющие» микроконтроллеры, как и экраны с низким потреблением, на самом деле жрут столько, что источник питания в такое устройство просто не впихнуть.
Тут остаётся только завидовать разработчикам древних игровых устройств типа «Ну погоди», которые имели доступ к волшебной элементной базе, способной полгода(!) жить на двух мелких таблетках. Какой современный ЖК-экран на такое способен? Даже E-ink выжрет их за пару часов, если его надо хотя бы раз в секунду обновлять. Да и микроконтроллеры «сифонят» энергию только в путь.
Любой ЖК экран. А для контроллера надо просто нормально воспользоваться режимом сна и снизить тактовую частоту до 100кГц в моменты когда не нужна высокая производительность. Обычный ЖК экран типа обозреваемого в активном режиме без подсветки потребляет всего 1мА, от таблеток проработает часов 30, теоретически. Остальное определяется частотой обновления и вычислительной мощности задачи. Для такой простой игры как «Ну погоди» тоже можно свести до среднего потребления в 1мА или и того меньше. Главное грамотно распределить задачи и использовать режим сна.
На самом деле тактовую частоту можно уменьшить еще сильнее. На AT91SAM7X мы опускали ее до 500Гц. Этого было достаточно что бы проснуться по прерыванию, поднять частоту до рабочей, обработать ввод пользователя и понизить частоту обратно без видимых задержек.
Ниже не имеет смысла. на 500Гц и на 100кГц потребление отличается незначительно — на таких частотах основное потребление происходит от самого тактового генератора. Причем снижать энергопотребление не даст требование к устойчивости к помехам.
Я делал подобное с питанием от часовой батарейки CR2032, но с маленьким OLED дисплеем, и простым STM32F100C4, а не энергоэффективным аналогом типа STM32Lxx; и флешкой в SOIC8 корпусе.
Оно было способно на 8 мегагерцах без какого либо сна проца проработать 2-3 часа непрерывно присвистывая текст и картинки плавно. Единственная хитрость — включение флешь памяти аппаратным ключом только во время чтения блока, а это всего 1мс из 30мс каждого кадра. А при статичной картинке естественно использовался просто слип (1мА) умные часики показывали неподвижный контент более 5 часов. Такой просто слип потому что олед потреблял заметно больше и оптимизировать не имело смысла. Толщина платы вместе с оледом составляла всего 5мм а часов 8мм что было тоньше айфона тех лет и даже не появился этот дебильный тренд уродовать мобильную технику излишним утоньшением.
Такие часы уверенно конкурировали в Европе наравне с китайскими поделиями до того как в моду пришли полноценные умные часы с полноценной ОС.

Знаете, в некоторых кейсах обычный


__asm("    wfi");

способен скосить от трети до половины электропотребления. Вы действительно радуетесь 2-3 часам, когда в легкую могли сделать 4-5?

что я и делал об этом и написал выше:
А при статичной картинке естественно использовался просто слип (1мА) умные часики показывали неподвижный контент более 5 часов.

просто при плавной прокрутки текста в 30фпс в режиме чтения использовать слипы было бесполезно т.к. проц был задействован близко к 100% постоянно.
и списывать редко когда требуется более 2 часов безостановочно читая текст с экрана, и такого чтоб было два экзамена подряд без возможности зарядки я вообще не слышал так что всё строго по ТЗ и желаниям клиентов.
какой-нибудь stm32g0 и попробовать тактовую 32кГц.
В целом, «ну-погоди» — это автомат с небольшим числом состояний. Наверняка можно раскидать на современной рассыпухе и будет потреблять еще меньше.

А на визитке сейчас модно делать дорожки с USB разъемом.
Only those users with full accounts are able to leave comments. Log in, please.