При написании первого драйвера столкнулся с проблемой измерения времени события, точнее с его точностью. Из кернел модуля для арм платформы не смог найти доступа через стандартные средства к аппаратным клокам, чтобы быстро (потому что собираюсь замеры делать в обработчике прерывания, а все остальное уже дорабатывать в тасклете и точно (интервал до сек, точность 1мкс или лучше, не путать с дискретностью). Нашел что есть такое как rdtsc(lo, hi) и get_cycles(), но увы это не реализованно почему то для арм платформ, последнее например возвращает захардкоженный 0 именно для арма, для некоторых других платформ работает. Как бы странно, всегда думал, что фиксация времени это одна из популярных операций, а тут как бы ничего не вымучивается. Либо не реализованно для арма, либо афигенное разрешение в наносеках, но при этом период обновления пляшет от герца-джифера, а оно увы 1-10мс, что вообще никак не подходит. Неужеле для арма надо настраивать самому пользовательские таймеры и работать с ними, так же таймеров не напасешься, да и как быть уверенным, что никакой другой драйвер их уже не пользует или не будет пользовать в дальнейшем.
Хмм, после ознакомления с этой статьей http://www.at91.com/linux4sam/bin/view/Linux4SAM/RealTime
уже начинаю думать, что для таких задач такая ось как линух не подходит. Хеномай было конечно и есть щас задача поставить, но даже с ним оно не поможет. Или я че то неправильно понял насчет того, с какой задержкой дойдет событие до моего обработчика прерывания в кернел модуле (26мкс в хеномаи и намного больше в обычном). Завтра на практике посмотрю, подключю осциллограф, с прерывания, дерну пином проца и померяю задержку от входа к выходу. Очень надеюсь, что я неправильно понял эту статью.
Да, так и есть, осциллограф показывает сразу на входе в прерывание задержку от 5мкс мин. и девиацию до 20мкс, хотя наверное может быть и больше, замерял на глаз по картинке на осциллографе. Такой шум увы не подходит, кто что может подсказать, как же в линухе мерять например ширину импульса, так чтобы шум измерения был меньше 1мкс, а еще лучше точность конечно же.
Неужеле камень с линухом надо опутывать однокристалками, которые будут уже в жестком риалтайме все мерять и по портам передавать уже в большой камень (ну или тоже самое будет делать интегрированный специфический узел в самом камне в отрыве от линуха).
Да. Постоянно вижу - люди не понимают что такое многозадачная ОС и пытаются "влоб" решать задачи как привыкли делать это на микроконтроллерах, для которых такие задачи - основные а зачастую вообще единственные, для взрослых процессоров и ОС подобные задачи - одни из многих и они не должны нагружать процессор.
Ну так как же выполнить задачу, которая элементарна на обычных однокристалках и занимает там минимум ресурсов, на таком мощном камне с линухом, так чтобы метрологически все было честно (мерять шим, 1-2мс с точностью хотя бы 1мкс) и камень не грузить. Программировать в драйвере перифирийные узлы (таймеры например) я не уверен, а вдруг его кто то еще пользует, когда писал для однокристаллок, то там я был король, сам все контроллировал, тут же прозрачности никакой, можно конечно посмотреть проц-стат, проц-интеррапт, наверняка можно еще в тысячу мест посмотреть, и прийти к выводу что узлом интегрированным можно пользоваться, но где гарантия, что через месяц в линухе не выйдет апдейт и кто-то не начнет шарить с вами ресурс и при этом некорректно.
Вот мои прошлые замеры 5-20мкс задержка до входа в мое прерывание, это гуд, но стоило мне запустить пользовательскую задачу и вход в прерывание стал уже 5-200мкс!!! Не факт что это максимум, и это при том, что в драйвере я всего лишь дергаю один пин и закомментил свой тасклет. Но в меголинухе есть задачи поважнее чем обработка прерываний я так понял. Сегодня буду играться с переферийными узлами, посмотрю что там, но там девиацию измерений придется уже статистически обрабатывать на верхнем уровне, там пином нет смысла дергать.
Ну так как же выполнить задачу, которая элементарна на обычных однокристалках и занимает там минимум ресурсов, на таком мощном камне с линухом, так чтобы метрологически все было честно (мерять шим, 1-2мс с точностью хотя бы 1мкс) и камень не грузить.
Кусок даташита для вашего камня
34.5.7
Capture Operating Mode
This mode is entered by clearing the WAVE parameter in TC_CMR (Channel Mode Register).
Capture Mode allows the TC channel to perform measurements such as pulse timing, fre-
quency, period, duty cycle and phase on TIOA and TIOB signals which are considered as
inputs.
Figure 34-5 shows the configuration of the TC channel when programmed in Capture Mode.