тут либо речь о каких-то элементарных операциях вида "выбор адреса" или "выставление данных на шину" (т.е. операции микрокода ядра), либо понятие "такт" перепутано с понятием "машинный цикл".
микрокод в ядре и вправду за один такт делает несколько лементарных действий, в самом простом случае по переднему и заднему фронтам тактового импульса, т.е. 2 операции. но с точки зрения программиста это значения не имеет, т.к. он лишен возможности как-то это контролировать
а вот машинный цикл может занимать несколько тактов, например, классическое ядро MCS51 на один машинный цикл тратит 12 тактов, старенькие PIC-и на цикл тратят 4 такта, и так далее. В этом случае по отношению к микрокоду ядра речь может идти о долях цикла, но никак не такта.
минимальное время выполнения команды NOP и будет равно 1/16000000, т.е. 0,0625 мкс. такую же длительность будут иметь и некоторые другие ассемблерные команды, например, NEG и т.п. говорить о времени исполнения кода на языке всокого уровня абсолютно неприемлемо, т.к. это величина не постоянная и целиком и полностью зависит от множества условий, например, от уровня оптимизации компилятора. что значит "общий вид"? примеры в даташитах AVR обычно приводятся именно на языке ассемблера AVR и на языке Си (обычно на "классической версии ANSI C).

ARV, С ассемблером понял, спасибо.
Т.е. 0.0625 мкс это время исполнения некоторых (надо полагать простейших команд)?
А например digitalRead исполняется дольше, чем внешнее прерывание, внешнее прерывание будет исполнятся 4 мкс? Или это уже бредни в которых незачем копаться?
Хочется понять как происходит работа МК а физическом уровне. Вот что такое бит, это же 1/0 (HIGH/LOW) т.е. наличие/отсутствие меандра на выводе. Как я понимаю этот меандр имеет частоту 16МГц, соответственно столько бит может обработать МК, но при этом даже считать показания с ноги нужно несколько таких тактов?
Машинный цикл понятно, время выполнения операции, при том на языке высокого уровня(?). Тогда что такое такт. Если мы говорим о тактовой частоте процессора и для atmega328 это 16 Мгц, то что успевает сделать МК за 0.0625 мкс? Например сравнить напряжение (бишь digitalRead) это понято требует нескольких операций, а вот внешнее прерывание? Оно разве не происходит со скоростью работы процессора в плане 16 МГц?

чтение порта происходит быстрее вызова прерывания, но! чтение порта происходит по запросу из программы, а когда программу заинтересует состояние порта - одному программисту известно а вызов прерывания (если флаги разрешения позволяют) начинается в ближайший цикл.
начнётся, но пока произойдет вызов по вектору прерывания, пока сохранится в стек состояние мк до прерывания (чтобы было куда вернуться после обработки прерывания), короче до выполнения написанного тобой полезного кода пройдёт довольно много тактов...
————
состояние порта это 1/0 наличие/отсутствие напряжения.
————
язык высокого уровня — более "человечный" язык, но, как правило в нём при переводе на машинный есть что изменить, (как при переводе одного человеческого языка на другой — результирующая фраза может сильно отличаться по длинне от исходной) и компилятор, как переводчик может запросто выкинуть или сократить на его взгляд лишнее,
вот поэтому в коде на ЯВУ не получается орентироваться по количеству команд (и кстати, что считать командой? строку? так в неё, при желании много втолкать можно)...

Добавлено after 4 minutes 52 seconds:
по поводу времени исполнения конкретных команд - это в даташит. там должен быть список доступных данному мк команд и время (а точнее количество тактов) их выполнения.

Добавлено after 6 minutes 6 seconds:
я точно не помню этот список, потому что им очень редко приходится пользоваться, обычно время выравнивается или аппаратно - прерыванием (по таймеру или от другой периферии) или подпрограммой delay() там количество циклов ожидания вычисляется компилятором автоматически

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

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

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

Добрый день, в устройстве необходимо отображение заряда батареи, которая разделена на три секции, делаю это с помощью делителя.
http://prntscr.com/ntwz09

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

ПОд гистерезисом понимаю, область в 5 милливольт в которой не изменяется состояние батареи.

А у меня еще вопрос, выпаял с digispark attiny85 прошитую на замыкание по прерыванию, впаял а свою плату, она не работает и ток вместо 4мА стал от 10 до 20 прыгать, на прерывание не реагирует, думал перегрел, впаял обратно в плату digispark работает как часы, глянул в даташит там нет никакой инфы про запуск, может ресет надо подтянуть к земле?

ищи "козу"

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

baghear Увеличьте гистерезиз еще больше, 5 мВ это слишком мало.
Также можно попробовать находить среднее значение из нескольких выборок АЦП, если скорость не критична, а она для вашего случая я думаю не критична.
Плюсуйте 256 отсчетов и делите на 256, например.

как вам демка? VGA-графика формируется микроконтроллером attiny5
прошивка занимает 492 байта, а в МК аж целых 32 байта ОЗУ и 16 регистров
интересно, аналогичная демка на ARM уложится в такие требования по объему, ОЗУ и регистрам?

Сама по себе демка примитивна и бессмысленна.
Поэтому легко реализуема малыми ресурсами.
Понятно, что сложные архитектуры израсходуют на примитивную задачу больше ресурсов, нежели простые.
Даже стартап на АРМе займет в разы больше места. Но о чем это говорит? Да ни о чем.
В магазин на соседней улице можно сходить пешком, съездить на велосипеде и сгонять на Порше Кайен.
Результат будет идентичный. И даже по времени почти не отличимый.
Из этого не следует, что на Кайене не нужно ездить в магазин. Даже на соседней улице.

На счёт "легко" не уверен. А смысл в том, что: есть задачи, не стоящие поездки на Порше, и применять Порше везде и всюду не меньшая глупость, как везде и всюду ходить пешком.

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

Еще раз. Задача КРАЙНЕ ПРИМИТИВНА. Это просто СТАТИЧЕСКАЯ КАРТИНКА с нарушенной синхронизацией. Сие нарушение синхронизации делается от счетчика кадров. Причем можно состояние счетчика пропустить через любую таблицу.
Именно бессмысленность изображения позволяет легко его реализовать. Никакой сложной тригонометрии и вообще расчетов там нет. Типо детского калейдоскопа со случайными обломками цветного стекла.


Отнюдь. Глупо задаваться вопросом о способе перемещения в соседний магазин. Простота задачи соединенная с ее сиюминутностью делает размышления бессмысленными.
В соседний магазин нужно передвигаться ПЕРВЫМ ПРИШЕДШИМ НА УМ СПОСОБОМ. То есть по ничем не объяснимой ПРИХОТИ.

Пешком, если понадобится, до Пальма-де-Мальорка трудно, на порше полегче

Кто о чем, а вши про баню...
Олег, Вы как то не в тему, извините...

конечно в тему -это к вопросу:

реальный пруф к этому:

Совершенно не в тему. Приведенная Вами демка для АРМа на 1000 порядков более ресурсоемкая, нежели та, что была приведена для Аттини.
То, что можно достаточно просто реализовать весьма требовательные к вычислениям графические задачи на АРМе, ВСЕМ ИЗВЕСТНО и НЕ ТРЕБУЕТ ПОДТВЕРЖДЕНИЙ.
Тема была совершенно не про это.
ЗЫ. Под ресурсами понимаются не только ОЗУ и флеш. Сюда входят и разного рода периферийные ресурсы. Включая DSP копроцессоры, графические ускорители etc. А так же частоты тактирования ядра и периферии.

ну вот же и ответ получился на вопрос:

имхо, если упростить, аналогичная демка будет на 100 порядков. Однако эту демку можно написать на языке более высокого уровня - C++, там есть еще пример на Rust для STM32. Имхо это важнее чем ресурсы.

КРАМ, на самом деле практическое применение есть. Например, это альтернатива рамке со словами "No signal detected". Мне и Вам эта альтернатива безразлична, а тому же ARV она понравилась. Значит, некоторое количество покупателей выберут монитор именно с таким screen saver. Вот и конкурентное преимущество, достигнутое только прошивкой контроллера монитора

Добавлено after 15 minutes 30 seconds:
ARV, на самом деле это новое есть хорошо забытое старое. Например, мой отец занимался в начале 80-х именно формированием изображения для телеигр/игровых автоматов на ПЛМ и ПЗУ вообще без МК. И вполне успешно.