Здравствуйте, IID, Вы писали:
IID>Ага. IID>Т.к. команду посередине не прервёшь, а команда HALT (ожидания прерывания) внутри устроена как бесконечное исполнение NOP-ов (4 такта).
Ну да, ну да, там же NOP 4 такта. Ну, тут достаточно иметь возможность получить разницу в 1 такт м/у какими-нить двумя командами.
Спасает конечно то, что развертка работает от той же исходной тактовой, что и процессор.
V>>Жаль, что частота развертки моего экрана не кратна исходной частоте развертки. IID>Включи HD. Иначе ютуб половину кадров выкидывает
HD 1080 ))
Всё-равно не то.
Даже на любом из эмуляторов — не то.
Надо саму железку к честному PAL-телеку подключать. ))
Просто, кто не видел подобные вещи вживую — они по ролику ничего не поймут.
V>>Кстате, раздражает в современных 3D-играх отсутствие той самой плавности смещения картинки и вообще отсутствие плавности любой анимации, которая была когда-то. Сейчас в играх FPS само по себе (да еще и плавающее), а развертка сама по себе. Поэтому, эффект не тот, не тот. )) IID>Эффект не тот из-за технологии ЖК матриц, ИМХО. Даже если железо способно вытянуть жёсткий лок на FPS монитора, без просадок. IID>Есть неплохой сайт с кучей тестов прямо в браузере: https://www.testufo.com/
Да, хорошая демонстрация этой фигни, спс. Если следить взглядом за движущейся фигурой, то она кажется расплывчатой вдоль вектора движения. Когда-то в анимации это было первым признаком кривых рук, а сейчас, спустя 25 лет, при в тысячу раз возросших мощностях, фактически нет механизмов это преодолеть. Цирк с конями, как по мне.
IID>ЭЛТ их проходит наотлично. IID>А на ЖК наблюдаются всякие артефакты. Начиная от дрожания краёв (ghosting) и заканчивая искажением цветов в движущейся сетке (не у всех матриц, тест Inversion Artifacts).
По-идее, если ЖК-монитор вносит строго фиксированную задержку, то от ghosting можно было бы избавиться — он же является индикатором неравномерной скорости движения.
IID>Причём наблюдаются на всех типах матриц, что я пробовал: TN/TN+Film/IPS/AMVA+. Ни 4мс, ни 2мс отклик не помогает (для 60fps должно по-идее 16ms хватать). Даже на 100/400hz телике всё хуже, чем на хорошем ЭЛТ.
Т.е. откуда-то берется неравномерность частоты развертки?
(с инверсиями и пост-свечениями всё понятно, но хотя бы дрожание надо как-то уметь побороть?)
Здравствуйте, netch80, Вы писали:
V>>Верно, просто где-то слагаемое будет равно 0-лю или соотв. бит будет нулевой, если несколько счетчиков упакованы в одном слове. N>Метод реализации тут действительно не сильно важен. Просто код вида N>
N> while (do1 || do2 || do3) {
N> if (do1) { if (++cnt1 == lim1) { do1 = work1(); } else { delay_some(); } }
N> if (do2) { if (++cnt2 == lim2) { do2 = work2(); } else { delay_some(); } }
N> if (do3) { if (++cnt3 == lim3) { do3 = work3(); } else { delay_some(); } }
N> }
N>
N>(ты ведь такое имел в виду?)
Конечно нет.
Условного ветвления не требуется в таких алгоритмах, по крайней мере в коде оперирования софтовыми таймерами.
Достаточны манипуляции с битами и простые арифметические операции:
Заметь, что пара управляющих сигналов выводится синхронно.
Ну а для быстродейдствующей обработки какой-нить детали сначала высчитывается некий "батч" (как раз можно использовать время на обратный ход инструмента), а потом этот батч прогоняется, т.е. остальная часть может выглядеть примерно так:
Понятно, что операция навроде ((acc1 & 0x80000000) >> 31) вычисляется в реальности лишь однажды или вообще заменяется условным исполнением/пропуском (и всё-равно лишь однажды). Т.е. на асме это всё еще выразительней получается, бо в C++ слишком многословно и не верно. Там надо признак переполнения прибавить к индексу. Просто для выражения этого в С потребуется заводить переменную двойной ширины только ради опроса младшего бита старшего слова.
N>Так это, конечно, реализуемо, но не отвечает ни на один из поднятых мной вопросов о качестве синхронизации внешних акций в таком исполнении.
Согласен, твой код не отвечает ни на один из вопросов.
Более того, он позволяет делить тактовую частоту (пусть нам требуется в некоей задаче генерировать некую частоту) лишь на целые числа.
N>Ну вот я даже код навёл. Теперь скажи, что в нём не так, по твоему мнению.
В нём не так то, что ты хоть и работал со звуковой областью когда-то, но конкретно темы обработки звука не касался, похоже. Потому что если бы касался, то ты хотя бы раз в жизни писал генератор синусоиды, который пишется примерно так:
Заметь, не надо сравнивать на каждом шаге и по результату отнимать 2*PI.
Классика вычислений с фиксированной точкой — это масштабирование любых данных. В данном случае диапазон 0..2*PI отмасштабирован на диапазон 0..MAX_UINT. Причем, получили честную точность 32 разряда, в отличие от точности 24 разряда в случае использования float.
N>Он писался максимально близко к тому, как ты объясняешь.
Я вижу максимально далёкий код.
N>Ну вот я и включаю. Поведение подобных процессоров определено для такта, не так ли? Если на такте t поднялось прерывание таймера, то, например, на t+2 его заметил блок прерываний процессора, на t+3 уже пошла грузиться команда с нового адреса.
А еще надо запихать текущую инструкцию в стек.
А еще конвейер у нас может быть больше, чем 2 стадии, например 4 стадии. Итого, t+3+4. И запрет прерываний, пока один из таймеров обрабатываем.
N>(Предполагаю, что если думают о скорости, то отработка прерываний это сохранение PC+PSW в служебные регистры процессора и загрузка новых из таких же служебных, оперативная память тут не используется.)
В контроллерах его внутреннюю оперативную память можно рассматривать как продолжение файла регистров, там точно такая же скорость обращения, бо это регистровая память, как L0.
N>Декодиться и исполняться она будет, например, от t+4 до t+7. И что, эта поправка не может быть заложена в задание таймера?
А как ты думаешь, почему у "самоделкиных" их фрезерные и токарные станки работают примерно в 10-100 раз медленней, чем промышленные экземпляры?
Может от того, что при выдаваемой ими ужасной временнОй точности управления приходится в 10-100 раз снижать скорость перемещения резака относительно детали? ))
Разумеется, любую погрешность можно учесть и компенсировать, но я ж сходу упомянул, каким именно образом.
N>Да видел я их. Я не запоминаю, за отсутствием прямой необходимости, в какой из современных рахитектур какое именно убожество применено и выдано за новейшие достижения нейтринной мегалоплазмы
Дык, в архитектуре Intel с таймерами еще на пару порядков всё печальнее. Там вообще полная ж-па. У тебя на сегодня нет никакой возможности узнать текущее точное время. У тебя на выбор только правильно идущие часы с точностью ~1/64 сек или еще есть часы с хорошей точностью, но всегда идущие неправильно (query performance counter).
N>это счётчик времени
Ага. Тактовая этого счётчика какова? А разрядность? А время доступа к нему?
N>Ну тогда это порочный круг. Одни "спецы" вместо нормальных таймеров подсовывают тошнотворные пародии. Другие не просто соглашаются с этим работать (вместо того, чтобы вывалять первых в дёгте и перьях), но и хвалят свои решения, которые обходят проблемы этих пародий. N>И это не только в таймерах, просто мы сейчас говорим о них.
Это дело привычки к определённому классу задач. Когда занимаешься этим постоянно, то подобные задачки решаются уже мозжечком, фактически не потребляя квантов внимания.
Просто ты заведомо неверно судишь о происходящем. Судить технические подходы можно лишь по некоторым критериям, где критерии обязательно зависят от самих же технических подробностей. ))
Ты же взял некие абстрактные критерии, где ни один из них не является важным для обсуждаемой предметной области.
Да тут не то, что в области низкоуровневых микроконтроллеров... тут даже в деле написания банальнейших дров под высокоуровневый ЦПУ на твоей машине — и уже твои критерии не работают. Ты слишком прикладной программист.
N>Отлично. А теперь скажи, что получится, если у тебя будет необходимость выполнить воздействие двум разным двигателям с интервалом меньше, чем эта длительность отработки одного двигателя. Например, work1() и delay() в коде выше — по 2 мкс, а тебе надо что-то сделать для 1 и 2 с разницей в 1 мкс.
Выделил ошибку.
Не у меня, а у тебя.
У тебя там не получится ничего, ес-но, как ты сам абсолютно правильно сейчас подметил.
Только зачем тогда было приводить заведомо неработающий код?
А потом ты обижаешься, когда я недвусмысленно намекаю, что ты ведешь обсуждение более чем странно, где странностью является добровольная бестолковость какая-то... ХЗ... никогда этого не пойму...
N>И что зависит от качества программистов для этих вспомогательных, кроме очевидного фактора корректности результата?
Тут тоже ХЗ. Но есть наблюдения — примерно половине программистов этот род деятельности не даётся вообще никак ни под каким видом. Хоть кол на голове им теши или даже под страхом расстрела. Казалось бы — там всё СЛИШКОМ элементарно... человек запросто пишет довольно-таки большие проги, использует сложные библиотеки и т.д... А вот просто пару бит туда-сюда погонять — полный ступор.
N>Я уже так давно не работал с SIP, что не могу понять, это в мой огород камень или нет. Но длинных цепочек ifʼов в своём коде я что-то не помню.
Если "раскрыть все скобки" (сделать все ф-ии инлайными в том коде), то будет просто масса ветвлений и всё.
Собсно, я еще тогда подробно объяснял этот фатальный недостаток SIP — это отсутствие встроенных ср-в комбинирования сценариев. Любая комбинация сценариев должна быть прописана в очередном расширении стандарта. Вот что я называю каменным веком. Протокол SIP был разработан, очевидно, потребителями технологий, а не производителями. Они взяли RTP, который был до них, они взяли TCP и сделали самую большую каку в истории VoIP. Более непоследовательного, непродуманного, ограниченного в развитии и т.д. до бесконечности протокола — просто не существует.
Мне SIP напоминает творчество тех самых админов Linux, где половина программы у них живет в конфиге, ы-ы-ы.
Одно плохо — придумать правильный формат конфига тоже моск нужен, а его при разработке SIP-а ни у кого не оказалось. ))
В общем, SIP был разработан админами, а не программистами, сие слишком очевидно.
Причем, очень и очень узкоспециализированным админами.
Поэтому, имеем что имеем.
V>В Broadcom есть. А по другим производителям инфа совсем скупая.
Какой именно чип?
Почему спрашиваю, потому как удивлен. Потому что как раз уверен что в броадком такого нет, именно в wifi, и практически уверен насчет Bluetooth. Я как раз работал у них до недавнего времени, и хорошо знаю архитектуру и какие фирмвари там.
Здравствуйте, vdimas, Вы писали:
V>>>В любом случае, для сценари использования таймера "выдай мне прерывание через столько-то времени" (а там именно такой сценарий) — это будет накопление ошибки, бо обычно у тебя нет никакой информации о том, сколько действительно времени потребовалось на реакцию на таймер. А когда таймеров более одного, ты находишься в обработке прерывания одного из них, прерывания от других запрещены... Дальше продолжать или уже догадался?
У STM32 можно настроить таймер так, чтобы прерывание только патроны подносило (через теневые регистры). Никакой ошибки, всё аппаратно. Я так в своём коде делаю. Потому и спрашивал, что не так с таймерами. Всё гарантировано по времени.
С циклом мне непонятно, а что с другими прерываниями-то делать? Как раз с прерыванием я бы делал как-то так: один таймер на все шаговики, самый высокий приоритет (чтобы оно гарантированно перебивало все другие прерывания). Запрет прерываний запрещён, только через BASEPRI и без запрета этого самого прерывания от таймера. В таком варианте, время реакции, по идее, будет всегда одно и то же.
Непонятно только, как очень близкие шаги по разным выходам делать (выдали 1 по одному выводу и через 1 такт -- по другому). Можно, наверное, немного смещать шаги, с учётом макрошагов, по идее, ошибка будет маленькая.
Может быть, можно через DMA как-то (чё-нить типа копировать из памяти в регистр GPIO по таймеру и в теневые регистры таймера по этому же таймеру).
Re[6]: Подскажите как сейчас принято искать работу
Здравствуйте, vdimas, Вы писали:
V>>>Т.е., всё-таки, ракетными системами будет управлять юзверское приложение поверх Linux? )) C>>SpaceX использует RT Линукс в системах управления. V>RT Линукс — это не Linux. ))
Это Линукс. Именно Линукс. Набор CONFIG_PREEMPT_RT добавляет поддержку жёсткого real-time с верхним ограничением времени реакции.
Здравствуйте, Иван Дубров, Вы писали:
ИД>У STM32 можно настроить таймер так, чтобы прерывание только патроны подносило (через теневые регистры). Никакой ошибки, всё аппаратно.
Ну вот самая распространённая задачка вокруг таймеров (остальное не есть "задачка") — это установка после каждого срабатывания таймера новой для него длительности. Насколько я понимаю, через теневые регистры это можно сделать, ОК. Прямо в теле прерывания. И получается тот фокус, что мы уже того-с, поезд уже ушел. Мы можем лишь настроить теневые регистры на следующий цикл, а не на этот, т.е. который вот только что начался.
Я "не дожил" в ассемблере до появления теневых регистров в армах, но правильно ли я понял сию тонкость?
ИД>Я так в своём коде делаю. Потому и спрашивал, что не так с таймерами. Всё гарантировано по времени.
А как получить частоту, скажем, ровно 2/255 от тактовой?
Что вообще можно сделать с обычным 16-тиразрядным счётчиком, кроме как использовать его для чего-то малокритичного?
ИД>С циклом мне непонятно, а что с другими прерываниями-то делать?
Их нет во время рабочего хода инструмента.
ИД>Как раз с прерыванием я бы делал как-то так: один таймер на все шаговики
Это будут шаговики на поиграться. Без особой спешки, в смысле.
ИД>Непонятно только, как очень близкие шаги по разным выходам делать
Именно что. А надо независимо обслуживать задержки. И даже выводить сигналы на разные порты в один и тот же момент времени, т.е. в рамках одной и той же команды записи в порт — это же просто запись в некий адресуемый регистр некоей битовой маски (пусть три младших разряда соответствуют 3-м шаговикам).
ИД>Можно, наверное, немного смещать шаги, с учётом макрошагов, по идее, ошибка будет маленькая.
Ошибка будет просто чудовищная, как по мне — в несколько десятков тактов. Более того, непонятно, как подстраивать фазу в такой конфигурации.
ИД>Может быть, можно через DMA как-то (чё-нить типа копировать из памяти в регистр GPIO по таймеру и в теневые регистры таймера по этому же таймеру).
Или не париться, а взять самую простую конфигурацию чипа и закодить таймеры в софте.
Я так делал. Играет двухголосную музыку, подаёт звонки, ведет отсчёт точного времени дня.
Тупо фиксированный цикл и зашита точная частота кварца конкретного экземпляра — годами часы можно не корректировать.
А частоты нот, знаешь ли, бывают очень дробными, а фальшь режет слух. ))
Здравствуйте, vdimas, Вы писали:
V>По-идее, если ЖК-монитор вносит строго фиксированную задержку, то от ghosting можно было бы избавиться — он же является индикатором неравномерной скорости движения.
А не, гоню.
Скорее всего ghosting — это признак длительного равномерного свечения картинки, при том что взгляд двигается синхронно со средней скоростью фигуры. Да, для избавления от этого эффекта длительность показа картинки (каждой её части) должна быть менее ~1/25 от полного цикла.
Здравствуйте, vdimas, Вы писали:
V>Ну вот самая распространённая задачка вокруг таймеров (остальное не есть "задачка") — это установка после каждого срабатывания таймера новой для него длительности. Насколько я понимаю, через теневые регистры это можно сделать, ОК. Прямо в теле прерывания.
V>Я "не дожил" в ассемблере до появления теневых регистров в армах, но правильно ли я понял сию тонкость?
Да, как-то так.
V>И получается тот фокус, что мы уже того-с, поезд уже ушел. Мы можем лишь настроить теневые регистры на следующий цикл, а не на этот, т.е. который вот только что начался.
Если программа заранее известна, то почему нет? Все длительности будут строго в соответствии с программой. Обработается ли прерывание чуть раньше или чуть позже -- не важно, оно же только на следующий цикл грузит (т.е при окончании цикла N прерывание будет обрабатывать длительности для цикла N+2). Главное, чтобы минимальная длительность была гарантированно больше самого пессимистичного сценария обработки прерывания.
V>А как получить частоту, скажем, ровно 2/255 от тактовой?
Таймер же (опосредованно) от того же генератора тактовой частоты работает. Если задержка в целых тиках не выражается, значит не выражается, надо переменные длительности делать. Можно чередовать длительности 127 и 128, в среднем будет 127.5.
V>Что вообще можно сделать с обычным 16-тиразрядным счётчиком, кроме как использовать его для чего-то малокритичного?
Можно сцепить два таймера и получить один 32-разрядный (старший щёлкает по переполнению младшего).
Здравствуйте, gardener, Вы писали:
G>Какой именно чип?
А какой достоверно не?
В открытом доступе есть только инфа о том, какие архитектуры ядер они лицензировали (я указывал выше) или на основе чего сделано ядро управляющего модуля в чипе (сейчас ARM, когда-то давно MIPS), но никогда не указывается, как они делают микропрограммируемую цифровую логику на чипе, которая, собсно, делает полезную работу. Остаётся делать выводы на основе того, какие архитектуры они лицензируют.
G>Почему спрашиваю, потому как удивлен. Потому что как раз уверен что в броадком такого нет, именно в wifi, и практически уверен насчет Bluetooth. Я как раз работал у них до недавнего времени, и хорошо знаю архитектуру и какие фирмвари там.
О какой фирмваре ты говоришь? Которая предназначена для управляющего ядра на основе ARM?
Серьёзно? ))
Или ты про VLIW-микрокод модуля протокола, что он не VLIW? ))
Или речь шла о блоке шифрования?
Или о блоках FFT/iFFT, кодирования/декодирования, разделения поднесущих в цифре и т.д.?
(а у последних вообще бывает обновляемая фирмварь? — скорее всего нет, бо незачем)
V>Или ты про VLIW-микрокод модуля протокола, что он не VLIW? )) V>Или речь шла о блоке шифрования? V>Или о блоках FFT/iFFT, кодирования/декодирования, разделения поднесущих в цифре и т.д.? V>(а у последних вообще бывает обновляемая фирмварь? — скорее всего нет, бо незачем)
Понятно. Т.е. ты не знаешь о чем говоришь. Там не то что VLIW, а и процессоров никаких нет.
Здравствуйте, Иван Дубров, Вы писали:
V>>И получается тот фокус, что мы уже того-с, поезд уже ушел. Мы можем лишь настроить теневые регистры на следующий цикл, а не на этот, т.е. который вот только что начался. ИД>Если программа заранее известна
Вот. ))
А если у нас токарный станок, у которого скорость вращения детали может зависеть банально от давления резака на материал, то у тебя "известная заранее программа" представлена в таком виде, что её еще надо отображать на мгновенную угловую скорость вращения детали.
ИД>Таймер же (опосредованно) от того же генератора тактовой частоты работает. Если задержка в целых тиках не выражается, значит не выражается, надо переменные длительности делать. Можно чередовать длительности 127 и 128, в среднем будет 127.5.
А если 127.3333? ))
Это я просто намекаю, что ты всё делаешь верно, но в итоге получишь такой алгоритм, что таймер станет уже фактически не нужным — у тебя и так получится "ручной" генератор произвольной частоты, примерно как в посте по ссылке, где дан сниппет про генератор синусоиды: http://www.rsdn.org/forum/flame.comp/6803924.1
Там можно взять только старший бит — и будет меандр нужной дробной частоты.
V>>Что вообще можно сделать с обычным 16-тиразрядным счётчиком, кроме как использовать его для чего-то малокритичного? ИД>Можно сцепить два таймера и получить один 32-разрядный (старший щёлкает по переполнению младшего).
А в базовой конфигурации есть 6 таймеров, которые можно подобным образом сцепить?
V>Ясно. V>Открываю даташит и вижу микропрограммируемое устройство, помимо ядра ARM.
Даташит на что? Название чипа пожалуйста.
Я разве говорил что там один процессор? Будь внимательнее. Повторяю — VLIW нигде нет. А те функции, которые ты перечислял — там и процессора нет.
V>Вот так ты "работал". ))
Опа, вот это поворот.
V>Не поделишься, чем именно ты там занимался?
Software engineering. Вот как раз фирмвары которые там.
Re[2]: Подскажите как сейчас принято искать работу
Здравствуйте, vdimas, Вы писали:
V>Я не знаю, каким махровым нубом надо быть, чтобы предполагать, что система обнаружения и управления радаром (для примера) будет управляться юзверским приложением на какой-нить обычной Linux. Это просто пробитие дна какое-то...
Система управления радаром, которую я видел управлялась Линуксом (МСВС).
Насколько это "обычный Линукс" — не знаю. Насколько непосредственно управлялась — тоже.
Визуально это выглядит как стойка размером с холодильник,
к которой присоединён компьютер на Эльбрус под МСВС.
Ты конечно можешь сказать, что весь реалтайм в этой стойке,
а на Линуксе только ГУИ, и наверное это действительно так.
Re[4]: Подскажите как сейчас принято искать работу
Здравствуйте, netch80, Вы писали:
БП>>Для меня критерий НАШЕГО компьютера — наличие на клавиатуре отдельной кнопки, переключающей раскладку. N>Насколько отдельной?
N>Я вот переназначаю CapsLock на эту роль — этого достаточно?
Ты про лампочку scroll lock забыл сказать...
В даташитах есть некий микропрограммируемый модуль PSM.
The programmable state machine (PSM) is a microcoded engine, which provides most of the low-level control
to the hardware, to implement the IEEE 802.11 specification. It is a microcontroller that is highly optimized for
flow control operations, which are predominant in implementations of communication protocols.
Твои комментарии?
V>>Не поделишься, чем именно ты там занимался? G>Software engineering. Вот как раз фирмвары которые там.
На управляющий ARM или на упомянутый процессорный модуль?
Еще вопрос — зачем они лицензировали CEVA-XC архитектуру?
Неужели лицензировали, но не используют?
Они прилично внутри отличаются. C 4360 я как раз работал до того как уйти в тим, который как раз вот разрабатывал эти IoT чипы (и который был продан Cypress).
V>В даташитах есть некий микропрограммируемый модуль PSM. V>
V>The programmable state machine (PSM) is a microcoded engine, which provides most of the low-level control
V>to the hardware, to implement the IEEE 802.11 specification. It is a microcontroller that is highly optimized for
V>flow control operations, which are predominant in implementations of communication protocols.
V>Твои комментарии?
Там никаких VLIW в помине нет. Доморощенный контроллер. Своя простая система команд.
Собрать AMPDU из набора подготовленных буферов и параметров, отослать в MAC, обработать BACK, сделать retry, etc.
Они его используют насколько я понимаю по историческим причинам. Например где я сейчас работаю маппинг функций на железо не абсолютно такой же, но похож, и мы это делаем обычным RISC небольшим процессором.
V>>>Не поделишься, чем именно ты там занимался? G>>Software engineering. Вот как раз фирмвары которые там.
V>На управляющий ARM или на упомянутый процессорный модуль?
Для АРМа. Но при этом доступ к исходникам этого PSM у меня был, и я туда периодически заглядывал, хотя и не коммитил. Туда вообще мало кто коммитит, там небольшая группа. Не то чтобы что-то сложное, просто там небольшой набор функциональности.
V>Еще вопрос — зачем они лицензировали CEVA-XC архитектуру? V>Неужели лицензировали, но не используют?
Без понятия. Это именно WiFi business unit? Потому как Broadcom здоровый и реально много чего делает.
В WiFi этого не было.
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, netch80, Вы писали:
БП>>>Для меня критерий НАШЕГО компьютера — наличие на клавиатуре отдельной кнопки, переключающей раскладку. N>>Насколько отдельной?
N>>Я вот переназначаю CapsLock на эту роль — этого достаточно? S>Ты про лампочку scroll lock забыл сказать...
И это тоже, безусловно, но я хотел сказать это уже в ответ на реплику коллеги БП. Но он молчит...
Здравствуйте, 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>Заметь, не надо сравнивать на каждом шаге и по результату отнимать 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. Это видно, например, по чрезмерной грамматичности. Но признаков участия именно админов я там не вижу.
