[adnega 11]

У меня было такое.... сделал таймер с тиком в 1 мс и отрубил прерывания.

А если бы не отрубил прерывания, то что?

[juvf 17]

А если бы не отрубил прерывания, то что?

А они мне зачем? У меня есть полностью аппаратный таймер, зачем мне программный таймер и обработчик прерывания? Вы наверно аппратный RTC(или UART/SPI/PWM/...) не будете пользовать, т.к. можно сделать программный, с календарем, с кучей будильников, ведь программный RTC займет всего 0,003% ресурсов!!!

[adnega 11]

А они мне зачем? У меня есть полностью аппаратный таймер, зачем мне программный таймер и обработчик прерывания?

Допускаю, что есть эксклюзивные задачи, в которых одного таймера до 65 мс достаточно, но в общем случае вариант

с 1мс-прерыванием гораздо универсальнее.

В некоторых библиотеках я вообще пришел к двум/трем функциям

on_init() - один раз при инициализации МК

on_mainloop() - внутри mainloop`а

on_timer() - внутри 10мс-таймера

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

типа таймер с предделителем таким-то и т.п.

Я не против исключений из правил, но их не стоит выдавать за правило.

Я на atmega8 вообще без аппаратных таймеров делал программный UART-TX тупо nop-ами формировал задержку,

и работало-ведь, но я же объявляю это нормой. Сделать софтовый 1мс таймер настолько просто, что грех от этого отказываться.

И мне не понятно зачем? ТС говорил, что у него какие-то критические секции есть... думаю, больное место там.

[jcxz 243]

И мне не понятно зачем? ТС говорил, что у него какие-то критические секции есть... думаю, больное место там.

Я думаю - там весь код одно сплошное больное место. Судя по постам ТСа... :biggrin:

[juvf 17]

Допускаю, что есть эксклюзивные задачи, в которых одного таймера до 65 мс достаточно,

65536 мс. не 65 мс, а 65 ТЫСЯЧ мс, это 65 секунд. И таймер один, но одновременно всяких интервалов и периодов можно задавать хоть сотню (как и на программном). Решение гибкое, воспроизводимое на множестве камней и архитектур. Никаких дополнительный аппаратных требований программных обработчиков, программного кода, настроек NVIC и т.п. Если зашли в критическую секцию (остановили прерывания), то таймер продолжит считать.

 

тупо nop-ами формировал задержку .... я же объявляю это нормой

опечатка?

 

И мне не понятно зачем?

Не знаю как объяснить? зачем в МК аппаратная перефирия? можно всё программно сделать, без таймеров, на ноп-ах и ногодрыгах.

[adnega 11]

зачем в МК аппаратная перефирия? можно всё программно сделать, без таймеров, на ноп-ах и ногодрыгах.

Я за полную загрузку периферии. В Cortex все унифицировали: есть одинаковый для всех SysTick и одинаковый NVIC.

За это переживать не надо.

Никогда не приходилось запрещать прерывания, а задачи решал самые разные. Для этого есть NVIC с ключевой буквой N,

типа вложенных прерываний с гибкой настройкой приоритетов. Недавно обсуждали SVC вместо критических секций.

[Obam 38]

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

Долгие годы программирования "железа" должны были научить пользоваться документацией на это "железо" ;)

 

то же самое - у него нет пределителя - я не могу создать тик с периодом и 1 миллисекунду.

RefMan на подсемейство K10: про PIT гл. 41 (всего 12 стр) разд. 41.4.3 волшебные слова "Chain mode" - тик будет с любым периодом. Редко у чего бывает "предделитель" в 32 разряда.