Поиск качественной литературы по мк. КР580ВМ80А

[Adrift]

[uquote="AlexS4",url="/forum/viewtopic.php?p=4675375#p4675375"]ps напомню что на начало 90х самые дешевые+удобные x51 производил какраз тоже атмел
и макс частота x51 была 24MHz (~ экв avr@2MHz)[/uquote]
У атмеловских x51 машинный цикл за 6 тактов выполнялся, а не 12. AVR был неплох, но приоритеты прерываний зажали и даже в новых AVR в этом плане стало не особо лучше.

[Starichok51]

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

[AlexS4]

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

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

[BOB51]

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

[Just_Fluffy]

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

Нормальная событийная практика.
Единственное что я оставляю зачастую в прерывании - это опрос кнопок и динамическую индикацию, ежели таковая есть. Но опять же, зависит от контекста. Если все события обрабатываются за время, меньшее, нежели итерация динамической индикации и/или опроса кнопок, то эти процессы можно и по событию обрабатывать в основном цикле.
А если там где то закрадывается блокирующая запись в EEPROM - то индикация уже может начать мерцать.....

[BOB51]

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

[Just_Fluffy]

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

[BOB51]

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

[AlexS4]

BOB51 скорее всего имеет ввиду - зарезервировать фиксированное время в расписании динамической индикации для долгих неперываемых процедур
но у меня не бывало такой потребности, обычно шаг развертки динамической индикации это выбор из буфера, ротация индекса и запись в пару портов, ну может еще нибблы и шифрование байта в сегменты (если 4битная плотная упаковка в буффер), это все 6..15 инструкций, если хотьчуть подумать над оптимизацией закольцовок итп. это ну 1uS @10MHz. обычно не проблема в таймерное прерывание засунуть, вместе с антидребезгом кнопок и всяких прочих опросных входов, которые еще на 1-3uS. и забыть про всякие некрасивые артефакты, так очевидно палящие топорность кода .

[Just_Fluffy]

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

[Starichok51]

запись нескольких байт в ЕЕПРОМ нужно делать по прерыванию, тогда никакой блокировки не будет.
мега8 дает время записи в ЕЕПРОМ 8 мс, это очень долго, чтобы блокировать выполнение программы.
в моих программах нужно записать 2 байта двухбайтового параметра, а это уже 16 мс. я у себя сделал запись второго байта по прерыванию.

[Just_Fluffy]

запись нескольких байт в ЕЕПРОМ нужно делать по прерыванию

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

[BOB51]

частота регенерации 62 Гц 0,016 секунды строка (даже не 50Гц)
дисплей на 5 позиций, используется только 4
на одну позицию 0,0032 секунды.
никакой потери в яркости...

Можно без вреда и чуток длиннее сделать.
В древни времена для "лаподрыгового обмена" с микролан датчиками удобно было.
На сегодня с разнообразными аппаратными модулями уже не столь актуально.

[Starichok51]

Just_Fluffy, не надо караулить флаг готовности (окончания) записи.
у меня "буфер" только на один (второй) байт. а если байтов несколько (много), в прерывании (EEPROM Ready) брать из буфера каждый следующий байт.

Добавлено after 7 minutes 34 seconds:
поясню для понимания.
первый байт на запись отправляем сами, а буфер заполняем, начиная со второго байта. и организуем счетчик байтов (за минусом первого байта).
а после последнего байта запрещаем прерывание.

[AlexS4]

тогда уж для однородности все через прерывание и инициировать первый прогон вручную.

[Starichok51]

AlexS4, где ты увидел неоднородность в моих словах?

[Just_Fluffy]

Starichok51, если уже спорить про скорсть, то на самом деле прерывание - достаточно медленная штука. Даже на асме. Просто из-за входа в обработчик, выхода из него, сохранения SREG и пары регистров.

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

[AlexS4]

если отбросить sleep, и экономию батарейки то да, нет разницы гонять опрос или прерывать, насчет быстродействия - тут на фоне mS 'экономия даж в целых 300nS врядли важна ,

Спойлер

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

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

[Starichok51]

Just_Fluffy, на постоянную проверку флага готовности ты потеряешь больше времени, чем на прерывание.

[Just_Fluffy]

Starichok51, да ладно!
Проверить бит EEWE в регистре EECR (SBIC/SBIS ) - это дольше, нежели накладные расходы на прерывание?