Да знаю я про спецдрайвера - это вариант разъяснения для задачки melandrа
( https://radiokot.ru/forum/viewtopic.php?f=57&t=161509 ) и иных КОТЯТ - более учебный, чем реально-прикладной.

Не знаю, удастся ли достаточно понятно написать/обосновать...

Да и под СИ у меня опыта маловато, не то, что под ассемблером, где такие заморочки весьма удачно решаются. Тут еще и специфику причин перехода к периферии с мозгами при блочном построении схем из нескольких МК и работе под ЯВУ можно прицепить...
А заодно и немного мозгами пошевелить.

У Чена была хорошая идея использовать для индикации разъем AVR-ISP, он все равно обычно присутствует для прошивки

схема примеры Си, асм тут:
http://elm-chan.org/docs/avr/avrisp.html
можно также использовать для вывода отладочной информации. Можно добавить еще один вывод микроконтроллера и получится 8 кнопок.

Сейчас Ардуинщики и любители вовсю используют 128x64 OLED дисплейчики - их полно на али и в радиокиосках, не дорого

Это опять таки "не кошерно" с точки зрения исходной задачи.

Фокус в том, что изначально идея была именно в простом варианте дисплея.
"4-х позиционный 7-сегментник с совмещенной клавиатурой".
При том, что этот вариант решения не должен мешать иным исполняемым в самоделке задачам.
Под ассемблером такое решение абсолютно реально. Даже с весьма мощным ШИМ автономно по каждой из позиций (тот же проект extdi2313).
Вот каким образом такое под ЯВУ соорудить...

А вот "довести до ума" именно под Си ( или обосновать невыгодность такого решения в случае с ЯВУ) это и есть суть данного тест-задания.

PCBWay - всего $5 за 10 печатных плат, первый заказ для новых клиентов БЕСПЛАТЕН

Сборка печатных плат от $30 + БЕСПЛАТНАЯ доставка по всему миру + трафарет

Онлайн просмотровщик Gerber-файлов от PCBWay + Услуги 3D печати

обосновать у вас не выйдет однозначно, если я буду "научным оппонентом" а вот довести до ума - это, в качестве практики языка Си, вполне посильная задача

Выбираем схему BMS для заряда литий-железофосфатных (LiFePO4) аккумуляторов

Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей.

Подробнее>>

Та ШО там делать! Ещё и куча места останется.)

Новый аккумулятор EVE серии PLM для GSM-трекеров, работающих в жёстких условиях (до -40°С)

Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре. Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.

Подробнее>>

а в чем конкретно проблема?

Деталюги ЖАЛКОО...

Ежли уж с точки зрения оптимальности — лучше используя внутренний R-C генератор освободить под сегменты порт PB.
НО... тогда с «типовой адуриной» нестыковка — надо будет «сторонних разработчиков» использовать, а у меня относительно оных СОМНЕНИЯ гложуть...
Посему пока потеоретизирую относительно самого дисплейчика на основе динамической развертки.
Приму аки должные исходные данные -
сегментные ключи, активный уровень равен логической единице;
позиционные ключи — активный уровень равен логическому нулю.
Для начала без кноп.

Спойлер

Собственно сама идея динамической развертки основана на физиологии глаза сущности вида ХОМО ХАПИЕНС — смена картинок пошустрее, чем 50 раз в секунду вызывает видимость единого изображения.
Ёжли у нас 4 позиции то каждая из оных должна появляться в 4 раза быстрее.
Предпочтительно количество позиций(знакомест) иметь кратным двойке — меньше проблем с математикой относительно наших МК.
Но тут есть гвоздь (ныне не так уж заметный) — лампы накаливания и газосветки — они также на 50 Гц пульсации дают (по крайней мере в постСССР и там, где частота в электросети 50 Гц. Посему забираемся повыше — 60-120 Гц на полный цикл вывода нашего индикатора.
Поскольку ранее МК были не столь шустрыми и с точки зрения “поменьше событий, отвлекающих МК от более важных дел» берем за основу 60 Гц — 0,0166666.... секунды на полную развертку строки индикации. Как-то те «6 в периоде» не есть хорошо — округлим до 0,016 получая в итоге 62,5 Гц на полный кадр.
Делаем буфер отображения размером под количество знакомест (у нас 4) и каждые 0,004 секунды сбрасываем одну из сегментных комбинаций плюс активацию соответствующего оной комбинации позиционного ключа на дисплейчик.
Вроде бы все - «проще не бывает» как обычно заявляют начинаюшши КОТЯТКИ...
Потом … начинают выползать всякопакостны «нюенсы» -
то картинка «дергается, подсвечивается, нестабильна, мерцает»,
то... оказывается МК больше ничего делать не успевает... То ешшо какие матюки «аффтарам идей»...
Разберем ту индикацию более внимательно. Я буду брать за основу «чистый ассемблер» — то, с чем ВСЕГДА можно результат получить. Ну и при возможности чего из средств референса ардуино IDE. Для полноценного повторения алгоритма под «чистым СИ» явно потребуются ассемблерные вставки — а сие уже не моё — может кто из наших КОТОГУРУ подбросит...
Итак...
обзываем:
kadr — одна (или несколько) строк развертки позиций дисплея.
Собственно дисплей может быть и «многострочный»...
line — интервал развертки всех позиций в одной строке дисплея
простейший дисплейчик — однострочный (состоит из N*point)
point – интервал активности одного знакоместа текущей строки развертки.
(набирается из 1 step или N*step).
step - это еще одно «внутреннее деление» - из некоторого количества таких шажков состоит
интервал отображения каждой позиции (зарезервировано под ШИМ алгоритмы).
v_ram — участок в ОЗУ, предназначенный для хранения сегментной комбинации для каждого
из знакомест. Размер определяется количеством позиций ( N*point).
v_ram_tmp — участок ОЗУ, предназначенный для хранения предподготовленных данных,
которые после обнаружения соответствующего запроса будут перегружены в v_ram.
v_flags – байт флагов обеспечения программного автомата.

Это минимум для начала. Далее будем к оным возвращаться.
Собственно такое построение делается для независимости обработчика дисплея(дисплея/клавиатуры) от течения основной программы в МК.
Ну и базовый момент всей идеи АППАРАТНЫЙ ТАЙМЕР...
(Или источник независимых (асинхронных) от основной программы аппаратных прерываний).
Основные минимальные требования к которому:
1. разрядность, обеспечивающая наши потребности;
2. наличие автоперезагрузки заранее заданным коэффициентом деления;
3. наличие аппаратного прерывания минимум по переполнению.
Тут появилась необходимость в константе досчета (tim_step) одиночного цикла таймера.
Однако это при «линейном» (или ШИМ) варианте. Если за основу берется BAM — там несколько иное распределение будет.

Примитив — алгоритм развертки одной строки:
Читаем текущее значение сегментов в порт вывода сегментов;
Активируем текущий сегментный ключ порта позиционных ключей;
Ждем интервал (у нас 0,004S) свечения текущего знакоместа;
Декрементируем (или инкрементируем) и проверяем на исчерпание счетчик позиций -
если не исчерпан — повтор от начала,
если исчерпан — перезагрузка счетчика и повтор от начала...
Добавилися
v_point_cnt – счетчик позиций дисплейчика (пока он считает step - интервалы)
Однако светится-то ОДНО знакоместо....
Надо добавить:
v_ram_ptr – указатель начального адреса видеопамяти
и... как-то определиться с активацией соответствующего позиционного ключа и адреса сегментных данных в видеопамяти...
В зависимости от имеющегося набора команд и функций компилятора решение может варьироваться.
Однако наиболее удачно использование для указания адреса сегментного кода содержимого указателя
v_ram_ptr + смещение равное текущему содержимому счетчика позиций v_point_cnt.
Но тут ужшш...
Проще всего автоинкремент указателя — но там в конце цикла потребуется его перезагрузка константой.
Ежли счетчик декрементный — возможны проблемы с направлением вывода (слева направо или справа налево — что также заслуживает отдельного рассмотрения).
Альтернатива — вводим дополнительный байтик в ОЗУ с указателем смещения
v_point_ptr и инкрементируем/декрементируем как пожелаем. Ну и про его начальное значение не забываем в таком случае.

Далее вопрос про активацию дисплейного ключа...
Да наиболее универсальную и быструю.
Для таковой создаем байтик буфера
v_point_keyptr – собственно регистр или ячейка в ОЗУ
и начальную маску из бинарного кода B11111110 (или 01111111)
v_point_keymask
Для упрощения считаем, что и сегментный (v_seg_port) и позиционный (v_point_port) порты только нашим дисплеем и занимаются и настроены на вывод данных. Для усложнений относительно разнонастроенного порта, обслуживающего позиционные ключи позднее можно будет добавку дописать.

В итоге алгоритм несколько видоизменяется:
hard_init:
загружаем начальные значения в
v_point_cnt = N - количество позиций (режим предвывода с последующим декрементом
счетчика)
v_point_keyptr = v_point_keymask
v_ram_ptr = адрес метки начала массива v_ram

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

а программа обработки прерывания получает вид:
irq_displey:
v_seg_port = содержимому ячейки с адресом v_ram_ptr + v_point_cnt - загрузка
сегментного кода в сегментный порт
(или более упрощенный постинкремент/постдекремент указателя после
текущей загрузки)
v_point_port = содержимому v_point_keyptr - загрузка позиционного кода в
позиционный порт
Текущая позиция дисплея активирована
далее делаем обработку счетчика позиций
v_point_cnt = v_point_cnt — 1 (можно и версию «инкремента до совпадения» - но то
зависит от специфики команд ядра — например у ПИКовых таковое имеется)
если счетчик не исчерпан -
v_point_keyptr = v_point_keyptr сдвинутое влево/вправо — при условии, что это простой кольцевой сдвиг (ассемблер), если это СИ помним, что двигаем 0 в массиве окружающих единиц! Направление сдвига определяем выбранным направлением развертки дисплея и согласуем с выборкой/размещением данных в v_ram.
reti - выход из обработчика прерывания.
Если счетчик исчерпан -
v_point_cnt = N (исходному значению)
v_point_keyptr = v_point_keymask (исходному значению)
(если использовалось инкрементирование/декрементирование указателя начала массива видеопамяти v_ram_ptr то его также придется перезагружать исходным значением).
reti - выход из обработчика прерывания.

Вроде... работает...
Но как-то не комфортно...
Паразитная «ПОДСВЕТКА» в тех местах, где сегменты неактивны.
Особо действует на нерву/становится заметной ежли активны (высвечены) не все позиции на нашем дисплейчике.

ЗАСАДКА...
Дело в том, что смена комбинации сегменты/позиция происходит еще в старой позиции дисплея. А тут минимум несколько команд. Добавим еще и интервал времени на распространение сигнала как в сегментных так и в позиционных ключах. Оный надо высчитывать в каждом конкретном случае по даташитам применяемых внешних элементов. Да длину шлейфов... МНДЯаа...
Определяем таковой интервад по максимальной задержке распространения в самых медленных из имеющегося в схеме — оптронах типа 4N33 как 100 микросекунд...
Добавим на всяк случай еще микросекунд с 50... итогом «темная область» 150 микросекунд от сигнала «все выключено» или по сегментам или по позициям перед последующей сменой активных данных является ОБЯЗАТЕЛЬНЫМ дополнением для любого светодиодного индикатора на основе динамической развертки.
Вот только … Вставлять такой цикл задержки в само прерывание... Это уж слишком затратное по ресурсам МК дело.
Хотя... В такой ситуации для нашего предыдущего алгоритма добавим
v_cnt_mrak – счетчик циклов задержки (обычно 1 одноцикловая команда =1мкС)
v_mrak – собственно константа.
Можно и по другому — главное смысл —
сгенерировать задержку в 100-150 микросекунд.
А также добавляем константу
v_blank равную пассивному коду то-ли для позиционных ключей, то-ли для сегментных.
Для сегментных вроде удобнее, для позиционных — простое инверсное состояние к тому, что ранее было выведено или «общая заглушка».
Тогда вариант предшествующей тест-прожки будет иметь вид:

hard_init:
загружаем начальные значения в
v_point_cnt = N - количество позиций (режим предвывода с последующим декрементом
счетчика)
v_point_keyptr = v_point_keymask
v_ram_ptr = адрес начала массива v_ram

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

irq_displey:
v_point_port = v_blank гашение по позиционным ключам
v_cnt_mrak=v_mrak

timm:
v_cnt_mrak=v_cnt_mrak-1
v_cnt_mrak=0?
Если нет — повтор от timm отработать задержку времени

v_seg_port = содержимому ячейки с адресом v_ram_ptr + v_point_cnt - загрузка
сегментного кода в сегментный порт
(или более упрощенный постинкремент/постдекремент указателя после
текущей загрузки)
v_point_port = содержимому v_point_keyptr - загрузка позиционного кода в
позиционный порт
Текущая позиция активирована
далее делаем обработку счетчика позиций
v_point_cnt = v_point_cnt — 1 (можно и версию «инкремента до совпадения» - но то
зависит от специфики оманд ядра — например у ПИКовых таковое имеется)
если счетчик не исчерпан -
v_point_keyptr = v_point_keyptr сдвинутое влево/вправо — при условии, что это простой кольцевой сдвиг (ассемблер), если это СИ помним, что двигаем 0 в массиве окружающих единиц! Направление сдвига определяем выбранным направлением развертки дисплея и согласуем с выборкой/размещением данных в v_ram.
reti - выход из обработчика прерывания.
Если счетчик исчерпан -
v_point_cnt = N (исходному значению)
v_point_keyptr = v_point_keymask (исходному значению)
(если использовалось инкрементирование/декрементирование указателя начала массива видеопамяти v_ram_ptr то его также придется перпзагружать исходным значением).
reti - выход из обработчика прерывания.

Ну индикация фиксированного содержимого из буфера получилась.
Теперь бы добавить изменения в то сообщение. Да так, чтоб не было «нежданчиков» - ситуаций, когда замена содержимого попадает в произвольное место всей строки...
Уж больно неприятно такие относительно редкие моменты попадаются. Ощущения от них...
ФЕЕЕЭЭЭ....
Причина довольно банальна — часть строчки глаз запомнил от старого варианта, а часть пошла новая. Это при некоторых обстоятельствах приводит к ощущению «ярких вспышек» в произвольных точках дисплея и иным весьма неприятным ощущениям, портящим впечатление от работы индикатора.

Для того, чтоб подобное не происходило, замена данных (и/или их предварительная подготовка) производится независимо от работы программы обеспечения регенерации дисплея в отдельном буфере данных (v_ram_tmp), а замена содержимого буфера отображения (v_ram ) на новое производится перед началом следующего цикла развертки сканера строк дисплея.
При этом используется флаг запроса обновления данных (он же является флагом запрета работы основной программы с содержимым v_ram_tmp на время перезагрузки данных).
Программа основного задания подготавливает новые данные (сегментные коды) и устанавливает активный флаг
v_flags_quest (из регистра флагов v_flags).
По заверщении цикла обработки строки программа регенерации дополнительно опрашивает статус v_flags_quest.
Если обнаруживается, что
v_flags_quest = 1 (true)
производится перегрузка данных из
v_ram_tmp
в
v_ram
по завершении которой программа обработки/регенерации дисплея сбрасывает
v_flags_quest = 0 (false)
и выходит из прерывания.

В принципе вполне работоспособный вариант.

В некоторых случаях можно тем и ограничиться и перейти к блоку «побочного эффекта» - обработчика клавиатуры.
Однако «по максимуму» лишние фрагменты разной длины в прерывании — штука весьма нежелательная.
Под ассемблером та проблема легко решается «условным возвратом» из прерывания через подстановку
адреса дополнительных фрагментов через стек с последующим reti.
По завершении «хвоста» командой ret проводится возврат в точку вызова прерывания по таймеру.
А вот как такой фокус без ассемблерных вставок в СИ соорудить?
Да еще не вникая в глубь специфики Сишного аппаратного стека?
Тем более, что в приличном модуле обработчика такие приемы есть жизненная необходимость на каждом шаге вывода позиции.
Иногда и по несколько раз за интервал отображения одной из позиций.
Ибо по условному возврату из прерывания разрешается работа других используемых основной программой прерываний при том, что «служебные хвосты» обработчика дисплея/клавиатуры могут достигать до половины тайм-аута индикации одной позиции дисплея.
Второй ГВОЗДЬ в отношении Сишного варианта -
В подобных алгоритмах практически всегда используются жестко определенные инлайновые таблицы в ПЗУ.
Это или готовые вектора переходов или поля указателей векторов/смещений по отношению к базовым указателям.
Работать в подобном режиме при помощи PROGMEM практически невозможно (см. ранее опубликованную «капельку дегтю»).
Третье касается только ардуиноIDE, но весьма существенно для «любителей плотной упаковки» с максимальным
использованием аппаратных ресурсов МК.
В самой IDE (описано в референсе) определен ряд функций, использующих аппаратные ресурсы — это и внутренний системный таймер и иные добавки, явно использующие аппаратные блоки — тот же вывод analogWrite() - PWM к примеру...
А описания всех таких моментов в отдельном виде не предоставлено — приходится по крупинкам собирать в разных источниках.
Вот и получается — полноценную прикладную программу с максимальным использованием аппаратных ресурсов и особенностей малолапых МК можно относительно легко написать только под «чистым ассемблером». А в более сложных случаях предпочтение комбинированному проектированию с использованием прикладных простых периферийных блоков и центрального МК «абстрактной обработки».

Ладно... влезать в глубины опционов компилятора и ассемблерных вставок не слишком хочется, а результат хош и «не очень» получить желаем...
Тогда есть еще один вариант...

Используем ту же динамическую развертку, но с dark_point - «темным/теневым позиционным фрагментом».
Собственно закладываем в цикл развертки отдельный участок, который занят не индикацией, а обработкой служебных подпрограмм самого дисплея.
Для наблюдателя это будет выражаться в некоторой потере яркости равноценной тому же дисплею с увеличенным количеством знакомест.
При том, что сам dark_point по длительности может быть равен паре обычных знакомест.
Тут главное не протупить с максимальной длительностью служебных подпрограмм, которые в том темном/теневом участке выполняться будут — предпочтительно не более ¾ его длительности. Зато можно уже вместо таблиц векторов вычислительные алгоритмы поставить будет.
Примерно так:
Планируем 4-х позиционку, добавляем еще два шага
итогом = 6 позиционный дисплей НО только с 4-мя действительными знакоместами.
0,016/6 = ~0,0026S примерно 64 Гц...
И в том дисплейчике у нас два служебных окна (или одно цельное — как работу прерываний по таймеру организовать).
А это уже минимум 2000 однотактовых команд (при 0,000001S на такт/команду) для математики и обработки...
Плюс такого алгоритма — используется только прерывание по таймеру и математика.
Минус — на время «темных дыр» работа иных прерываний запрещена — что соответственно вводит свои ограничения относительно основной программы устройства.
(Хотя... алгоритм на аппаратной начинке АВРкина Т1 мне гораздо приятнее как по возможностям, так и по ощущениям от его работы).

В связи с вышеизложенными размышлениями вероятнее всего под имеющиеся условия лучше подойдет версия с «теневым» обработчиком. Вроде у адуринок имеется библиотечка timer own... надо над тем дополнительно поразмышлять...

кто вам такое сказал?!
по-моему, вы просто абсолютно не представлете, что такое Си. мне кажется, вы болеете ассемблером в особо тжелой форме, вам срочно надо принять пару проектов Си, чтобы улучшить состояние
в случае, когда вы не заняты разработкой ОСРВ, вам такие форкусы не потребуются. более того, за подобные фокусы обычно в Си принято канделябром...
вообще не понял, о чем тут речь... но, если вы не на тини13 работаете, почти всегда не представляет никаких проблем сделать "таблицу векторов" в своей программе в ОЗУ...
имхо, надо поразмышлять о целях и средствах. ардуино - это С++ и большое количество заранее наработанных библиотек, ориентированных на определенный набор вариантов схемотехники. Си - это си, и с библиотеками, кроме libc, там ничего не "стандартно", сплошная свобода. ассемблер - это вообще третье.

для чего на ардуино насаживать Си - не понятно
для чего скрещивать С++ от ардуины и чистый Си - не понятно
для чего постоянно проводить параллели с ассемблером - не понятно

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

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

Чего уж так сразу и "операционная система"?
Просто привычно использовать совмещенный самостоятельно работающий дисплейчик на своей самоделке.
(В едином кристалле).
А то, что оный сам-по-себе вертится как-то даже удобнее.
Соорудил и забыл - только обмен через буфер данных - аналогично как и с СБИС внешнего индикатора.
И... НИКАКИХ ОСРВ.

Другой вопрос как аналогия под имеющимися ресурсами СИ выглядеть будет.
Прямого варианта похоже нету - соответственно сам алгоритм должен видоизменяться.
Не делать же ОСРВ ради простейшего параллельно и независимо работающего индикатора!

Столько слов, столько разговоров... Уже б за это время можно было бы и Си изучить, и напрактиковаться вволю.( А мы всё о возвышенном.)

а то, что только при разработке ОС приемлемо использование ассемблерных вставок со всякими "хитрыми" манипуляциями вроде ret не по адресу, который был помещен в стек, а по замененному в стеке адресу. может, я вас не правильно понял, но показалось, что вы приделожили извращаться именно подобным образом...

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

Доброй ночи! Присоединюсь к дискуссии, так как от моей темы пошел разговор. Задача стояла модернизировать код на Си таким образом, чтобы его было возможно сопровождать через несколько лет и понять принцип построения программ с использованием меню, в частности на 7-сегментном индикаторе. Сама индикация вопросов не вызывала, разве что немного неэффективно использовалась библиотека. Роман подсказал, в каком направлении нужно работать, чтобы оптимизировать вывод на индикатор пунктов меню и времени, с возможностью редактирования. Обработка кнопок также реализована через библиотеку. С ней вопросов не возникает. И самое основное, очень не понравился мне код обработки меню. То есть при нажатии кнопок должна меняться информация на индикаторе и редактироваться параметры, при активации режима редактирования. Сам алгоритм я придумывал сам, и понимаю, что он сделан лишь бы работало, а не с возможностью использования в других проектах.

Хороший пример меню от автора библиотеки LUFA Dean Camera:
https://github.com/abcminiuser/micromenu-v2
на Радиокоте тема обсуждалась:
https://radiokot.ru/forum/viewtopic.php?f=57&t=114775

Ну пока еще до меню далековато.

Собственно разговор про исполнение обработчика прерываний.
То, что положил ARV это простейший вариант. Да еще без паузы на задержку распространения.
Но суть даже не в том...
Собственно у АВРок нет истинного приоритетного контроллера прерываний (так как допустим у всем известной mcs51 и в некоторых иных семействах).
Т.е. пока исполняется модуль прерывания все кроме оного приостановлено.
А это не есть хорошо. Допустим тот же системный таймер уже примораживается (или еще какой процесс на основе аппаратной начинки).
Разрешение вложенных прерываний есть великая морока.
А вот вариант короткой преамбулы с условным возвратом на дополнительный "хвост" обработчика уже не закрытый для иных прерываний весьма полезная штука. И вклинивает обработку в любом произвольном месте как обычное прерывание (без ожидающих завершения предшествующих процессов диспетчера задач) и в то же время не "примораживает" без необходимости иные задачи, использующие прерывания.
Вот и "хотелка" имеется аналогию по смыслу того ассемблерного решения соорудить.
Ведь простейший перебор позиций еще добавляться дополнительным функционалом должен. Даже при условии тех мизерных затрат - все равно интерес именно к такому разделению. Тем более, что таки охота тот программный модуль аналогично староассемблерному варианту пустить своим ходом и более об оном не заморачиваться.
А уж потом и до меню - там много проще будет.
Нечто подобное (возможно весьма коряво для Сишника ):

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


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

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

вы на самом деле так думаете?
вот в том кусочке кода, что я приводил, есть макрос обработчика прерывания ISR(TIMER0_OVF_vect) - помните? так вот, чтобы тело этого обработчика выполнялось при разрешенных "вложенных" прерываниях, надо изменить эту строку так: ISR(TIMER0_OVF_vect, ISR_NOBLOCK) - считаете, это великая морока?
вот это описанное вами извращение, как я понял его смысл, заключается в таком вот коде:как я уже говорил, это мало того, что не одобряемый принцип программирования на Си, так еще и ничем не лучше того, что я написал чуть ранее - просто сделать весь обработчик "не блокирующим" другие прерывания.

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

Понятьненько... то, чего под ассемблером таки в СИ не провести...
Обычное разрешение прерываний и усе...

Печалька...
Вот оттого и подсели на разновидности ОСРВ.

Придется в те ограничения втискиваться.... УУУршшш....


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

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

Не совсем так - у меня выход из прерывания с закрытием прерывания и переход к обычной подпрограмме, а затем выход из обычной подпрограммы в исходную точку.
А У Вас внутренние подпрограммы до последнего момента и затем выход из общего блока с закрытием прерывания.
(Стандартный вариант).
Разница таки есть. Но в большинстве "ширпотреба" вероятно не столь и заметна.

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

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