> Во первых, ровно то же самое известно и для чипов х86. Оно никогда не известно с какой либо точностью, т.к. нет никаких _гарантий_ попадания в кеш, угадывания или не угадывания ветвления и прочая. И джиттер там нефиговый сам по себе.
> И то что в атмеге декларируется 3-5 тактов на переход на обработку
> прерывания, а в х86 это может оказаться цифра 5-100 (с потолка
> взятые цифры) ничего не означает на практике - при пересчете в
> реальное время - на те же микросекунды,
У атмеги ее такты - это с момента когда на лапке изменились условия и до момента когда ядро проца отдаст руль обработчику прерываний, который этим вопросом озадачится. Потому что контроллер GPIO вплотную к ядру, сразу его и дергает. А у x86 пока там что-то где-то по хрензнаеткаким шинам из своих дербеней отсигналит что тут у нас вообще прерывание прилетело - рак на горе свистнет.
Что x86 может "сам по себе" видно на примере программаторов на LPT/COM порт где x86 относительно "напрямую дергает IO-лапками". В современных реалиях правда оно вообще подохло т.к. в многозадачках выходит совсем жопно. А все быстрые программаторы как один юзают микроконтроллер который и разруливает скоростной дерг лапками из буфера почему-то.
> этот джиттер съедатся разницей частот.
Ну да, мечтайте. У x86 вообше нет GPIO по сути. А пока там от периферии доползет что вообще имело место прерывание... ну вон в PCI-E вообще прерываний нет. Там только сообщение :) о том что "а вот это типа прерывание" ("MSI" - message signaled interrupt). В юсб вообще тухляка - там хост опрашивает периферию - "есть чо? А если найду?" и не более 1000 раз в секунду всего (особо хардкорные геймеры и то плюются).
> Во-вторых, джиттер надо учитывать не на переход на программу прерывания,
> а на реальный отклик
Переход на программу прерывания позволяет вот прямо там и устроить реальный отклик на событие. А если ломовым polling'ом и дергом лапок покомандно - атмега без аппаратных костылей разрулит несколько мегагерцев маханий лапками. А x86 от сотен тыщ...миллионов IRQ в секунду вообще колом встанет. Ну не заточен он на такое. Поэтому вся периферия имеет некислые буфера, DMA и прочая и стараются накопить побольше данных на 1 дерг. Знаете как у UART 16550 появился буфер? Писюшники перестали успевать дергаться на прерывания от его безбуферных предков типа 8250 и пришлось срочно рожать накопительный буфер :)
> - другими словами, надо добавлять сюда еще время обработки прерывания.
У атмеги оно на порядок ниже как правило. И тасовки регистров меньше, т.к. набор регистров человеческий, и I/O оно может рюхать в пределах _ОДНОЙ_ команды при желании, за _ОДИН_ такт, если уж совсем хардкорный поллинг/дергинг делать.
> ага) на то чтобы считать данные из порта, посчитать от него скажем синус
А это нафига?
> и выставить в другой порт,
А на цифровой порт сложно выставить что-то кроме единиц или нолей. Посчитать синус с "точностью" в 1 бит можно как делать нефиг за считанные команды (тупо сравнение влобешник). Ах, вы про что-то типа DAC? Так у большинства (если не всех) atmega его нет. Если надо крутую обработку сигналов в реальном времени - этим DSP занимаются...
> а мы вместе посмеемся, когда сравним время отклика на атмеге и на х86.
Не, ну я понимаю что сферический конь в вакууме это круто. Но вот почему-то такие "тараканы" по жизни принимают ключевые решения вида "ой, а по мнению гироскопа мы тут во что-то основательно въе, так что выпускаем подушки безопасности".
>> А ща мы вас обломим. Вспоминаем про SMI и понимаем что на типовом писюшнике x86 вообще
>> никому нифига не гарантирует,
> В исходном посте речь шла что атмега уделает х86, а не типовой писюшник.
> Это как бы две очень большие разницы. Как насчет распаянного эмбед х86,
> без каких либо биоса и прочих финтифлюшек?
Ну так сферический конь в вакууме никому не интересен. Сделайте и приходите. Для начала можете забабахать эквивалент ESC (electronic speed controller) для оборотистых BLDC моторов которые в почете у авиамоделистов например. Там оно влобовую ключи дергает переключая обмотки заместо коллектора. Да еще по росту тока детектирует попадание препятствий в пропеллер, мера чтобы юзвергу руку не порубало в капусту если в пропеллер попадет.
>> А по-фи-гу: у x86 контроллер прерываний вообще внешняя фигня, и не больно какая
>> быстрая, а GPIO вообще толком нет, а пока там достучишься до периферии на шине
> Боже мой, какая безграмотность. Никакой внешний контроллер прерываний не поможет, если
> нет прерываний в самом проце (INTR/NMI).
Боже мой, какая безграмотность, нас волнует время прохождения всей этой этажерки. Практическое, а не сферические кони в вакууме.
> Поставь нужные порты и задействуй INTR, если так уж хочется сравнивать
> сами архитектуры. Про скорость периферии улыбнуло - атмега сравнится
> разве что с лохматым 80386/ISA.
Именно лобовой дерг лапок у атмег очень быстрый, можно менять состояние порта чуть ли не каждый такт, что вообще-то является обалденным по эффективности результатом. Какой там нафиг 80386/isa? Вы им вообще сможете дернуть лапкой на 100 наносекунд? И как это по вашему будет выглядеть? :) А у современного x86 обычно вообще нет GPIO у проца, там только всякие шины ориентированные на ломовую пропускную способность но в ущерб латентности, в надежде что кеш и прочие предсказания ветвлений вытянут. Вытягивают, но очень уж негарантированно и джиттер нехилый. Как и вообще разница в скорости выполнения, в зависимости от. Если время выполнения отличается в разы - оно отличается в разы.
> если не дошло, то объясню еще раз - х86 не используется для
> подобных задач не потому что он этого не умеет, а потому
> что overkill: дорого и неудобно.
Он не используется для этой цели потому что разгонять многотонный дорожный каток до скорости 200 км/ч довольно непростое начинание. Хотя если как следует постараться и пустить его с обрыва - говорят что можно, да :)
