При написании первого драйвера столкнулся с проблемой измерения времени события, точнее с его точностью. Из кернел модуля для арм платформы не смог найти доступа через стандартные средства к аппаратным клокам, чтобы быстро (потому что собираюсь замеры делать в обработчике прерывания, а все остальное уже дорабатывать в тасклете и точно (интервал до сек, точность 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мкс!!! Не факт что это максимум, и это при том, что в драйвере я всего лишь дергаю один пин и закомментил свой тасклет. Но в меголинухе есть задачи поважнее чем обработка прерываний я так понял. Сегодня буду играться с переферийными узлами, посмотрю что там, но там девиацию измерений придется уже статистически обрабатывать на верхнем уровне, там пином нет смысла дергать.
29.06.2012 01:24
30.06.2012 09:29