fk0, легенда (16.10.2010 23:51, просмотров: 161) ответил rezident на Вполне допускаю, что нужен какой-то низкоуровневый драйвер, которой нужно переписать или его просто нет. А может нужно что-то с приоритетами приложений сделать. Сейчас наблюдается такая штука. Допустим задали внешнее воздействие, которое
Между компортом и приложением есть буфер порта. Так вот при поступлении туда данных в буфер-то они складываются, а будить (возвращаться из select или read) процесс ядро будет как только у него планировщик до того дойдёт, и не факт, что быстрее, чем за 1 цикл планировщика (видимо, это негарантированно лечится ASYNC_LOW_LATENCY или опцией low_latency в программе setserial -- см. её man). Потом у самого UART есть fifo. И прерывания могут быть настроены по разному, как и глубина fifo. Понятно, что пока fifo не полное, нет прерывания, латентность зависит от частоты опроса порта ядром, не высокой... Вариант -- отключить fifo (опять же, с помощью setserial задать 16450, например, но если драйвер moxa -- х.з. что делать, кроме того можно задать rx_trigger, чтоб получать прерывания по каждому байту). Ещё вариант, который может помочь -- перекомпилировать ядро с большим значением HZ (более частым системным тиком, поскольку к нему привязан тот же планировщик).
Потом непонятно какие настройки порта и как с ним идёт работа, там свои таймауты есть (например, у read, задаваемый через tcsetattr) -- может там накосячено. Всё ж задержка в несколько секунд -- это очень-дофига, все заморочки с последовательным драйвером в ядре это всё же скорей десятки миллисекунд в худшем случае, если CPU load конечно не 200%... чего вообще в embedded не должно быть.
[ZX]