Ассемблер (ASM) для AVR в вопросах и ответах

[BOB51]

I2C допускает приостановку на некоторое время (если обработчик мастера программный).
Замена данных в буфере отображения/вывода ВСЕГДА производится в конце текущей строки развертки при погашенной индикации (тогда и "дерготни" не будет)
А глазу наблюдателя смена показаний что на 0,016 секунды раньше, что на такое же время позже АБСОЛЮТНО БЕЗ РАЗНИЦЫ.

Насчет "глючения" в разные относительно длинные и неравномерные интервалы времени - это к гадалкам.
Обычно нормально написанная программа таких дефектов не имеет.

Кстати... обычно чтение ВСЕХ данных из RTC делается или однократно при запуске устройства по подаче питания или только по "жизненной необходимости" (включая коррекцию данных").
В остальное время работает модуль "внутренних часов" в самом МК с приращением от ежесекундного прерывания от RTC.
Остальные программы подбираются с учетом секундного интервала - должны или вписыватся в него или "дробиться" на участки менее 1 секунды.

[dgrett]

Гефестион, я бы в прерывании от часов просто считал бы до 60, а с часами по i2c синхронизировался бы по истечении тех 60 сек, т.е. раз в минуту. А 500 герц считаю слишком много, для динамики имхо, хватило б и 100. Тогда и не надо будет разрешать прерывания в прерывании.

[Мурик]

Низкоприоритетному прерыванию (секунды) можно включить флаг ISR_NOBLOCK

С каких пор AVR аппаратно поддерживают вложенные прерывания? Эта возможность появилась в более новых МК например с ядром ARM. У многих из них есть встроенный RTC и внешний не нужен.

[BOB51]

Зависит от числа разрядов и количества сегментных портов.
0,016 секунды на всю развертку (~ 62,5 Гц)
при 8 знакоместах и одном сегментном порте 0,016/8 = 0,002 секунды на знакоместо (те же 500 Гц)
Можно конечно еще и "прошимить"...
Но даже такой вариант при правильной смене данных и грамотном распределении ресурсов заметного мерцания не даст.
Как вариант гашение одного из нескольких циклов развертки в уж оччень жестких условиях для процедур, не терпящих прерываний.

Синхронизация с RTC не имеющими программной коррекции точности хода в энергонезавсимом режиме даст гораздо меньшую точность, чем отработка собственного КВАРЦЕВОГО генератора МК, да еще на гораздо более высокой частоте и при программной коррекции точности хода. RTC более как "хранилище опорных данных" во время отключенного состояния устройства использовать полезно.


МУРИК...
Ну не ожидал такого "ляпсуса" насчет вложенных прерываний у АВРок...

Достаточно добавить внутри открытого прерывания команду разрешения (как и у всех типовых МК).

Другой вопрос контроллер приоритетных прерываний как например у MCS51

[Мурик]

Достаточно добавить внутри открытого прерывания команду разрешения

BOB51, я про аппаратную поддержку, а то что вы предлагаете это программная. При некоторых обстоятельствах программно разрешая прерывания можно получить переполнение стека. При аппаратной поддержке прервать текущее прерывание, может только то что имеет больший приоритет чем текущее, которое выполняется. В AVR (ATtiny и ATmega) такого нет.

[WiseLord]

С каких пор AVR аппаратно поддерживают вложенные прерывания?

И где это Вы в моих словах вычитали что-то про аппаратную поддержку прерывания? Я вроде как всё совсем наоборот сказал.

[BOB51]

Зато там нет блокировок, свойственных аппаратным контроллерам - запрет на повторный вызов того же прерывания внутри текущего исполнения. Пресловутое "нельзя выполнить снова, пока хотя бы одна команда после возврата не будет выполнена".
Хотя то конечно ВЕЛИКИЙ ИЗВРАТ не для начинающих.
И не путать ВЛОЖЕННЫЕ ПРЕРЫВАНИЯ
с
АППАРАТНЫМ КОНТРОЛЛЕРОМ ПРИОРИТЕТНЫХ ПРЕРЫВАНИЙ,
тем более, что ни Z80 ни MCS51 "новыми" никак назвать нельзя...

Да и переполнение стека при 32х регистр-акумуляторах и одновременно минимум 64 байтах ОЗУ под стек...
Это уж только ежли некорректности с возвратом из подпрограмм допустить. Надо весьма умудриться...

[WiseLord]

Достаточно добавить внутри открытого прерывания команду разрешения

Как я писал чуть выше, чуть более правильно будет объявить прерывание с соответствующим флагом, например ISR (PCINT2_vect, ISR_NOBLOCK). При этом компилятор сам постарается разрешить (прочие) прерывания при входе в обработчик как можно раньше. По крайней мере, по сравнению с обычным неблокирующим объявлением типа ISR (PCINT2_vect) + разрешением внутри него.

Для очень редких прерываний (таких как ежесекундное от RTC) такой подход (вложенность прерываний даже на AVR) вполне имеет право на жизнь.

Естественно, я говорю про стандартную связку gcc + avr-libc, а не про прочие маргинальные компиляторы (вещи в себе). Хотя, может и там где-то предусмотрено что-то подобное. Никогда особо не интересовался.

[ARV]

[uquote="Мурик",url="/forum/viewtopic.php?p=3468331#p3468331"]

Низкоприоритетному прерыванию (секунды) можно включить флаг ISR_NOBLOCK

С каких пор AVR аппаратно поддерживают вложенные прерывания? Эта возможность появилась в более новых МК например с ядром ARM. У многих из них есть встроенный RTC и внешний не нужен. [/uquote]очень уместное упоминание в теме про ассемблер AVR. Кстати, в "новых" ваших ARMах вложенные прерывания с приоритетами появились примерно спустя 25 лет после того, как они были реализованы в i8051

[BOB51]

[uquote="WiseLord",url="/forum/viewtopic.php?p=3468483#p3468483"]...

Естественно, я говорю про стандартную связку gcc + avr-libc, а не про прочие маргинальные компиляторы (вещи в себе). Хотя, может и там где-то предусмотрено что-то подобное. Никогда особо не интересовался.[/uquote]

Речь идет о "чистом ассемблере" (avrasm2), а не о том варианте, что в Си применяется.
Ибо Сишный - то дело темное и требующее настроек компилятора в придачу. Кои весьма муторны для начального освоения.
В ассемблере в чистом виде все распределение ресурсов и работа с разрешением/запретом прерываний (в том числе и их объявление - прописывание самих подпрограммок с указанием в нужных местах ПЗУ соответствущих векторов перехода) делает автор программы САМОСТОЯТЕЛЬНО.
Автору же и решать можно чего вложить или нет - никаких ограничений /контроля про времени исполнения/наложению программ при их исполнении в готовом устройстве компилятор не выполняет. Проверяется только корректность мнемоник команд, директив и границы размещения кода/данных.
В том есть и свои плюсы и свои минусы.

[WiseLord]

Да, Вы, наверное, правы. Я как-то сразу не обратил внимания на то, что тема-то про ассесблер. Хотя, всё равно имею мнение, что лучше привязаться к gcc, как чему-то относительно стандартному. Хотя это скорее полезно для возможности делать смешанный программы - что-то требовательное к ресурсам делать на ассемблере, а основную логику программы - на том же C.

[Мурик]

что-то требовательное к ресурсам делать на ассемблере

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

[ПростоНуб]

[uquote="Мурик",url="/forum/viewtopic.php?p=3468860#p3468860"]по цене AVR можно купить более производительные микроконтроллеры (32-ух битные и с большей тактовой частотой)[/uquote]
Назовите хотя бы один 32-х битный МК по цене ATTiny13A и тоже в SOP-8, так как габариты имеют значение.

[Мурик]

ATTiny13A для очень простых задач. Размеры флеша и ОЗУ (всего 64 байта) и возможности периферии, а также число выводов не позволяют что-то нормальное сделать. Посмотрим на это с другой стороны. Допустим есть STM32F030F4P6. Его характеристики.

Спойлер

Если кратко, стоимость в Китае около 0.5$. Корпус TSSOP20 (20 выводов), 32-ух битное ядро ARM, тактовая частота 48 МГц, 32 КБ флеша, 4 КБ ОЗУ, 12-ти битный АЦП, 7 таймеров (ШИМ, захват, ШИМ захват, поддержка энкодера и датчика холла, события запуска АЦП, объединение таймеров в цепочки и многое другое), 5 из которых 16-ти битные, один 32-ух битный и еще один системный 24-ех битный, USART, I2C, SPI, RTC, CRC, DMA (по русски ПДП - прямой доступ к памяти) 2 сторожевых таймера и т. д. Поддержка отладки. Отладчик ST-Link в Китае стоит 100 рублей. МК поддерживает выполнение кода из ОЗУ, куда можно перенести так же таблицу векторов прерываний. А еще фьюзов нет. Все настраивается программно. Например можно во время работы переключится с внутреннего RC генератора на внешний кварц или наоборот. Можно программно разогнать МК. http://purebasic.mybb.ru/viewtopic.php?id=583
Назовите мне модель МК AVR обладающую подобными возможностями и стоящую не больше чем 0.5$?

Замечу это самая простая модель. У других возможностей еще больше.

[BOB51]

А потом "после очередной порции САНКЦИЯ" народ воет об импортозамещении и невозможности "спрыгнуть" с троянского коня/дармового сыра...

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

[Гефестион]

[uquote="WiseLord",url="/forum/viewtopic.php?p=3468225#p3468225"]Низкоприоритетному прерыванию (секунды) можно включить флаг ISR_NOBLOCK, тогда оно будет прерываться другими. Фактически, то же самое, что Вы сделали, но, что ли, чуть правильнее[/uquote]
А как это сделать?

Добавлено after 50 seconds:
[uquote="trofim2",url="/forum/viewtopic.php?p=3468278#p3468278"]И не надо вообще входить в прерывание по секунде, а просто опрашивать его в фоне, и вычитывать по I²C и сбрасывать запрос на прерывание.[/uquote]
Опрашивать прерывание в фоне - это как? Или Вы имеете ввиду, в фоне опрашивать RTC?

Добавлено after 6 minutes:
[uquote="BOB51",url="/forum/viewtopic.php?p=3468285#p3468285"]Замена данных в буфере отображения/вывода ВСЕГДА производится в конце текущей строки развертки при погашенной индикации (тогда и "дерготни" не будет)
А глазу наблюдателя смена показаний что на 0,016 секунды раньше, что на такое же время позже АБСОЛЮТНО БЕЗ РАЗНИЦЫ.
[/uquote]
Хорошая идея! Вот только как синхронизировать прерывания от таймера и внешние прерывания?

[uquote="BOB51",url="/forum/viewtopic.php?p=3468285#p3468285"]Насчет "глючения" в разные относительно длинные и неравномерные интервалы времени - это к гадалкам.
Обычно нормально написанная программа таких дефектов не имеет.[/uquote]
Да уж, это точно) Решительно не могу понять, как процессор перепрыгивает в самое начало программы. которое вообще не должно повторяться. Там помимо начальной инициализации портов и периферии на индикаторы выводится 1234, затем rjmp PC и дальше работа на прерываниях. Но каким-то образом раз в несколько часов на индикаторах снова появляется 1234 и время перестаёт считываться из RTC.


[uquote="BOB51",url="/forum/viewtopic.php?p=3468285#p3468285"]Кстати... обычно чтение ВСЕХ данных из RTC делается или однократно при запуске устройства по подаче питания или только по "жизненной необходимости" (включая коррекцию данных").
В остальное время работает модуль "внутренних часов" в самом МК с приращением от ежесекундного прерывания от RTC.
Остальные программы подбираются с учетом секундного интервала - должны или вписыватся в него или "дробиться" на участки менее 1 секунды.
[/uquote]
Если подсчётом времени занимается RTC, то зачем программно считать время? ИМХО, проще с некоторым интервалом читать время из RTC.

Добавлено after 2 minutes 59 seconds:
[uquote="dgrett",url="/forum/viewtopic.php?p=3468305#p3468305"]А 500 герц считаю слишком много, для динамики имхо, хватило б и 100. Тогда и не надо будет разрешать прерывания в прерывании.[/uquote]
500 Гц - это потому что 5 индикаторов (часы, минуты и посередине разделительный символ мигает раз в секунду). Т.е. цикл повторения индикации как раз 100 Гц.

[BOB51]

Поднимать частоту выше 62 Гц смысла особого нету, ибо все-таки нужен компромисс между минимальной скоростью развертки и спецификой восприятия глаза.
Синхронизация процессов собственно динамической развертки и внешних выполняется посредством флагов пользователя и буфера отображения в конце обработки текущей строки.
Опрашиваем флаги и, при необходимости, меняем содержимое буфера отображения содержимым из буфера предподготовки данных.
В принципе.. у АВРок на основе таймера Т1 и его прерываний можно превосходный контроллер динамической развертки организовать. При том, что он будет функционировать параллельно основному процессу.
Касательно RTC и "внутреннего счета времени" - при нежелании особо закапываться в организацию внутренней "сетки синхронизации" удобно использовать только начальную загрузку данных в часы, а приращение и обработку данных вести по прерываниям. Затраты времени на обмен в таком случае исключаются, что облегчает функционирование остальных, критичных ко времени участков программы.
Насчет "перепрыгов"...
В МК существует аппаратный модуль, который в момент возникновения разрешенного прерывания соответствующего приоритета автоматически загружает в стек адрес возврата и выполняет команду LCALL на адрес вектора данного прерывания.
А вот "спасение" в стеке SREG и прочего критичного содержимого регистрового файла - это уже забота автора программы (как и корректный возврат из прерывания).

[ПростоНуб]

[uquote="Мурик",url="/forum/viewtopic.php?p=3469055#p3469055"]ATTiny13A AVR?[/uquote]
Да, AVR. Загляните в даташит. "High Performance, Low Power AVR® 8-Bit Microcontroller"

Назовите хотя бы один 32-х битный МК по цене ATTiny13A и тоже в SOP-8, так как габариты имеют значение.

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

Добавлено after 6 minutes 5 seconds:
[uquote="Мурик",url="/forum/viewtopic.php?p=3469055#p3469055"]Назовите мне модель МК AVR обладающую подобными возможностями и стоящую не больше чем 0.5$?[/uquote]
А почему я должен на этот вопрос отвечать? Я разве где-то утверждал обратное?

[Гефестион]

[uquote="BOB51",url="/forum/viewtopic.php?p=3469048#p3469048"]буфера отображения в конце обработки текущей строки. [/uquote] Сейчас сделал так: запретил внешние прерывания до тех пор, пока счётчик циклов индикации не дойдёт до 5 и запретил вложенные прерывания (убрал SEI в прерывании от RTC). Т.е. теперь внешнее прерывание возникает только в конце цикла индикации. Всё равно индикация дёргается В общем, обработчик внешнего прерывания должен выполняться гораздо быстрее. Не буду опрашивать RTC каждую секунду и, наверное, подниму тактовую частоту (щас у меня по дефолту 1 МГц от встроенного RC)

[dgrett]

Гефестион,
"500 Гц - это потому что 5 индикаторов (часы, минуты и посередине разделительный символ мигает раз в секунду). Т.е. цикл повторения индикации как раз 100 Гц."
Разделительный символ это часом, не Н сегмент единиц часов?
Считаю, что достаточно для 4х знакового индикатора обновлять инфу каждые 10 мс. В прерывании гасим индикатор полностью, выбираем следуещее знакоместо и инфу, которая должна быть на него выведена. А теперь включаем индикацию и сваливаем из прерывания. У Вас мк перегружается, как я понял, так есть регистр кажется MCUCSR, не помню, но там есть инфа, от чего пошли на ресет.