Ник:
Пароль:

Контакты

E-mail: info@starterkit.ru
тел.: +7 922 680-21-73
тел.: +7 922 680-21-74
Телеграм: t.me/starterkit_ru

Способы оплаты

User Info


Добро пожаловать,
Guest

Регистрация или входРегистрация или вход
Потеряли пароль?Потеряли пароль?

Ник:
Пароль:

ПользователейПользователей:2
Поисковых ботовПоисковых ботов:3
ГостейГостей:1

ОбновитьПодробнееВсегоВсего:6
Форум » starterkit.ru » ARM
AT921SAM9G20 Точное измерение времени в драйвере под Линукс
chronoman
Добавлено 29.06.2012 01:24
0
Сообщение: 1
chronoman
0

Пункты: 295
Регистрация: 19.04.2010
При написании первого драйвера столкнулся с проблемой измерения времени события, точнее с его точностью. Из кернел модуля для арм платформы не смог найти доступа через стандартные средства к аппаратным клокам, чтобы быстро (потому что собираюсь замеры делать в обработчике прерывания, а все остальное уже дорабатывать в тасклете и точно (интервал до сек, точность 1мкс или лучше, не путать с дискретностью). Нашел что есть такое как rdtsc(lo, hi) и get_cycles(), но увы это не реализованно почему то для арм платформ, последнее например возвращает захардкоженный 0 именно для арма, для некоторых других платформ работает. Как бы странно, всегда думал, что фиксация времени это одна из популярных операций, а тут как бы ничего не вымучивается. Либо не реализованно для арма, либо афигенное разрешение в наносеках, но при этом период обновления пляшет от герца-джифера, а оно увы 1-10мс, что вообще никак не подходит. Неужеле для арма надо настраивать самому пользовательские таймеры и работать с ними, так же таймеров не напасешься, да и как быть уверенным, что никакой другой драйвер их уже не пользует или не будет пользовать в дальнейшем.
Спуститься к концу Подняться к началу
Персональная информация
chronoman
Добавлено 29.06.2012 02:32 Сообщение: 2
chronoman
0

Пункты: 295
Регистрация: 19.04.2010
Хмм, после ознакомления с этой статьей
http://www.at91.com/linux4sam/bin/view/Linux4SAM/RealTime
уже начинаю думать, что для таких задач такая ось как линух не подходит. Хеномай было конечно и есть щас задача поставить, но даже с ним оно не поможет. Или я че то неправильно понял насчет того, с какой задержкой дойдет событие до моего обработчика прерывания в кернел модуле (26мкс в хеномаи и намного больше в обычном). Завтра на практике посмотрю, подключю осциллограф, с прерывания, дерну пином проца и померяю задержку от входа к выходу. Очень надеюсь, что я неправильно понял эту статью.
Спуститься к концу Подняться к началу
Персональная информация
chronoman
Добавлено 29.06.2012 13:15 Сообщение: 3
chronoman
0

Пункты: 295
Регистрация: 19.04.2010
Да, так и есть, осциллограф показывает сразу на входе в прерывание задержку от 5мкс мин. и девиацию до 20мкс, хотя наверное может быть и больше, замерял на глаз по картинке на осциллографе. Такой шум увы не подходит, кто что может подсказать, как же в линухе мерять например ширину импульса, так чтобы шум измерения был меньше 1мкс, а еще лучше точность конечно же.
Неужеле камень с линухом надо опутывать однокристалками, которые будут уже в жестком риалтайме все мерять и по портам передавать уже в большой камень (ну или тоже самое будет делать интегрированный специфический узел в самом камне в отрыве от линуха).
Спуститься к концу Подняться к началу
Персональная информация
sasamy
Добавлено 30.06.2012 09:19 Редактировалось 30.06.2012 09:29 Сообщение: 4
sasamy
4.71

Пункты: 83534
Регистрация: 14.08.2009
Цитата

будет делать интегрированный специфический узел в самом камне в отрыве от линуха


Да. Постоянно вижу - люди не понимают что такое многозадачная ОС и пытаются "влоб" решать задачи как привыкли делать это на микроконтроллерах, для которых такие задачи - основные а зачастую вообще единственные, для взрослых процессоров и ОС подобные задачи - одни из многих и они не должны нагружать процессор.
Спуститься к концу Подняться к началу
Персональная информация
chronoman
Добавлено 02.07.2012 09:57 Сообщение: 5
chronoman
0

Пункты: 295
Регистрация: 19.04.2010
Цитата
Цитата

будет делать интегрированный специфический узел в самом камне в отрыве от линуха


Да. Постоянно вижу - люди не понимают что такое многозадачная ОС и пытаются "влоб" решать задачи как привыкли делать это на микроконтроллерах, для которых такие задачи - основные а зачастую вообще единственные, для взрослых процессоров и ОС подобные задачи - одни из многих и они не должны нагружать процессор.


Ну так как же выполнить задачу, которая элементарна на обычных однокристалках и занимает там минимум ресурсов, на таком мощном камне с линухом, так чтобы метрологически все было честно (мерять шим, 1-2мс с точностью хотя бы 1мкс) и камень не грузить. Программировать в драйвере перифирийные узлы (таймеры например) я не уверен, а вдруг его кто то еще пользует, когда писал для однокристаллок, то там я был король, сам все контроллировал, тут же прозрачности никакой, можно конечно посмотреть проц-стат, проц-интеррапт, наверняка можно еще в тысячу мест посмотреть, и прийти к выводу что узлом интегрированным можно пользоваться, но где гарантия, что через месяц в линухе не выйдет апдейт и кто-то не начнет шарить с вами ресурс и при этом некорректно.

Вот мои прошлые замеры 5-20мкс задержка до входа в мое прерывание, это гуд, но стоило мне запустить пользовательскую задачу и вход в прерывание стал уже 5-200мкс!!! Не факт что это максимум, и это при том, что в драйвере я всего лишь дергаю один пин и закомментил свой тасклет. Но в меголинухе есть задачи поважнее чем обработка прерываний я так понял. Сегодня буду играться с переферийными узлами, посмотрю что там, но там девиацию измерений придется уже статистически обрабатывать на верхнем уровне, там пином нет смысла дергать.
Спуститься к концу Подняться к началу
Персональная информация
sasamy
Добавлено 02.07.2012 10:41 Сообщение: 6
sasamy
4.71

Пункты: 83534
Регистрация: 14.08.2009
Цитата

Ну так как же выполнить задачу, которая элементарна на обычных однокристалках и занимает там минимум ресурсов, на таком мощном камне с линухом, так чтобы метрологически все было честно (мерять шим, 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.


дальше не вижу смысла объяснять
Спуститься к концу Подняться к началу
Персональная информация
Форум » starterkit.ru » ARM