QNX 6.4: проблема со встроенной системой

[Ingko]

Здравствуйте. Помогите разобраться с проблемкой:
Значит есть устройство на микроконтроллере. Взаимодействие с компьютером происходит через COM порт, интерфейс RS-232. Обмен информацией осуществляется через свой драйвер, работающий на низком уровне. На хост системе QNX 6.4 работает нормально, 1-2 таймаута на 10000 циклов запрос-ответ. А вот на встроенной системе начинаются проблемы: порядка 40 таймаутов на 10000 циклов, не смотря на то что драйвер COM порта (devc-ser8250) не запущен, никакие другие приложения с портом не работают (с запущенным драйвером ситуация та же).
Вот вывод команды pidin на встроенной системе:

     pid name                code  data Arguments
       1 boot/procnto-instr  487K 1140K procnto-instr
       2 proc/boot/devc-con  548K  156K devc-con -n1
       4 proc/boot/pci-bios  528K  120K pci-bios
    4099 proc/boot/mqueue    480K  124K mqueue
    4101 proc/boot/pipe      484K  124K pipe
    4102 proc/boot/devc-pty  528K  188K devc-pty
    4103 roc/boot/devb-eide  832K   17M devb-eide blk automount=hd0t177:/ qnx6 sync=optional
    4104 sbin/io-display     636K  208K io-display -dvid=0x5333,did=0x8d01,deviceindex=0 -c /etc/system/config/display.conf
    4105 /photon/bin/Photon  540K  124K Photon
    4106 proc/boot/io-hid    568K  136K io-hid -d ps2ser kbd:kbddev:ps2mouse:mousedev
    4107 proc/boot/devi-hid  668K  200K devi-hid mouse kbd
    4108 on/bin/io-graphics 2516K 1444K io-graphics -c /etc/system/config/display.conf
    4109 usr/photon/bin/pwm 1852K  172K pwm
    4111 sbin/./devc-par     528K  156K /sbin/./devc-par -p0x378
   16398 r/photon/bin/pterm 2080K  332K pterm
   16400 proc/boot/sh        652K  156K sh
   16401 bin//pidin          520K  132K pidin -faNcdA

в чем может быть проблема? Заранее благодарю за ответ

[Ingko]

под таймаутом я подразумеваю отсутствие корректного ответа от устройства за определенный промежуток времени

[Андрей Сеньков]

Как правило, целевая система обладает меньшей производительностью и в этом может быть причина проблемы при таком интенсивном обмене как у вас. Обычно, в UART имеется возможность диагностировать проблемы обмена: переполнение fifo, rx overrun, etc.

Вы не описали специфику взаимодействия, поэтому общие рекомендации будут следующими: увеличение приоритета вашей задачи, использование аппаратного fifo в UART, а также снижение накладных расходов за счет общей разгрузки системы, например, замена procnto-instr на procnto.

[Ingko]

Благодорю за ответ. Увеличение приоритета (до 200) не помогло, замена procnto-instr на procnto не помогла. Буду пробовать понизить частоту обмена и с UART разбираться. Драйвер писал не я, его автор исходниками не делится, так что руки у меня немного связаны в этом плане.

[Владимир Махилёв]

Думаю, что для проверки имеет смысл сократить влияние всех остальных обработчиков прерываний. Т.е. посмотреть у кого навешены обработчики прерываний

Код:

# pidin ir

и по возможности все лишние драйвера убрать.
Если речь идёт о x86 системе, можно попробовать задать нужному вам прерыванию высший приоритет через

Код:

startup-bios -I #

(по умолчанию высший приоритет у 3го прерывания).
Еще одно предположение - увеличить системный ticksize через ClockPeriod().