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

V>while(true) {
V> acc1 += step1;
V> acc2 += step2;
V> byte result = ((acc1 & 0x80000000) >> 30) | ((acc2 & 0x80000000) >> 31);
V> outp(some_port, result);

V> calc_next_values_of_step1_and_step2();
V>}
V>[/ccode]
V>Заметь, что пара управляющих сигналов выводится синхронно.

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

Ага, вот с этих точек уже понятно. Предрасчёт разметки под управление.
step1, step2 вычисляются делением. Это дорогая операция; возможно, у тебя аналогично она делается в свободное время, или используется готовая таблица обратных чисел.
Особой ценности в выводе двух сигналов одновременно я не вижу, но предположим, что для какой-то аппаратуры это важно.

В этой схеме нет возможности подстроиться под внешние влияния на ходу. Нет детекта реальной исполняемости (ты рядом писал про разную скорость вращения детали в зависимости от специфики текущей обработки; будет ли это также важно для управления шаговыми двигателями? управляется ли собственно вращение деталью шаговым двигателем, или там просто силовое воздействие?) Именно это — то, на что я не закладывался в своих предположениях; наоборот, я всегда предполагаю такой код, который в состоянии проверить выполнение своих внешних воздействий в любой момент. Похоже, для части embedded это не лучший вариант, и можно залагаться на то, что некоторое время мы, как носорог, идём вслепую

V>Понятно, что операция навроде ((acc1 & 0x80000000) >> 31) вычисляется в реальности лишь однажды или вообще заменяется условным исполнением/пропуском (и всё-равно лишь однажды). Т.е. на асме это всё еще выразительней получается, бо в C++ слишком многословно и не верно. Там надо признак переполнения прибавить к индексу. Просто для выражения этого в С потребуется заводить переменную двойной ширины только ради опроса младшего бита старшего слова.

Это уже не так важно для общей концепции.

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

V>Согласен, твой код не отвечает ни на один из вопросов.
V>Более того, он позволяет делить тактовую частоту (пусть нам требуется в некоей задаче генерировать некую частоту) лишь на целые числа.

С чего это? В моём построении за это отвечает установка следующего лимита. В твоём — шага.

N>>Ну вот я даже код навёл. Теперь скажи, что в нём не так, по твоему мнению.

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

Да. У нас фирма уходила от этого по максимуму (я даже местами удивлялся). Вся трансформация кодеков и т.п. — на внешние чужие изделия, в крайнем случае (для всяких MOH) — на астериск/аналог.

V> Потому что если бы касался, то ты хотя бы раз в жизни писал генератор синусоиды, который пишется примерно так:

Генератор синусоиды писал. Не на заказ. Таки на явных синусах, потому что не было причины тут экономить.
Дальше — по таблице готовых значений. Для того железа скорость и затраты по памяти устраивали с головой.

V>

V>unsigned phase = 0;
V>const unsigned delta = ulong64_t(MAX_UINT32)*freq/sample_rate;

V>unsigned sin_gen_next() {
V>    return fixed_point_sin(phase+=delta);
V>}
V>

V>Заметь, не надо сравнивать на каждом шаге и по результату отнимать 2*PI.
V>Классика вычислений с фиксированной точкой — это масштабирование любых данных. В данном случае диапазон 0..2*PI отмасштабирован на диапазон 0..MAX_UINT. Причем, получили честную точность 32 разряда, в отличие от точности 24 разряда в случае использования float.

Только ты самое вкусное и важное тут не показал — как этот fixed_point_sin() устроен. В таблицу 2**32 значений я не верю. Таблица значений с фиксированным шагом, и аппроксимация промежуточных точек? Тогда на аппроксимации тоже нужно применить арифметику без плавучки и делений на неконстанты.
Я предположу, что есть таблица, например, на 1024 значения. Может, ещё меньше. Дальше — интерполяция через сдвиг и сложение.
И, кстати, "честные 32 разряда" тут по большей части просто шум.

А ещё у тебя может оказаться, что истинное freq/sample_rate нецелое. Тогда ты одной простой delta не обойдёшься.

N>>Ну вот я и включаю. Поведение подобных процессоров определено для такта, не так ли? Если на такте t поднялось прерывание таймера, то, например, на t+2 его заметил блок прерываний процессора, на t+3 уже пошла грузиться команда с нового адреса.
V>А еще надо запихать текущую инструкцию в стек.

Мнэээ... стек чего? Или ты про сохранение старого PC в стек? Это обсуждаем ниже.

N>>(Предполагаю, что если думают о скорости, то отработка прерываний это сохранение PC+PSW в служебные регистры процессора и загрузка новых из таких же служебных, оперативная память тут не используется.)
V>В контроллерах его внутреннюю оперативную память можно рассматривать как продолжение файла регистров, там точно такая же скорость обращения, бо это регистровая память, как L0.

Значит, пусть пишет по фиксированному адресу.

N>>Декодиться и исполняться она будет, например, от t+4 до t+7. И что, эта поправка не может быть заложена в задание таймера?
V>А как ты думаешь, почему у "самоделкиных" их фрезерные и токарные станки работают примерно в 10-100 раз медленней, чем промышленные экземпляры?

Я вообще не в курсе обстановки у станков

V>Может от того, что при выдаваемой ими ужасной временнОй точности управления приходится в 10-100 раз снижать скорость перемещения резака относительно детали? ))
V>Разумеется, любую погрешность можно учесть и компенсировать, но я ж сходу упомянул, каким именно образом.

Не очень. Обратной связи в твоей схеме как-то не видно. А мне как-то стрёмно видеть на своём выходе изделия, которые способны на такое, как тот автопогрузчик, что завалил целый склад от того, что что-то вдруг оказалось на пути.
Потеря заготовки от того, что шаг не выполнился, тоже неприятна.

N>>Да видел я их. Я не запоминаю, за отсутствием прямой необходимости, в какой из современных рахитектур какое именно убожество применено и выдано за новейшие достижения нейтринной мегалоплазмы

V>Дык, в архитектуре Intel с таймерами еще на пару порядков всё печальнее. Там вообще полная ж-па. У тебя на сегодня нет никакой возможности узнать текущее точное время. У тебя на выбор только правильно идущие часы с точностью ~1/64 сек или еще есть часы с хорошей точностью, но всегда идущие неправильно (query performance counter).

Мнэээ? Как минимум есть ещё PIIX/ACPI timer, APIC timer, HPET main counter. Тут уже ты явно отстал от нынешних реалий. И что ты назвал "неправильно идущие"? Если постоянный темп, то один раз зафиксировать смещение от внешнего времени (если оно вообще нужно) и потом его прибавлять — задача тривиальная даже для embedded
И откуда цифра 1/64? Ни один из известных мне таймеров системы Wintel не знает такой точности. Ты, наверно, вспомнил 1/18 — это то, что получится, если i8254 запрограммировать на максимальный период (65536) и считать только его прерывания, без чтения текущего значения счётчика.

N>>это счётчик времени
V>Ага. Тактовая этого счётчика какова? А разрядность? А время доступа к нему?

Тактовая — для embedded, должна совпадать с тактовой процессора, ну в крайнем случае в 2-4 раза ниже. Для обычного компа — годится сейчас от ~10 МГц.
Разрядность — такая, чтобы было минимум с 2-3-кратным запасом от максимального времени, на сколько можно позволить себе выключать прерывания. Например, 32-разрядный (копейки, по нынешним временам) и при 1ГГц тактовой (фантастически высокое для embedded, да?) это более 4 секунд => хватит с головой.
Время доступа — как к обычной ячейке памяти (SRAM), кэша.

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

Да понятно, что можно обойти (для большинства случаев) подобные грабли. Вопрос, насколько это грязно и совместимо с некоторыми другими требованиями.
Например, перепрограммирование i8254 всегда теряет точность на самом этом процессе. А это сейчас достаточно типичное требование — менять темп прерываний или даже заказывать на конкретные моменты. Если использовать другой clocksource, проблемы с точностью счёта времени уже нет. Хотя в HPET, например, компараторы глупые, иногда и там можно потерять кусочек.

V>Просто ты заведомо неверно судишь о происходящем. Судить технические подходы можно лишь по некоторым критериям, где критерии обязательно зависят от самих же технических подробностей. ))

От _других_ технических подробностей. А так — да, embedded чудовищно широк, и мой опыт с твоим, похоже, пересекается минимально. Потому я на те твои подробности, которые создают твои критерии, смотрю временами, как баран на новые ворота.

V>Ты же взял некие абстрактные критерии, где ни один из них не является важным для обсуждаемой предметной области.
V>Да тут не то, что в области низкоуровневых микроконтроллеров... тут даже в деле написания банальнейших дров под высокоуровневый ЦПУ на твоей машине — и уже твои критерии не работают. Ты слишком прикладной программист.

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

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

V>Выделил ошибку.
V>Не у меня, а у тебя.
V>У тебя там не получится ничего, ес-но, как ты сам абсолютно правильно сейчас подметил.
V>Только зачем тогда было приводить заведомо неработающий код?

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

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

Ну когда ты, претендуя на звание инженера, ведёшь себя как гуманитарий — заказчик дизайна, естественно, что обижаюсь

N>>И что зависит от качества программистов для этих вспомогательных, кроме очевидного фактора корректности результата?
V>Тут тоже ХЗ. Но есть наблюдения — примерно половине программистов этот род деятельности не даётся вообще никак ни под каким видом. Хоть кол на голове им теши или даже под страхом расстрела. Казалось бы — там всё СЛИШКОМ элементарно... человек запросто пишет довольно-таки большие проги, использует сложные библиотеки и т.д... А вот просто пару бит туда-сюда погонять — полный ступор.

В теме обучения высокому программированию я, извини, не копенгаген, хоть и стараюсь собирать данные по этому поводу (и персональные ученики в виде собственных детей и племянников хоть какие-то основы, но поняли). Но вопрос задам — может, у них таки проблемы с основами, и надо было погонять начиная с систем счисления и булевых операций?
Или ты опять имел в виду одно, а выразился про другое? Например, фокусы с предрассчитанными таблицами это приём, который надо не просто знать — надо тренироваться или в ТРИЗ/etc., или в практике именно такого кодинга.

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

V>Если "раскрыть все скобки" (сделать все ф-ии инлайными в том коде), то будет просто масса ветвлений и всё.

Вот опять — какой "тот" код?

V>Собсно, я еще тогда подробно объяснял этот фатальный недостаток SIP — это отсутствие встроенных ср-в комбинирования сценариев. Любая комбинация сценариев должна быть прописана в очередном расширении стандарта. Вот что я называю каменным веком. Протокол SIP был разработан, очевидно, потребителями технологий, а не производителями. Они взяли RTP, который был до них, они взяли TCP и сделали самую большую каку в истории VoIP. Более непоследовательного, непродуманного, ограниченного в развитии и т.д. до бесконечности протокола — просто не существует.

SIP придуман несколькими фирмами — производителями VoIP. Или ты думаешь, что внутри этих фирм им занялись совершенно не те люди?
Протокол местами чудовищно сложен, это факт. Я, пока работал вокруг него, так и не довёл до ума некоторые вроде бы базовые вещи. Банально не хватило времени и терпения, хотя планы были. Мне больше всего не нравится именно взаимовлияние FSM диалога и сессии. А что со сценариями, хоть один пример?

V>Мне SIP напоминает творчество тех самых админов Linux, где половина программы у них живет в конфиге, ы-ы-ы.

Вроде на sendmail не похоже

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

SIP был разработан под эгидой IETF. Это видно, например, по чрезмерной грамматичности. Но признаков участия именно админов я там не вижу.