Гм... частота (скорость) посылки пакетов через последовательный порт Опции

[haker_fox]

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

Вопрос вот в чем. Необходимо, чтобы мастер опрашивал "вереницу" устройств, висящих на RS-485. Количество устройств - не более 10 - 20. Количество пакетов в секунду - 5 - 10. Среднее количество байт в пакете - 10.
Вот я не знаю, как прикинуть, сможет ли линукс гонять пакетики с заданной частотой (5-10 пакетов в секунду)? Нечастные "тормоза" допустимы. Но если это будет повторяться часто, то это будет плохо.
Помимо этого, на плате планируется поднять файерволл, подключить к ней CDMA модем, использовать ее в качестве прокси-сервера, запустить какой-нить легкий GUI. Как-то невнятно так.

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

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

Спасибо!

[sasamy]

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

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

[haker_fox]

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

[Hmm]

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

[haker_fox]

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

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

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

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

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

[sasamy]

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

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

[_3m]

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

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

[haker_fox]

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

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

[Enthusiast]

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

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

[Dron_Gus]

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

[Enthusiast]

Таймерное прерывание, это аппаратный таймер? 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]

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

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

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

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

[sasamy]

А вот про 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

Сообщение отредактировал sasamy - Mar 20 2012, 13:26

[Dron_Gus]

С первым соглашусь.
Системы без 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]

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

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

[Dron_Gus]

Samsung s3c2416. В нем, конечно, есть таймеры. Но 16-битные и без каскадирования. Если из него делать hi-res таймер для ядра, получится набор костылей. Мне в железке не надо.