fk0, легенда (10.11.2017 13:12, просмотров: 397) ответил MBedder на Таймера у читающих даташиты считываются еще проще - при корректном чтении первой половины таймера (в ДШ написано, какую именно половину следует читать первой) содержимое второй половины аппаратно защелкивается в теневой регистр, из которого
Увы, это не всегда помогает. У pic18 есть теневой регистр, но... для нормальной работы пришлось городить такую конструкцию: аппаратный таймер 16 бит, или даже 12, тут не помню, по прерыванию инкрементится ещё слово (16 бит) программной части таймера. Для получения в любой момент времени некого единого счетчика времени берётся старшая часть из программной части и младшая из аппаратного таймера. Ну вот сложить их без приведённой конструкции с многократным чтением -- никак (прерывания запрещать вообще не вариант: младшая часть-то аппаратно все равно проинкрементится и будет неправильное значение). Зачем такие сложности? Можно, конечно, для времени высокого разрешения использовать один таймер, для времени низкого разрешения -- другой, но таймеров лишних нет и полагаться на что-то специфичное для МК желания тоже нет. Некий абстрактный счетчик времени -- он для любого проекта на МК практически нужен, и он и высокое разрешение давать должен, порядка миллисекунд и меньше, и большие периоды, десятки минут, 16 бит никак не хватает. Это если архитектура вида big loop. Если time triggered, до там можно к циклам привязаться, но в такой архитектуре многое нормально не сделать, IMHO это для жесткого реалтайма только. Если event driven или multithread то есть какой-то планировщик, и у него тоже есть понятие времени.
[ZX]