Опрос кнопок микроконтроллером

[Starichok51]

На ассемблере программа всегда либо ходит по кругу, либо переход между кругами.

открою тебе секрет: на любом языке программа ходит по кругу и по вложенным кругам.

[AlexS4]

но кроме джампов некоторые затейники еще зачемто используют call/ret/reti

c чего бы это?! неумехи ! машинный кот не нюхали! , щас AQ29 научит всех минимализму

а кстати были еще форт процессоры, тож интересная концепция... но и там не идеально круглые AQ29-круги
в какойто ветке про самодельные процы пару лет назад обсуждали.

[Just_Fluffy]

AlexS4, вы еще вспомните про прерывания - то тоже как бы отдельные круги... Но мне как то рассказывали, что прерывания нежелательны - они ж могут и ход программы сломать... И переменную затереть... И источником трудноуловимых глюков быть.... Лучше бегать по кругу, как бессмертный пони.

[AlexS4]

ну да reti этож обычно из прерывания.
ну вот для примера скока их у меня в простейшем коде
~$ grep -i -e callx -e reti -C1 ~/data/devel/lcdconv/lcdconv.S
rjmp main ; 0. reset, ext pin, power-on, brown-out, watchdog
reti ; 1. external interrupt 0
reti ; 2. external interrupt 1
reti ; 3. timer 1 capture event
reti ; 4. timer 1 compare match
reti ; 5. timer 1 overflow
reti ; 6. timer 0 overflow
reti ; 7. uart rx complete
reti ; 8. uart data register empty
reti ; 9. uart tx complete
reti ; a. analog comparator

чтоб ничего не затиралось есть всего 3 варианта: надо либо ничего не портить (не писать), либо сохранять-возвращать то что поришь, либо использовать непересекающиеся наборы обьектов для записи (регистров, массивов итп), для разных задач и разных процессоров оптимальным будет разный подход, 1й вариант обычно неприемлем и соответственно остается комбинация 2го и 3его.
AQ29, это совсем не сложно и совсем не портит эффективность , скорее наоборот

некоторые языки предлагают вообще интересные варианты, как скажем yeld в python
которая позволяет уступить процессор вызвавшему процедуру коду а при следующем вызове функции - продолжить с места где она уступила.
(это по сути поведение которое скрыто от кода делают многозадачные ос на 1 ядре)

разница в языках программирования восновном только в том насколько надо заботиться о доступе к нужным данным, о переключении контекстов для распараллеливаемых задач итп, и соответственно насколько можно влиять на эффективность кода.

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

C - скрывает некую часть работы и позволяет начинающим не знать что m[n] m+sz*n это одно и то же а неначинающим сконцентрироваться на алгоритме не заботясь о множестве мелочей, которые на masm устанешь делать, правда за такой сервис он требует например изучения поведения версий компиляторов с разными O0,1,2 , если хочешь макс эффективности кода


а про forthcpu - вот неплохая статейка , они кстати и в космосе долго летали и в конце прошлого века на них много надежд возлагали
https://habr.com/ru/articles/133338/
вообще forth один из немногих языков в которм возможен почти 0-интерпритатор, тоесть можно писать вполне сложные и читабельные конструкции почти в машинных кодах.

ну собственно макроассемблер позволяет аналогичное делать на обычных cpu но заходит к задаче с другой стороны.

...чета я разболтался, новыйгод-прерывание видимо перекдючило контекст в процессоре

[shonty]

Вы зачем из АСМ-а сюда перебежали? Чтобы теперь в кнопках про ассемблер разговаривать?

[Starichok51]

shonty, всё правильно. кнопки - периферия, а это раздел периферии.

[AlexS4]

а с кнопками вроде все тривиально и давно извесно:

1. статические кнопки (по 1 на 1 gpio)
там их удобно группировать по портам, зачитывать по таймеру порядка 10-30ms прямо группой весь порт,
затем можно отсекать дребезг, фиксируя изменение бита от предыдущего опроса по таймеру и если было изменение а потом нестало меняться - фиксировать переключение.
это тоже удобно делать побитными операциями сразу для всего порта.

зачитываем порт, делаем xor/^ c предыдущим сохраненным и получаем изменившиеся биты (для красоты это хорошо обьединяется со свопом текущего и предыдущего состояний) аналогично храним признаки свежих и зафиксированных изменеий.

затем биты не используеме для кнопок можно отрезать побитовой маской.

затем, например более медленным таймером, обрабатываем зафиксировавшиеся изменения как изменения состояний кнопок
(сбрасываем биты-флаги и запускаем соответствующие процедуры: либо реакции, либо алгоритмов похожих на антидребезговые, которые тоже могут по более медленным таймерам различать команды по длительностям нажатий кнопок и уже потом запускать процедуры реакций.

аппаратно - кнопка на gnd + встроенный pullup - оптимально.


2. динамические кнопки, могут быть
2a. матричными (строчная развертка, реализуется чисто на наборе 2 групп gpio n выходов и m входов и n x m матрицей кнопок с диодами )
2b. со счетчиком+дешифратором или со сдвиговым регистром в этих реализациях нужны 3gpio: 2 выхода RST, C и вход
есть также всякие ухищрения позволяющие обьединить RST+C на 1gpio , или сокращение в 2a. n gpio до log2 n применением аппаратного дешифратора
или например очевидная оптимизация обьединения группы n выходов для развертки клавиатуры и скажем динамического дисплея.

опрос и 2a. и 2b. осуществляется по сути аналогично 1. ,
только опрашивется не gpio порт, а некая переменная, записанная простейшим алгоритмом динамической развертки на основании данных со счетсика выходов и состояния входов.

3. это преобразование сигналов с кнопок в аналоговый сигнал и считывание этого сигнала встроеным или скажем кустарным ADC.

и здесь все тот же подход, но первичные(нестабильные) данные готовит не алгоритм развертки (как в 2.) или сам порт (как в 1.), а алгоритм опроса или симуляции ADC.

[Игорь2111]

Была идея сделать две кнопки + - с помощью двух таймеров один симулятор энкодера другой в энкодер включении. Чисто аппаратно и антидребезг есть. На stm32. Есть смысл?

[Just_Fluffy]

Энкодерный фильтр в СТМках грустный. Новые энкодеры фильтрует, а разболтанные дешевые китайские - уже нет.

[shonty]

У меня дешёвые китайские энкодеры теперь вот и на at90s2313 отлично заходят)) и без всякого антидребезга

[OKF]

[uquote="Starichok51",url="/forum/viewtopic.php?p=4665310#p4665310"]на любом языке программа ходит по кругу и по вложенным кругам.[/uquote]
А могу я просто спать? И кто меня разбудит, того я и обслужу). Безо всяких кругов, не?

[AlexS4]

можно и спать-просыпаться но по сути это тоже будет кругами
круги они везде в природе, еще есть спирали, но они не так долговечны, ...если не промодулированы кругами

[Just_Fluffy]

Поскольку МК - это не исполняемый файл в ОС, программа не должна никогда завершаться. Т.е. основное тело программы (независимо от ЯП) - это должен быть бесконечный цикл ("круг" в терминах гуру).
А уже что в этом цикле делается - зависит от подхода программиста и поставленной задачи.
Это может быть пустой цикл, со SLEEP-ом или без.... И вся работа будет идти в обработчиках прерываний. interrupt-driven, как частный случай event-driven подхода.
Либо какой то опрос в таймерном прерывании всей периферии и генерация событий в очереди задач (либо прямая обработка внутри прерывания)...
Либо большой цикл, привязанный к какому то таймеру (ожидание события таймера - это еще один цикл.. ой, круг) - и в этом цикле уже работа с периферией, опрос асинхронных флагов и реакция на них, программные таймеры и т.д.

Касаемо опроса клавиатуры - лично я предпочитаю его делать в таймерном прерывании (которое заодно пинает основной цикл либо событийные таймеры). Тогда вся обработка нажатий идет спокойно и независимо, будь то матричная клава, отдельные кнопки, АЦП....
Я считаю, что опрос клавиатуры - это уровень работы с железом, а основная программа вообще не должна знать, как у нас подключены кнопки, как там они дребезжат и как их опрашивать.
Основная программа получает событие в очереди либо флаг нажатой кнопки.
Я вообще стараюсь придерживаться модульности в программировании. И по возможности - полной абстракции периферии. Т.е. все, что взаимодействует с периферией МК - оно живет в отдельном файле и в основную программу торчат только интерфейсные функции. Это иногда немножко увеличивает код, но немножко.

[OKF]

Люблю возражать.) А вот нет у меня бесконечного цикла. Стартую с main-а дохожу до sleep и всё. Разбудил кто - начинай с начала, со сброса! От начальной точки и до конечной - ну ведь не круг же, прямая!) А уже после рестарта смотрю кто же это меня потревожил и что с ним делать.

С клавиатурой разницы нет. Что по прерыванию, что без. Всё равно функция обработки присутствует, инициализация присутствует. Разница в том, включаете ли вы обработку в основной цикл, либо она в фоне - в прерывании. Это даже менее красиво и менее структурно, нежели в основном цикле.
ХитрО в Ардуино. Я могу иметь отдельный файл в папке, о котором в основной программе не будет ни слуху - ни духу. Но при сборке он включится в основную программу и будет в ней участвовать.)

[ARV]

Да, программа для МК не обязана иметь бесконечный главный цикл. Делал один микропроект на любимой attiny13, которая просыпалась по ватчдогу т.е. по сбросу от него, и пробегала единственную дорожечку без циклов... Ватчдог срабатывал часто, так что внешне работа была непрерывной

[shonty]

Ватчдог срабатывал часто,..

Типа всё равно "псевдо"цикл

[Jack_A]

Так "засып" - "просып" и есть часть бесконечного цикла. Ну разве что во взрывателях: проснулся - и БАБАХ ! Цикл завершён.

Спойлер

- У меня винчестер сдох.
- Какая была гарантия?
- Пожизненная.
- Ну так всё: сдох - гарантия закончилась. ©

[OKF]

Можно и без бабах. Сделал одно, другое, третье, уснул и не проснулся. Где тут цикл?

[shonty]

OKF, вам вряд ли кто-то возразит.

Циклы возможны только при тактировании.. В вашем же случае тактирование отключено

Добавлено after 4 minutes 21 second:
PS: но если без отключения тактирования, тогда да, от циклов никуда не деться

[ARV]

Не нужно путать цикл вообще и программный цикл. Программный цикл контролируется программой, а вообще абстрактный цикл - неизвестными внешними условиями. Программный цикл содержит программные средства, из-за которых счетчик команд меняется циклически, и всегда можно изменить весь процесс, изменив программу. Изменить ход процесса, зависящего от внешнего сброса невозможно, т.к., например, невозможно программно заставить человека нажать на кнопку.

Ну, вы понели