Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, netch80, Вы писали:

V>>>Просто в цикле крутишь несколько счетчиков параллельно, при обнулении счетчика выдаёшь сигнал.
N>>А некоторые не крутишь, ибо закончились. А код, по твоему варианту, крутит их всех.

V>Верно, просто где-то слагаемое будет равно 0-лю или соотв. бит будет нулевой, если несколько счетчиков упакованы в одном слове.

Метод реализации тут действительно не сильно важен. Просто код вида

  while (do1 || do2 || do3) {
    if (do1) { if (++cnt1 == lim1) { do1 = work1(); } else { delay_some(); } }
    if (do2) { if (++cnt2 == lim2) { do2 = work2(); } else { delay_some(); } }
    if (do3) { if (++cnt3 == lim3) { do3 = work3(); } else { delay_some(); } }
  }

(ты ведь такое имел в виду?) Так это, конечно, реализуемо, но не отвечает ни на один из поднятых мной вопросов о качестве синхронизации внешних акций в таком исполнении.

V>Тут наоборот — похоже, что я не могу простейший алгоритм объяснить.

Ну вот я даже код навёл. Теперь скажи, что в нём не так, по твоему мнению. Он писался максимально близко к тому, как ты объясняешь. (Я-то могу сказать, что по-моему в нём не то, но важно именно то, куда ты пойдёшь исправлять.)

V>>>>>2. Точность таймера с учётом времени реакции на прерывание может не удовлетворять требуемым скоростям (скоростям обработки детали, например).
N>>>>Это же какой контроллер надо подобрать, чтобы он на прерывание реагировал дольше, чем длится 2-3 команды?
V>>>Любой, с длиной конвейера больше 2-х, вестимо.
N>>Воистину фейспалм — писали контроллеры такие же "спецы", если у них прерывание не может врезаться в конвейер, когда это действительно нужно.
V>Ага, но ты же коммунист, Петька! — и пулемёт застрочил вновь.
V>Удивляют порой коллеги верой в мифы и вообще вот этот подход — "оно там как-то само всё образуется".
V>Да никогда еще ни разу "само собой" ничего не образовалось. Всегда надо включать моск.

Ну вот я и включаю. Поведение подобных процессоров определено для такта, не так ли? Если на такте t поднялось прерывание таймера, то, например, на t+2 его заметил блок прерываний процессора, на t+3 уже пошла грузиться команда с нового адреса. (Предполагаю, что если думают о скорости, то отработка прерываний это сохранение PC+PSW в служебные регистры процессора и загрузка новых из таких же служебных, оперативная память тут не используется.) Декодиться и исполняться она будет, например, от t+4 до t+7. И что, эта поправка не может быть заложена в задание таймера?

N>>Хотя им это не нужно — они же поллят и получают ту же проблему с конвейером и без прерываний

V>Не получают. Фронт может немного "дрожать", но не более, чем получили бы такое дрожание при реакции на самое первое аппаратное прерывание.
V>Главное, что ошибка такого дрожания задержки затем не накапливается от слова совсем. А если еще задействовать механизм фазовой автоподстройки для этого цикла, так вообще сколь угодно точно можно импульсы выдавать — с точностью фазы до одного nop, т.е. одного такта.
V>>>В любом случае, для сценари использования таймера "выдай мне прерывание через столько-то времени" (а там именно такой сценарий) — это будет накопление ошибки, бо обычно у тебя нет никакой информации о том, сколько действительно времени потребовалось на реакцию на таймер. А когда таймеров более одного, ты находишься в обработке прерывания одного из них, прерывания от других запрещены... Дальше продолжать или уже догадался?
N>>Двойной фейспалм — вместо таймеров использовать туалетную бумагу, которая не в состоянии показать даже текущее время.

V>Увы, именно так. Зря ты отказался хотя бы одним глазом взглянуть на даташиты.

Да видел я их. Я не запоминаю, за отсутствием прямой необходимости, в какой из современных рахитектур какое именно убожество применено и выдано за новейшие достижения нейтринной мегалоплазмы, но общие тенденции отслеживаю. Конкретно по таймерам, единственная нормальная реализация это счётчик времени (в нормальном режиме вообще не корректируемый) плюс декременторы (один или больше), как в PowerPC, или компараторы (на малость беззнаковой разницы, а не просто на больше-либо-равно). Почти нормальная — это с компаратором на больше-либо-равно (как в HPET). Если же счётчик времени одновременно и декрементор, как было в i8254 и как сейчас делают во многих встраиваемых — он кроме как на подтирку и не годится.

V>Чтобы "показать текущее время" при наличии только 16-тиразрядных таймеров в той же архитектуре STM32 — это надо еще прилично кода вокруг такого таймера городить на ровном месте. И так будешь всё глубже и глубже закапываться в преодоление на каждом шаге очередных граблей, которые сам же решил и разложить перед собой. А ведь можно взять самый простой чип и обойтись программкой в пол-сотни строчек на асме основного цикла (не берем строчки на инициализацию режимов контроллера).

Ну тогда это порочный круг. Одни "спецы" вместо нормальных таймеров подсовывают тошнотворные пародии. Другие не просто соглашаются с этим работать (вместо того, чтобы вывалять первых в дёгте и перьях), но и хвалят свои решения, которые обходят проблемы этих пародий.
И это не только в таймерах, просто мы сейчас говорим о них.

N>>Ну и "спец", который рассказал про событие от одного таймера во время прерывания другого, но точно так же забыл про событие от одного таймера во время поллинга группы таймеров, по рецепту этого же "спеца".
V>Это ты забыл, что циклы у нас имеют фиксированную длительность, т.е. сработал некий софтовый таймер или нет — ничего не изменится, по-сути.

Отлично. А теперь скажи, что получится, если у тебя будет необходимость выполнить воздействие двум разным двигателям с интервалом меньше, чем эта длительность отработки одного двигателя. Например, work1() и delay() в коде выше — по 2 мкс, а тебе надо что-то сделать для 1 и 2 с разницей в 1 мкс. Будешь специально писать отработку подобного варианта? Ну так она в итоге ничем не будет отличаться от решения типа "выбрать ближайшее время из трёх и подождать до него".

N>>Твой образ на RSDN никакого ликбеза провести не в состоянии — ему самому в школу идти надо, с нуля.

V>Вот поэтому и скучно, что объяснять совсем уж с 0-ля — это надо в школе, а не на этом сайте.
V>В принципе, тут достаточно было включить воображение или накатать несколько строчек, чтобы прикинуть — как такие циклы могут выглядеть.

Я и прикинул несколько вариантов. И все они кривые. Видимо, объяснять у тебя таки проблемы. А самому показать псевдокод ты тоже не хочешь — корона свалится.

V>Мне вообще странен подобный игнор некоторыми коллегами того факта, что на один современный центральный проц приходится чуть ли не десяток вспомогательных процов в остальных подсистемах их компов. На них программы по-твоему боги пишут? ))

С чего идеи про игнор? И что зависит от качества программистов для этих вспомогательных, кроме очевидного фактора корректности результата?

V>Такие программисты и пишут. Ну разве что у них обязательно наблюдается такая особенность как внимательность к мелочам, в отличие от разработчиков цепочек if-ов для обслуживания протокола SIP, например.

Я уже так давно не работал с SIP, что не могу понять, это в мой огород камень или нет. Но длинных цепочек ifʼов в своём коде я что-то не помню.