Читаю даташит на мегу1284 и никак понять не могу что там с atomic operations и к чему они ведут.
Вот, например, меговский таймер Т1 тактируется от внешней частоты, которая всего в 4 раза меньше системного клока.
Вдруг захотелось считать регистр содержимого счетчика TCNT1 (сначала low байт, потом high байт).
То есть, клоков внешней частоты на Т1 пройдет заведомо больше, чем один, за то время, пока я буду этот регистр читать.

Что я считаю из регистра TCNT1 в итоге? Наверное, ничего хорошего, но что именно?
Будет ли таймер при таких условиях считать внешнюю частоту нормально или пропустит клоки, пока читать буду?

AVR'овские таймеры были организованы так, что чтение из младшего байта таймерного регистра вызывает одновременное чтение старшего байта во временный (теневой) регистр, и последующее чтение из старшего байта таймерного регистра физически производится из упомянутого теневого регистра. Таким образом, совершенно без разницы, какие там соотношения частот тактирования ядра и таймера - чтение из таймерного 16-разрядного регистра всегда производится так, что читаются все 16 бит. Единственное, что нужно соблюдать порядок чтения половинок регистра - в документации это достаточно внятно указано.

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

Атомарные операции в данном случае очень важны. При чтении low байт у вас одновременно читается и high байт во временный регистр, как уже сказал dxp. Так вот, если между чтением low и high байтов у вас произойдет прерывание - в его обработчике этот временный регистр может затереться другим значением, т.к. он один для всех двухбайтных регистров I/O. Атомарная операция, это та, которую нельзя разорвать прерыванием - это нужно вручную выставлять, например: сохранить состояние бита глобальных прерываний, запретить прерывания, выполнить чтение/запись двухбайтного регистра, возобновить старое состояние бита прерываний.

это лишнее . Cli за глаза хватит

Вы проверили это "в железе", или это - Ваши домыслы?
Чтение DS не прояснило количество временных регистров (плохо смотрел?), а термин" Temporary Register" всегда встречается в единственном числе... Что породило сомнения - я всегда считал, что временный регистр есть у каждого шестнадцатибитного регистра, за исключением тех, для которых прямо написано об их отсутствии.
Имхо, Atmel'овцы - не дураки и, вероятно, поступили "по-уму" встроив в МК отнюдь не один временный регистр. Под рукой нет МК, чтобы проверить это "в железе"...
Симулятор AVRStudio (ох, не доверяю я этим симуляторам!) утверждает, что временный регистр всё-таки не один.

Кто-то может это проверить на реальном МК и подтвердить (или опровергнуть) слова Schulz_K?

Сделал так , для каждого из устройств получил свои значения. Т.е получается у ADC свой временный регистр у таймера свой.

У АЦП вообще нет временного регистра. Там при чтении ADCL обновление результата преобразования вообще блокируется до пока ADCH не прочитают. Со всеми вытекающими.


Да и вообще у вас с кодом чето не то.

Да с АЦП - промашка, но других 16 битных нет. Хотя и OCR тоже без TEMP Запросил support Atmel .
Если считывать так , то в temp-ах значения TCNT , а в mean значения ICR , но для тааймера всё таки он един
А Вы , что первый раз asm видите?

в отцитированном у меня коде Вы дважды читаете OCR1AL и ни разу OCR1AH. Сначала читается ADCH, потом ADCL, хотя нормальные люди делают наоборот. Так что не в асме дело

Ох извините , когда писал пост , чуточку ошибся, вместо читать OCR1AH

Нет, отнюдь не лишнее.


Зачем?

Казалось бы, все ясно написано.

Что может произойти кроме RESET в момент чтения/записи если cli

Спасибо.

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

Подождите. Когда программа подходит к месту чтения из 16-bit регистров , Вам не пофиг разрешены или запрещены прерывания. CLI либо изменит состояние I, либо нет. При этом не нарушив ход выполнения программы , так как другие флаги не изменятся. Я видел , конечно примеры в DS, но помоэму это избыточно.
И это хорошо , если есть свободный регистр куда можно пихнуть SREG , а если нет , надо запомнить регистр , запихнуть SREG и все потом в обратном порядке
. Тогда уж сразу отдельная подпрограмма.

Представьте: прерывания уже были запрещены (и не просто так, наверное), выполнили CLI (которая ничего не изменила), прочитали регистры, а потом что?
Разрешить прерывание теперь - значит нарушить нормальный ход программы. Для этого и нужно сохранять состояние - чтобы была возможность вернуть процессор в исходное.

Убедили

Что-то у меня логика не сходится.
Пусть прерывание произошло между чтением младшего и старшего байта. Пока читается младший, старший , тихой сапой , переползает в регистр временного хранения. Прерывание сохраняет , полюбасу , следующую команду и тихо уходит по своим делам . Если в эти дела , таймер не замешан , то старший байт сидит и ждёт своей участи , торча там где ему и положено, счётчик считает. Все заняты своим делом.
Вернулись , прочитали старший байт - он не изменился. Т.е , если в прерывании timer не задействован , то нафинг запрещать прерывания перед чтением.

В этом случае действительно ничего запрещать не надо.

Спасибо