[haker_fox 60]

Здравствуйте!

Имеется плата на базе MAT91SAM9G45 с установленным линуксом. Пока даже не могу сказать точно каким, т.е. команда uname -a не выдает название дистрибутива.

 

Вопрос вот в чем. Необходимо, чтобы мастер опрашивал "вереницу" устройств, висящих на RS-485. Количество устройств - не более 10 - 20. Количество пакетов в секунду - 5 - 10. Среднее количество байт в пакете - 10.

Вот я не знаю, как прикинуть, сможет ли линукс гонять пакетики с заданной частотой (5-10 пакетов в секунду)? Нечастные "тормоза" допустимы. Но если это будет повторяться часто, то это будет плохо.

Помимо этого, на плате планируется поднять файерволл, подключить к ней CDMA модем, использовать ее в качестве прокси-сервера, запустить какой-нить легкий GUI. Как-то невнятно так.

 

Или все-таки стоит для мастера использовать отдельную плату? Скажем с LPC2478 и поднять на ней РТОС (FreeRTOS, TNKernel)?

 

З.Ы. Опыта с линуксом практически нет. Работал с ним на персоналках. Поэтому трудно предсказать, что он может.

 

Спасибо!

[sasamy 7]

Или все-таки стоит для мастера использовать отдельную плату? Скажем с LPC2478 и поднять на ней РТОС (FreeRTOS, TNKernel)?

 

Для таких задач Linux с головой хватит.

[haker_fox 60]

Добрый день, уважаемый sasamy! Приятно Вас видеть! Польщен Вашими знаниями в этой области (по форуму на стартеркит.ру).

Спасибо за ответ!

[Hmm 0]

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

[haker_fox 60]

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

Опрос охранных датчиков, опрос чашек TouchMemory, управление модулями ввода-вывода...

 

Впринципе "разовая" задержка на приложение ключа к чашке в пределах 1 - 2 сек. допустима, но очень не жетельна, дабы не нервировать человека. Примерно тоже можно к охране отнести. Модули ввода-вывода управляют, например освещением.

 

Т.е. жесткое РВ не нужно. Но эти задержки в опросе модулей не должны быть частыми.

 

Видимо, нужно ставить эксперимент.

[sasamy 7]

Видимо, нужно ставить эксперимент.

 

Тестирование в любом случае нужно - должно хватить и обычного soft realtime который давно уже в ядре "из коробки", можно и rt-патч использовать. На атмеловских процессорах не пробовал, на imx233 тестировал - отклик задачи с высоким приоритетом не превышал 1 мс, при этом в ядре freescale присутствовал баг который приводил к дидлоку системы, с rt-патчем этот баг вообще не проявлялся - полное вытеснение делало свое дело :)

[_3m 6]

Тестирование в любом случае нужно - должно хватить и обычного soft realtime который давно уже в ядре "из коробки", можно и rt-патч использовать. На атмеловских процессорах не пробовал, на imx233 тестировал - отклик задачи с высоким приоритетом не превышал 1 мс,

Протестируйте еще раз: без рт патча и во время обмена с сд картой, желательно на запись. Еще вставляйте/извлекайте сд карту во время работы. Мониторьте максимальное время задержки.

Будьте осторожны - результаты могут шокировать.

 

[haker_fox 60]

Будьте осторожны - результаты могут шокировать.

А можно огласить, в смысле шокировать?)

[Enthusiast 0]

А можно огласить, в смысле шокировать?)

В текущей задаче у меня получился уход времени отклика задачи по таймерному прерыванию не более 25 мкс (+/- 12,5 мкс в ту и другую сторону). Установлен "Генту" на одноплатном компьютере с х86-процессором на 500 МГц.

[Dron_Gus 2]

Таймерное прерывание, это аппаратный таймер? CONFIG_HZ у Вас сколько? Обозначенная зажержка, это задержка до bottom или top half?

[Enthusiast 0]

Таймерное прерывание, это аппаратный таймер? CONFIG_HZ у Вас сколько? Обозначенная зажержка, это задержка до bottom или top half?

Нет, я использовал программное таймерное прерывание "Линукса". Привожу исходный код ниже.

CONFIG_HZ - это параметр ядра? Честно говоря, я уже не помню его значение, выставлял всё по максимуму при сборке. Последний вопрос не понял, поясните.

 

/* Configure and start timer for CAN bus I/O transactions */
/* Input: CanBusDescriptor for write and read to/from it  */
/* Output: 0 - start is ok                                */
/*         -1 - not ok (invalid)                          */
int StartCanBusTimer(void)
{
  /* linux interval timer configuration */
  struct itimerval TimerId;
  struct sigaction sigact;

  /* clear all flags and handler before using the signal action */
  memset(&sigact, 0, sizeof(sigact));
  /* define a signal handler for timer interruption */
  sigact.sa_handler = &CanBusTimerHandler;

  if(sigaction(SIGALRM, &sigact, (struct sigaction *)NULL) != 0)
  {
    DEBUG_PRINT("Can not run a signal action!\n");
    return -1;
  }

  /* configure timer */
  /* At first time run the timer handler after minimal time (1 us) */
  TimerId.it_value.tv_sec = 0;
  TimerId.it_value.tv_usec = 1;
  /* and every timing interval run timer handler again */
  TimerId.it_interval.tv_sec = CAN_BUS_TIMEOUT_INTERVAL_SEC;
  TimerId.it_interval.tv_usec = CAN_BUS_TIMEOUT_INTERVAL_NSEC / 1000;
  /* start the timer */
  setitimer(ITIMER_REAL, &TimerId, NULL);

  return 0;
}

/* It works at every CAN_BUS_TIMEOUT_INTERVAL_SEC */
/* Write data to the CAN bus and receive answer from it */
void CanBusTimerHandler(int SignalNumber)
{

  /* write DataToTheCanBus to the CAN bus */
  if((WriteToTheCanBus(CanBusDescriptor, (void *)DataToTheCanBus, UART_CAN_IO_NUMBER_OF_BYTES)) == -1)
  {
    DEBUG_PRINT("Can not write to the CAN bus!\n");
  }
}

[Dron_Gus 2]

Ну этот параметр "по максимуму" выставлять иногда вредно.

Обработчики прерывания обычно делят на две части - быструю (короткую), которая собственно вызывается при возникновении прерывания и собственно сам обработчик, который вызывается после и может быть долгим, ждать каких-то событий и т.д. Если вам нужен реал-тайм отклик, то часть обработки прерывания стоит перенести в top half, немного увеличится время на которое прерывания заблокированы, но Вы получите почти детерменированный отклик.

 

http://www.makelinux.net/ldd3/chp-10-sect-4

 

З.Ы. ИМХО для опроса датчиков по RS-485 это все нафиг не нужно. Какая там будет скорость? 9600? 115200? Програмный и аппаратный FIFO снивелирует возможные задержки.

 

А вот про CONFIG_HZ http://kerneltrap.org/node/464 . Т.е. погрешность програмного таймера напрямую зависит от частоты системных тиков.

[sasamy 7]

А вот про CONFIG_HZ http://kerneltrap.org/node/464 . Т.е. погрешность програмного таймера напрямую зависит от частоты системных тиков.

 

Информация у вас сильно устаревшая - Submitted by Jeremy on October 15, 2002 :)

http://elinux.org/High_Resolution_Timers

от HZ они зависят только на системах где нет таймеров с высоким разрешением (к примеру я таких не встречал). Например на at91sam9g45

# uname -a

Linux buildroot 3.2.9-rt17 #12 PREEMPT RT Tue Mar 20 03:29:27 MSK 2012 armv5tejl GNU/Linux

# cat /proc/timer_list

Timer List Version: v0.6

HRTIMER_MAX_CLOCK_BASES: 3

now at 335349555422 nsecs

 

cpu: 0

clock 0:

.base: c08bef80

.index: 0

.resolution: 1 nsecs

...

.hres_active : 1

...

event_handler: hrtimer_interrupt

Изменено 20 марта, 2012 пользователем sasamy

[Dron_Gus 2]

С первым соглашусь.

Системы без hi-res таймера есть (и не такие уж и древние):

root@crux:~# uname -a
Linux crux 3.2.0+ #915 Tue Mar 6 17:15:21 MSK 2012 armv5tejl GNU/Linux
root@crux:~# cat /proc/timer_list 
Timer List Version: v0.6
HRTIMER_MAX_CLOCK_BASES: 3
now at 2012233776199 nsecs

cpu: 0
clock 0:
  .base:       c05256a8
  .index:      0
  .resolution: 5000000 nsecs
  .get_time:   ktime_get

[sasamy 7]

Системы без hi-res таймера есть (и не такие уж и древние):

 

Какой это процессор ? Нужно смотреть - позволяет ли "железо", а в ванильном ядре есть далеко не все что есть в кастомных ядрах производителей и например у атмела поддержка полноценного таймера с высоким разрешением только после наложения -rt патча.