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

K>Что ARM — не [чистый] RISC

Давно.
Например, Cortex-A — это не RISC ни в каком из мест, а Cortex-R — практически чистый RISC, предназначен для того самого hard realtime.

Система команд у этих веток практически идентичная (за исключением нескольких расширений).


K>или что у RISC-ов не бывает out-of-order?

Бывает OoO реализации процов на некую систему команд, которая появилась изначально для некоего RISC-процессора.

Строгое разделение архитектур на RISC и CISC осталось в 90-х. Сейчас уже понятно, что "выжили" единицы архитектур, но выжили сугубо в терминах абстракций их системы команд/регистров, т.е. ISA. Сегодня на эти "абстракции" натягиваются различные подходы в реализации.

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

K>>или что у RISC-ов не бывает out-of-order?
V>Бывает OoO реализации процов на некую систему команд, которая появилась изначально для некоего RISC-процессора.

Power, Alpha, RISC-V изначально создавались под идею "от самых мелких с минимумом конвейера до старших с out-of-order".

V>Строгое разделение архитектур на RISC и CISC осталось в 90-х. Сейчас уже понятно, что "выжили" единицы архитектур, но выжили сугубо в терминах абстракций их системы команд/регистров, т.е. ISA. Сегодня на эти "абстракции" натягиваются различные подходы в реализации.

Мощно задвинул (tm)

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

N>>Кэшу он не противоречит, если в закладках по времени рассчитать вариант "кэш полностью заполнен чужим содержимым"
K>А, ну-ну. Тогда и на винде можно делать очень даже Hard realtime

Можно запросто на уровне ядра и ядерных дров.
Только не факт, что вообще имеет смысл вводить разделение на уровни исполнения в специализированной железке. Бред же...


K>если записать в спеке, что любая операция должна выполняться не более секунды.

1. у прерываний есть приоритеты
2. код с нужными привилегиями может запретить некие прерывания на некоем участке.

Хотя, этот спор заведомо ни о чем. ))

Я не знаю, каким махровым нубом надо быть, чтобы предполагать, что система обнаружения и управления радаром (для примера) будет управляться юзверским приложением на какой-нить обычной Linux. Это просто пробитие дна какое-то...

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

N>Я такие циклы фиксированной длительности помню из более знаменитого источника — драйвер диска для Apple II. 32 или 40 тактов на байт, в зависимости от части дорожки, циклы с NOP-PHA-PLA-etc. для выдерживания ровно нужного количества тактов 6502. И что, это хорошо?
N>По-моему, это всё тупой закат солнца вручную.

Дык, ничего не изменилось с тех пор. Просто сейчас аналогичная программа перенесена из ЦПУ в контроллер, расположенный прямо прямо на диске.


N>Шаговый двигатель там тоже управлялся, было. Аж ностальгия скоро пробьёт. Зато как сейчас хорошо всей этой дурью не маяться.

Кому хорошо, тебе лично?
Значит тебе интересней другой род программирования, только и всего.


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

Прогресс — это удешевление конечного устройства и ускорение цикла разработка->продажа.
Всё остальное называется "программист ниасилил". ))


N>>>И в чём тогда разница этих предметных областей? Чем, по-твоему, так принципиально отличается то, что в MIPS, от SSE образца x86?
V>>Тем, что не происходило переименования регистров, вестимо. И что программист достоверно знает, сколько там АЛУ и что там происходит.
N>Чем же это лучше? Если нельзя развивать архитектуру с тем, чтобы не переписывать код?

Для конкретного озвучиваемого железа это не важно.
Всё-равно под каждую конкретную железку будет свой "драйвер".


N>Ты же делаешь вид, что всё всегда знаешь

По темам, по которым высказываюсь и в тех объемах, в которых высказываюсь?
ИМХО, это единственно адекватная стратегия.
Остальное должно быть или прямо поставленными вопросами (без ужимок, прыжков, подъ-бок, желания "поймать" и т.д.) или read-only.

Здравствуйте, Иван Дубров, Вы писали:

ИД>А можно чуть по-подробнее, что не так с таймерами, в случае с шаговым двигателем?

Зависит от.

1. Таймеров конечное кол-во.
2. Точность таймера с учётом времени реакции на прерывание может не удовлетворять требуемым скоростям (скоростям обработки детали, например).
3. Выделяя отдельный аппаратный блок под каждую элементарную операцию можно получить не самое оптимальное по цене решение.
4. В задачах управления более чем одним шаговым двигателем всё еще печальнее.

По собственному опыту, на "толерантое буферирование" лучше отводить ввод-вывод, как популярный пример — по I2C, т.е. удобней иметь асинхронность лишь по линиям передачи информации. Всё остальное можно с относительно большой точностью делать в софте на самых дешевых RISC-контроллерах, а запас по цене лучше "тратить" на более высокую тактовую — это немного развязывает руки.

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

N>>Я такие циклы фиксированной длительности помню из более знаменитого источника — драйвер диска для Apple II. 32 или 40 тактов на байт, в зависимости от части дорожки, циклы с NOP-PHA-PLA-etc. для выдерживания ровно нужного количества тактов 6502. И что, это хорошо?
N>>По-моему, это всё тупой закат солнца вручную.
V>Дык, ничего не изменилось с тех пор. Просто сейчас аналогичная программа перенесена из ЦПУ в контроллер, расположенный прямо прямо на диске.

А с другой стороны с ним хочет общаться ЦП через SATA/USB/etc... опс, а чего это у нас устройство не отвечает? О, два контроллера. Вместо одного. И у каждого по процессору. Привет, синхронизация.

N>>Шаговый двигатель там тоже управлялся, было. Аж ностальгия скоро пробьёт. Зато как сейчас хорошо всей этой дурью не маяться.
V>Кому хорошо, тебе лично?
V>Значит тебе интересней другой род программирования, только и всего.

Согласен, мне неинтересен род программирования "пока мы с одним кем-то общаемся с выдерживанием наносекунд, остальные курят бамбук". Сколько уходили от этого на всех уровнях, а вот особо некоторые железячники продолжают тянуть нас обратно и вгонять в команды процессора то, что давно ушло из него.

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

Нет, это называется — китайский дерьмогон.
Всё на процессор! Урежем спеки, купим самое дешевое *овно, вобьём стандартный основной план работы в код. На полдоллара дешевле конкурентов, уря!
А потом и начинается — то вдруг errata "ой, мы поспешили сказать, что поддерживаем 8 параллельных запросов, урежьте до 4", или "хотите туннель? лимиты разделить на 3. шифрование? ещё на 5. да, мы этого в основной спеке не скажем, только в дополнительной и под NDA."
Зато быстро, хе-хе.
Я теперь понял, на кого ты работаешь, и почему такую идеологию продвигаешь.

N>>>>И в чём тогда разница этих предметных областей? Чем, по-твоему, так принципиально отличается то, что в MIPS, от SSE образца x86?
V>>>Тем, что не происходило переименования регистров, вестимо. И что программист достоверно знает, сколько там АЛУ и что там происходит.
N>>Чем же это лучше? Если нельзя развивать архитектуру с тем, чтобы не переписывать код?
V>Для конкретного озвучиваемого железа это не важно.
V>Всё-равно под каждую конкретную железку будет свой "драйвер".

Агащазз. Перенесут готовое и не задумаются. Даже если без тебя. Arian и Therac-25 на поверхности, а сколько таких не попало в газеты?

N>>Ты же делаешь вид, что всё всегда знаешь
V>По темам, по которым высказываюсь и в тех объемах, в которых высказываюсь?
V>ИМХО, это единственно адекватная стратегия.

Спасибо, занёс в протокол

V>Остальное должно быть или прямо поставленными вопросами (без ужимок, прыжков, подъ-бок, желания "поймать" и т.д.) или read-only.

Ну да, только можно самого себя по 2 раза на день опровергать Зато прямо и честно

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

ИД>>А можно чуть по-подробнее, что не так с таймерами, в случае с шаговым двигателем?

V>Зависит от.

V>1. Таймеров конечное кол-во.
V>4. В задачах управления более чем одним шаговым двигателем всё еще печальнее.

И сидят три процессора и рулят каждый своим шаговым двигателем, отсчитывая nopʼами задержку... ой, нет трёх процессоров? Какой облом. Значит, таймеры в софте, очередь ближайших срабатывающих (ну, сделана массивом или вообще явным тестом на каждой итерации — неважно)? А как же пункт 1?

V>2. Точность таймера с учётом времени реакции на прерывание может не удовлетворять требуемым скоростям (скоростям обработки детали, например).

Это же какой контроллер надо подобрать, чтобы он на прерывание реагировал дольше, чем длится 2-3 команды? Впрочем, знаю. Там должны быть кэш DRAM, OoO исполнение команд... ой, а откуда это он у нас такой? Кто его сюда поставил?

V>3. Выделяя отдельный аппаратный блок под каждую элементарную операцию можно получить не самое оптимальное по цене решение.

А кто сказал "под каждую"?

V>Собсно, все современные сигнальные процы — VLIW. Есть на ноуте/планшете Bluetooth? — там живет сигнальный процессор. Есть WiFi — аналогично.

В WiFi VLIW нет (из опыта с одним очень распространенным производителем вайфай чипов, и одним не очень). В Bluetooth похоже тоже нет.

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

N>И сидят три процессора и рулят каждый своим шаговым двигателем, отсчитывая nopʼами задержку... ой, нет трёх процессоров? Какой облом. Значит, таймеры в софте, очередь ближайших срабатывающих (ну, сделана массивом или вообще явным тестом

Каким "тестом"?
Что тестировать-то?
Просто в цикле крутишь несколько счетчиков параллельно, при обнулении счетчика выдаёшь сигнал.

Причем, в одном слове можно располагать несколько счетчиков обычно.


N>на каждой итерации — неважно)? А как же пункт 1?

Это ты слишком сложные для себя вопросы пока задаешь. ))


V>>2. Точность таймера с учётом времени реакции на прерывание может не удовлетворять требуемым скоростям (скоростям обработки детали, например).
N>Это же какой контроллер надо подобрать, чтобы он на прерывание реагировал дольше, чем длится 2-3 команды?

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


N>Там должны быть кэш DRAM, OoO исполнение команд... ой, а откуда это он у нас такой? Кто его сюда поставил?

Ну вот опять. В неприличной форме напрашиваешься на грубый ликбез.
Скучно...

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

G>В WiFi VLIW нет (из опыта с одним очень распространенным производителем вайфай чипов, и одним не очень). В Bluetooth похоже тоже нет.

В Broadcom есть. А по другим производителям инфа совсем скупая.

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

N>>И сидят три процессора и рулят каждый своим шаговым двигателем, отсчитывая nopʼами задержку... ой, нет трёх процессоров? Какой облом. Значит, таймеры в софте, очередь ближайших срабатывающих (ну, сделана массивом или вообще явным тестом

V>Каким "тестом"?
V>Что тестировать-то?
V>Просто в цикле крутишь несколько счетчиков параллельно, при обнулении счетчика выдаёшь сигнал.

А некоторые не крутишь, ибо закончились. А код, по твоему варианту, крутит их всех.

V>Причем, в одном слове можно располагать несколько счетчиков обычно.
N>>на каждой итерации — неважно)? А как же пункт 1?
V>Это ты слишком сложные для себя вопросы пока задаешь. ))

Это ты не можешь простейший алгоритм в голове уложить, чтобы не ляпнуть по-тупому такое, что смеются не только лишь все (tm).

V>>>2. Точность таймера с учётом времени реакции на прерывание может не удовлетворять требуемым скоростям (скоростям обработки детали, например).
N>>Это же какой контроллер надо подобрать, чтобы он на прерывание реагировал дольше, чем длится 2-3 команды?
V>Любой, с длиной конвейера больше 2-х, вестимо.

Воистину фейспалм — писали контроллеры такие же "спецы", если у них прерывание не может врезаться в конвейер, когда это действительно нужно. Хотя им это не нужно — они же поллят и получают ту же проблему с конвейером и без прерываний

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

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

N>>Там должны быть кэш DRAM, OoO исполнение команд... ой, а откуда это он у нас такой? Кто его сюда поставил?
V>Ну вот опять. В неприличной форме напрашиваешься на грубый ликбез.
V>Скучно...

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

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

V>Я не знаю, каким махровым нубом надо быть, чтобы предполагать, что система обнаружения и управления радаром (для примера) будет управляться юзверским приложением на какой-нить обычной Linux. Это просто пробитие дна какое-то...

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

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

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

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


V>>Причем, в одном слове можно располагать несколько счетчиков обычно.
N>>>на каждой итерации — неважно)? А как же пункт 1?
V>>Это ты слишком сложные для себя вопросы пока задаешь. ))
N>Это ты не можешь простейший алгоритм в голове уложить, чтобы не ляпнуть по-тупому такое, что смеются не только лишь все (tm).

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

V>>>>2. Точность таймера с учётом времени реакции на прерывание может не удовлетворять требуемым скоростям (скоростям обработки детали, например).
N>>>Это же какой контроллер надо подобрать, чтобы он на прерывание реагировал дольше, чем длится 2-3 команды?
V>>Любой, с длиной конвейера больше 2-х, вестимо.

N>Воистину фейспалм — писали контроллеры такие же "спецы", если у них прерывание не может врезаться в конвейер, когда это действительно нужно.

Ага, но ты же коммунист, Петька! — и пулемёт застрочил вновь.
Удивляют порой коллеги верой в мифы и вообще вот этот подход — "оно там как-то само всё образуется".
Да никогда еще ни разу "само собой" ничего не образовалось. Всегда надо включать моск.


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

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


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

N>Двойной фейспалм — вместо таймеров использовать туалетную бумагу, которая не в состоянии показать даже текущее время.

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


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

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


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

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

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

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

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

V>>Я не знаю, каким махровым нубом надо быть, чтобы предполагать, что система обнаружения и управления радаром (для примера) будет управляться юзверским приложением на какой-нить обычной Linux. Это просто пробитие дна какое-то...
K>Достаточно просто представлять уровень бардака в российской военке. Не знаю каких махровым эльфом надо быть, чтобы этого не знать.

Т.е., всё-таки, ракетными системами будет управлять юзверское приложение поверх Linux? ))
Спасибо, ты сделал мой день.

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

V>Типичный цикл контроллера, который сейчас делает то, что раньше делало железо — он фиксирован. Как по-твоему, происходит фазовое детектирование того же WiFi? Ни о каких таймерах там не может быть и речи, ес-но. Там прямо в теле цикла фиксированной длительности

Напомнило детство...

Смотреть с 2:37

Суть:
Кадр имеет разрешение 48*24 блока (4*8 пикселей блок), но отрисовка синхронизирована с лучом развёртки, и ровно каждые 4 скан линии (224 такта в каждой) перерисовывается 24 байта атрибутов, и монитор начинает отображать новую информацию. Что увеличивает разрешение по вертикали вдвое. При этом успеваем выбирать повёрнутые пиксели из текстуры. Внутренний цикл выглядит примерно так: выбор из регистровой пары, инкремент/декремент/nop каждой половинки регистра (а-ля фиксед-поинт), запись в экран, приращение экранного адреса. Код сгенерирован с учётом вектора движения по текстуре. Никаких циклов, ветвлений и проверок — на них нет времени. Никакого разделения поворота и отрисовки уже повёрнутого — не успеешь.

Просто для понимания тормознутости процессора: типичное время исполнение одной команды 4/7/10/12 тактов. Частота 3.5мгц. За один кадр (1/50сек) инструкция блочного копирования LDIR успевает обработать только ~4кб данных. Для ротатора надо успеть обработать 24*48=1152 байт, примерно за 60% кадра. Т.е. быть всего вдвое медленнее чем команда блочного копирования! И не забываем про выравнивание отрисовки до такта, иначе рассинхримся с лучом и ничего не получится.

В нижней части экрана видим бегущую строку. Она бежит вне пиксельной области, т.н. "бордюр", 3 битный порт-регистр, задающий цвет рамки вокруг экрана. Бегушка формируется серией последовательных OUT-ов (и никак иначе, ибо OUT занимает 12 тактов за которые развёртка успевает пробежать 24 пикселя). Серия команд генерится на каждый кадр. И самое весёлое — количество тактов в кадре при любом раскладе должно давать один и тот же остаток от деления на 4, иначе будет рандомный сдвиг на 1-3 двухпиксельных шага по горизонтали. Генератор машкода тоже выровнен по тактам.

Обязательно досмотреть до 3:11, с учётом объяснений про "бордюр" станет ясно, как это устроено. Мы в 1997 реально со стульев попадали, когда увидели.

https://www.youtube.com/watch?v=dl3wWxJmIZw

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

K>>Достаточно просто представлять уровень бардака в российской военке. Не знаю каких махровым эльфом надо быть, чтобы этого не знать.
V>Т.е., всё-таки, ракетными системами будет управлять юзверское приложение поверх Linux? ))
SpaceX использует RT Линукс в системах управления.

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

IID>В нижней части экрана видим бегущую строку. Она бежит вне пиксельной области, т.н. "бордюр", 3 битный порт-регистр, задающий цвет рамки вокруг экрана. Бегушка формируется серией последовательных OUT-ов (и никак иначе, ибо OUT занимает 12 тактов за которые развёртка успевает пробежать 24 пикселя). Серия команд генерится на каждый кадр. И самое весёлое — количество тактов в кадре при любом раскладе должно давать один и тот же остаток от деления на 4, иначе будет рандомный сдвиг на 1-3 двухпиксельных шага по горизонтали. Генератор машкода тоже выровнен по тактам.

Фазовая автоподстройка? ))


IID>Обязательно досмотреть до 3:11, с учётом объяснений про "бордюр" станет ясно, как это устроено. Мы в 1997 реально со стульев попадали, когда увидели.

Не досмотрел. Жаль, что частота развертки моего экрана не кратна исходной частоте развертки.
Такие вещи наблюдал и баловался ими вживую в 90-92-х годах, там когда вживую смотришь, то плавность идеальная, прямо как на Атари тех же времён. ))
По видео этот момент немного теряется, увы.

============
Кстате, раздражает в современных 3D-играх отсутствие той самой плавности смещения картинки и вообще отсутствие плавности любой анимации, которая была когда-то. Сейчас в играх FPS само по себе (да еще и плавающее), а развертка сама по себе. Поэтому, эффект не тот, не тот. ))

Здравствуйте, 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ʼов в своём коде я что-то не помню.

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

K>>>Достаточно просто представлять уровень бардака в российской военке. Не знаю каких махровым эльфом надо быть, чтобы этого не знать.
V>>Т.е., всё-таки, ракетными системами будет управлять юзверское приложение поверх Linux? ))
C>SpaceX использует RT Линукс в системах управления.

RT Линукс — это не Linux. ))
Это микроядерная ОС, в которой можно запустить специальный слой совместимости Linux. А можно и не запускать...
Для отладки удобно, например, т.е. на этапе разработки.

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

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

IID>>В нижней части экрана видим бегущую строку. Она бежит вне пиксельной области, т.н. "бордюр", 3 битный порт-регистр, задающий цвет рамки вокруг экрана. Бегушка формируется серией последовательных OUT-ов (и никак иначе, ибо OUT занимает 12 тактов за которые развёртка успевает пробежать 24 пикселя). Серия команд генерится на каждый кадр. И самое весёлое — количество тактов в кадре при любом раскладе должно давать один и тот же остаток от деления на 4, иначе будет рандомный сдвиг на 1-3 двухпиксельных шага по горизонтали. Генератор машкода тоже выровнен по тактам.

V>Фазовая автоподстройка? ))

Ага.
Т.к. команду посередине не прервёшь, а команда HALT (ожидания прерывания) внутри устроена как бесконечное исполнение NOP-ов (4 такта).

Ещё нужен трюк с первоначальной автоподстройкой, т.к. мы не знаем какое смещение тактов от фронта прерывания было в предыдущем, невыровненном коде.

V>Жаль, что частота развертки моего экрана не кратна исходной частоте развертки.

Включи HD. Иначе ютуб половину кадров выкидывает

V>Кстате, раздражает в современных 3D-играх отсутствие той самой плавности смещения картинки и вообще отсутствие плавности любой анимации, которая была когда-то. Сейчас в играх FPS само по себе (да еще и плавающее), а развертка сама по себе. Поэтому, эффект не тот, не тот. ))

Эффект не тот из-за технологии ЖК матриц, ИМХО. Даже если железо способно вытянуть жёсткий лок на FPS монитора, без просадок.

Есть неплохой сайт с кучей тестов прямо в браузере: https://www.testufo.com/

ЭЛТ их проходит наотлично.
А на ЖК наблюдаются всякие артефакты. Начиная от дрожания краёв (ghosting) и заканчивая искажением цветов в движущейся сетке (не у всех матриц, тест Inversion Artifacts).
Причём наблюдаются на всех типах матриц, что я пробовал: TN/TN+Film/IPS/AMVA+. Ни 4мс, ни 2мс отклик не помогает (для 60fps должно по-идее 16ms хватать). Даже на 100/400hz телике всё хуже, чем на хорошем ЭЛТ.

Товарищ SkyDance уверяет, что на 144hz всё будет плавно, хоть и путается в определении Tearing-а. Верится в это слабо. А до физического теста я пока не добрался (надо ноут в магазины тащить, открыть сайт сами они не могут, пробовал уже).