Не надо делать мне как лучше, оставьте мне как хорошо
-
- А не боитесь получить гонки сигналов, в виде эпизодов,
длительностью полторы-две секунды, когда "почему-то" до
низкоприоритетной задачи вообще не доходит управление? - Cкpипaч(24.02.2025 19:25)
- Не, у меня таких длинных задач нет. Все долгое порублено на отдельные состояния и выполняется кусками в несколько проходов. - LightElf(24.02.2025 20:10)
- Так это не для высоконагруженных задач, так, уменьшить время
реакции на некоторые события. Нечасто применяю, но иногда удобно. - Andreas(24.02.2025 19:29)
- Не понимаю. Сколько у вас наихудшее ожидаемое полное время
выполнения цикла биглуп? - Cкpипaч(24.02.2025 19:33)
- Это что-то на умном. Есть 5...7..10 обработчиков флагов(в т.ч таймеров) по 50..100мкс и такая система позволяет каждые 100мкс опрашивать самое важное и чуть с большим разбросом менее важное. Например прием DMX RC5 и что-то еще подобное. Пропуски возможны, но нежелательны/ - Andreas(24.02.2025 19:43)
- Не понимаю. Сколько у вас наихудшее ожидаемое полное время
выполнения цикла биглуп? - Cкpипaч(24.02.2025 19:33)
- А у вас задачи не оформлены как функции? У меня, полный прогон
биглупа со всеми функциями укладывается в одну милисекунду (а может
быть и в сто раз меньше, давно не мерял). Cкpипaч(109 знак., 24.02.2025 19:22)
- Если надо быстро где-то не в прерывании и приоритеты важны, то идут
if по флагам и если флаг установлен и вызвана функция обработки, то
потом не дальше, а в начало. - Andreas(24.02.2025 19:26)
- Непонятно. Предполагается что "инкапсуляция данных" есть правильный
дзен и биглуп ничего не знает о флагах и прочей внутренней кухне
задач в нём. Или у вас "инкапсуляция - не догма"? - Cкpипaч(24.02.2025 19:31)
- Не, не догма, это для небольших проектов. Зато позволяет некоторые
прерывания поллингом заменить. - Andreas(24.02.2025 19:34)
- А зачем заменять прерывания поллингом? (я не зануда, но у меня тоже
очень небольшие проекты и очень интересен ваш опыт) - Cкpипaч(24.02.2025 19:37)
- Чтобы в приоритетах не запутаться, не на все прерывания есть. Это
не отменяет ессно прерывания, но позволяет сократить их число и
длительность. - Andreas(24.02.2025 19:46)
- Там где нет прерываний я использую прерывание от таймера. Одно.
Этакий "биглуп на выезде". - Cкpипaч(24.02.2025 19:54)
- А что это дает, кроме фиксированного кванта времени? - Andreas(24.02.2025 19:56)
- Ничего. Это единственная цель. - Cкpипaч(24.02.2025 19:59)
- А что это дает, кроме фиксированного кванта времени? - Andreas(24.02.2025 19:56)
- Там где нет прерываний я использую прерывание от таймера. Одно.
Этакий "биглуп на выезде". - Cкpипaч(24.02.2025 19:54)
- Чтобы в приоритетах не запутаться, не на все прерывания есть. Это
не отменяет ессно прерывания, но позволяет сократить их число и
длительность. - Andreas(24.02.2025 19:46)
- А зачем заменять прерывания поллингом? (я не зануда, но у меня тоже
очень небольшие проекты и очень интересен ваш опыт) - Cкpипaч(24.02.2025 19:37)
- Не, не догма, это для небольших проектов. Зато позволяет некоторые
прерывания поллингом заменить. - Andreas(24.02.2025 19:34)
- Непонятно. Предполагается что "инкапсуляция данных" есть правильный
дзен и биглуп ничего не знает о флагах и прочей внутренней кухне
задач в нём. Или у вас "инкапсуляция - не догма"? - Cкpипaч(24.02.2025 19:31)
- Оформлены как функции. Но иногда в одном проходе цикла срабатывают
несколько функций (у одной таймаут истек, у другой событие
пробуждающее появилось, у третьей еще какая шляпа). И задача,
сидящая в начале списка (конкретно - разбор принятых пакетов
Ethernet) очень долго ждет своей очереди. Происходит такое нечасто,
но очень неприятно. - LightElf(24.02.2025 19:24)
- Может быть проще между задачами всегда давать квант времени ethernet'у? - Cкpипaч(24.02.2025 19:28)
- Хорошая идея, спасибо! - LightElf(24.02.2025 19:31)
- Применяю для длительных операций пара-тройку программных "задержек"
в которых и выгребаю то, что пришло в ethernet. Что то срочное
выполняю сразу. Несрочное буферизуется/взводятся флаги. Ну а
"суперсрочное" - в прерываниях. Ну и до сих пор сижу на ENC28 с
аппаратным буфером пакетов - жрут немеряно, но сильно облегчают
жизнь ;) - Гyдвин(24.02.2025 19:47)
- А при использовании прототредов это получается "само". Если медленная задача чего-то ждёт - вызывает при этом xxx.Run() от быстрых. - Samx(25.02.2025 23:32)
- CH579, ептыть. Походу я достиг его пределов ;-) А то, что он
Cortex-M0 и в нем нет DWT->CYCCNT воздуха тоже не озонирует,
тому що профайлить непонятно как. - LightElf(24.02.2025 19:51)
- Да я в курсе откуда ноги растут :) - Гyдвин(24.02.2025 20:16)
- Да, не было бабе забот - завела порося ;-) - LightElf(24.02.2025 20:26)
- Да я в курсе откуда ноги растут :) - Гyдвин(24.02.2025 20:16)
- Применяю для длительных операций пара-тройку программных "задержек"
в которых и выгребаю то, что пришло в ethernet. Что то срочное
выполняю сразу. Несрочное буферизуется/взводятся флаги. Ну а
"суперсрочное" - в прерываниях. Ну и до сих пор сижу на ENC28 с
аппаратным буфером пакетов - жрут немеряно, но сильно облегчают
жизнь ;) - Гyдвин(24.02.2025 19:47)
- Хорошая идея, спасибо! - LightElf(24.02.2025 19:31)
- Какова ожидаемая худшая длительность цикла? Все же событие ethernet может не обязательно в начале биглуп произойти... - Cкpипaч(24.02.2025 19:27)
- Может быть проще между задачами всегда давать квант времени ethernet'у? - Cкpипaч(24.02.2025 19:28)
- Если надо быстро где-то не в прерывании и приоритеты важны, то идут
if по флагам и если флаг установлен и вызвана функция обработки, то
потом не дальше, а в начало. - Andreas(24.02.2025 19:26)
- А не боитесь получить гонки сигналов, в виде эпизодов,
длительностью полторы-две секунды, когда "почему-то" до
низкоприоритетной задачи вообще не доходит управление? - Cкpипaч(24.02.2025 19:25)