SciFi (28.05.2023 15:43, просмотров: 99) ответил my504 на Хорош то он хорош, но является фичей STM. По нынешним временам
неактуально. Поэтому альтернативы простому циклу с калибровкой под
архитектуру/проект не видно.ส็็็็็็็็็็็็็็็็็็็็็็็็็༼ ຈل͜ຈ༽ส้้้้้้้้้้้้้้้้้้้้้้้
-
- У меня таймеры заканчиваются в каждом втором проекте. Делать из них
микросекундные задержки совсем некуртуазно. Я даже не понимаю какой
с этого профит. Другое дело - таймер больших задержек. Под это я
стандартно выделяю отдельный простой таймер (иногда SysTick) и он
генерирует прерывания с нужным мне дискретом (обычно 10 мс). - my504(28.05.2023 15:54)
- Я давно обнаружил, что большинство вопросов времени решаются в
стиле "start = current_time(); while (current_time() - start <
BLAH_BLAH) { /* wait */ }". То есть один таймер (обычно
DWT->CYCCNT) решает почти все такие вопросы. Никаких
регулярных прерываний. - SciFi(28.05.2023 16:52)
- Либо задержка блокирующая, либо работает через прерывания. Делать
блокирующие задержки значительной длительности - плохая идея. А
маленькие можно и традиционным способом через программный счетчик
циклов. По любому для них особой точности не получить и она не
требуется. - my504(28.05.2023 17:15)
- Да, по приведённому коду - блокирующая. Если без ОС - то автор, предположительно, понимает что делает: нет чего-то, что надо отслеживать на интервале такого замера; если ОС - то на крайний случай вытеснится задача. К тому же прерывания тоже имеют время реакции, сохранения на стек, загрузки из стека; так что для микросекундных - вполне вариант при определённых условиях. - Dingo(29.05.2023 04:52)
- Неблокирующая. Main Loop + protothreads. Удивительно, но решает
почти все мои вопросы. В редких случаях, когда нужна точная
времянка, есть аппаратные таймеры и прерывания. - SciFi(28.05.2023 17:32)
- Тогда у вас скорее не while(), a PT_WAIT_WHILE() :о) - Dingo(29.05.2023 04:55)
- Строго говоря, можно и while (...) { PT_YIELD(...); } :-) - SciFi(29.05.2023 09:40)
- Это частности; существенно то, что вы умолчали об используемом
вызове ОС, но утверждали, что неблокирующий и оно так работает. - Dingo(29.05.2023 09:57)
- Арестуйте меня :-) - SciFi(29.05.2023 09:58)
- Не дождётесь. ;-) - Dingo(29.05.2023 10:02)
- Арестуйте меня :-) - SciFi(29.05.2023 09:58)
- Это частности; существенно то, что вы умолчали об используемом
вызове ОС, но утверждали, что неблокирующий и оно так работает. - Dingo(29.05.2023 09:57)
- Строго говоря, можно и while (...) { PT_YIELD(...); } :-) - SciFi(29.05.2023 09:40)
- Тогда у вас скорее не while(), a PT_WAIT_WHILE() :о) - Dingo(29.05.2023 04:55)
- Либо задержка блокирующая, либо работает через прерывания. Делать
блокирующие задержки значительной длительности - плохая идея. А
маленькие можно и традиционным способом через программный счетчик
циклов. По любому для них особой точности не получить и она не
требуется. - my504(28.05.2023 17:15)
- Я давно обнаружил, что большинство вопросов времени решаются в
стиле "start = current_time(); while (current_time() - start <
BLAH_BLAH) { /* wait */ }". То есть один таймер (обычно
DWT->CYCCNT) решает почти все такие вопросы. Никаких
регулярных прерываний. - SciFi(28.05.2023 16:52)
- У меня таймеры заканчиваются в каждом втором проекте. Делать из них
микросекундные задержки совсем некуртуазно. Я даже не понимаю какой
с этого профит. Другое дело - таймер больших задержек. Под это я
стандартно выделяю отдельный простой таймер (иногда SysTick) и он
генерирует прерывания с нужным мне дискретом (обычно 10 мс). - my504(28.05.2023 15:54)