форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка

Вариант для распечатки		Архивированная нить - только для чтения!  Пред. тема | След. тема
Форумы Программирование под UNIX (Public)
Изначальное сообщение		[Проследить за развитием треда]

"Как ускорить возврат из функции read при работе с СОМ-портом"
Сообщение от Павел Мальцев on 14-Май-04, 15:16  (MSK)
Пытаемся работать на платформе StrongARM (это такой маленький однопалтный комп) с ядром 2.4.21 с СОМ-портом. Порт не совсем обычный - стандарта RS-422 (дифференциальный, полудуплексный) - все устройства, грубо говоря, передают и принимают по одной и той же линии. Соответственно встает задача переключения этой линии в состоянии прием/передача, а точнее процесс передачи происходит примерно так: 1. переключили линию в состояние "передача" (просто изменили DTR) 2. передали в линию данные 3. считали нами же переданные данные - убедились, что они ушли в линию 4. переключили линию в состояние "прием" и слушаем ответы от устройств... работаем - с обычным /dev/ttyS4 стандартными read/write/tcdrain и т.д. И все бы было хорошо, если бы процедура считывания наших данных из линии не выполнялась слишком долго (5-7 мс), в результате все устройства уже давно успели ответить, а мы только сподобились переключить линию в состояние "прием". Причем проверено, что само переключение линии (если его зациклить) занимает примерно 5 мкс (т.е. в тысячу раз быстрее, чем задержка при вызове read) Также проверено, что если данных нет и read собирается возвращать 0, то это тоже происходит быстро. И только когда действительно есть что вернуть (нами же переданные данные), read возвращается с большой задержкой, не смотря на то, что мы точно знаем сколько данных читать, используем минимальные значения timeout'ов и т.д.... Все это не помогает - задержка все равно 7 мс. Что делать? Откуда такая большая задержка появляется?
	Рекомендовать в FAQ | Cообщить модератору | Наверх

Индекс форумов | Темы | Пред. тема | След. тема

Сообщения по теме

1. "Как ускорить возврат из функции read при работе с СОМ-портом"
Сообщение от klalafuda on 17-Май-04, 20:06  (MSK)
>Пытаемся работать на платформе StrongARM (это такой маленький однопалтный комп) с ядром >2.4.21 с СОМ-портом. >Порт не совсем обычный - стандарта RS-422 (дифференциальный, полудуплексный) - все устройства, >грубо говоря, передают и принимают по одной и той же линии. >Соответственно встает задача переключения этой линии в состоянии прием/передача, а точнее >процесс передачи происходит примерно так: >1. переключили линию в состояние "передача" (просто изменили DTR) >2. передали в линию данные >3. считали нами же переданные данные - убедились, что они ушли в >линию >4. переключили линию в состояние "прием" и слушаем ответы от устройств... > >работаем - с обычным /dev/ttyS4 стандартными read/write/tcdrain и т.д. >И все бы было хорошо, если бы процедура считывания наших данных из >линии >не выполнялась слишком долго (5-7 мс), в результате все устройства уже >давно успели ответить, а мы только сподобились переключить линию в >состояние "прием". >Причем проверено, что само переключение линии (если его зациклить) >занимает примерно 5 мкс (т.е. в тысячу раз быстрее, чем задержка при > >вызове read) >Также проверено, что если данных нет и read собирается возвращать 0, >то это тоже происходит быстро. И только когда действительно есть что >вернуть (нами же переданные данные), read возвращается с большой >задержкой, не смотря на то, что мы точно знаем сколько данных читать, > >используем минимальные значения timeout'ов и т.д.... >Все это не помогает - задержка все равно 7 мс. >Что делать? Откуда такая большая задержка появляется? выключите аппаратное FIFO если оно есть на плате. // wbr
	Рекомендовать в FAQ | Cообщить модератору | Наверх

	2. "Как ускорить возврат из функции read при работе с СОМ-портом"
	Сообщение от Павел Мальцев on 17-Май-04, 21:03  (MSK)
	>выключите аппаратное FIFO если оно есть на плате. Не подскажете, можно ли это сделать по стандарту UART? У нас пока подозрение, что задержка связана с уровнями абстракции, при работе с СОМ-портом: http://www.linux.it/kerneldocs/serial/serial.html Т.е. при работе с /dev/ttyS# прежде, чем мы достучимся до serial.c, который представляет собой самый низкий уровень и, видимо, работает быстро, мы натыкаемся по дороге на всякие tty_io.c и n_tty.c, которые и приводят к появлению задержек... За подсказку спасибо - попробуем найти метод отключить FIFO, хотя пока не знаю где искать, непохоже, что обслуживающая порт микросхема 16C2852 это поддерживает...
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	3. "Как ускорить возврат из функции read при работе с СОМ-портом"
	Сообщение от klalafuda on 18-Май-04, 08:48  (MSK)
	>>выключите аппаратное FIFO если оно есть на плате. >Не подскажете, можно ли это сделать по стандарту UART? если этот чип совместим с UART 16550 и выше то да, для FIFO есть регистр управления, через который им можно рулить. http://ianzag.megasignal.com/ftp/pub/doc/std/comm/serial/AN-491.pdf http://ianzag.megasignal.com/ftp/pub/doc/std/comm/serial/8250_2.txt это относится к чипам типа 8250 и выше, которые предназначались для RS232, но может помочь и для других интерфейсов. весь вопрос в совестимости. если вам так нужен жесткий тайминг, то FIFO конечно же лучше запретить бо ожидание в FIFO на примем следующего байта лежат где-то в описываемых вами интервалах. другой вопрос конечно - а сможет ли Linux стабильно выдержать такой тайминг даже при корректно настроеном UARTе :) может, имеет смысл пренести такого рода логику в ядро для снижения накладных расходов по времени. взять сужествующий драйвер и немного его подправить под себя. >У нас пока подозрение, что задержка связана с уровнями абстракции, >при работе с СОМ-портом: >http://www.linux.it/kerneldocs/serial/serial.html > >Т.е. при работе с /dev/ttyS# прежде, чем мы достучимся до >serial.c, который представляет собой самый низкий уровень и, >видимо, работает быстро, мы натыкаемся по дороге на всякие >tty_io.c и n_tty.c, которые и приводят к появлению задержек... извините, на данный момент ничего не скажу по поводу Linux :) >За подсказку спасибо - попробуем найти метод отключить FIFO, >хотя пока не знаю где искать, непохоже, что обслуживающая порт >микросхема 16C2852 это поддерживает... если можно, ссылку на datasheet по микросхеме. там посмотрим, что она умеет а что нет. // wbr
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	4. "Как ускорить возврат из функции read при работе с СОМ-портом"
	Сообщение от Павел Мальцев on 18-Май-04, 16:33  (MSK)
	Используется вот это чудо враждебной техники: http://www.exar.com/products/XR16C2852v200.pdf Сейчас интенсивно копаем в указанном Вами направлении. О результатах обязательно сообщу.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	5. "Проблема решена"
	Сообщение от Павел Мальцев on 19-Май-04, 20:04  (MSK)
	Большое спасибо за совет! Проблема действительно была в FIFO. Изменив конфигурацию FIFO (уменьшив до 8-ми байт) удалось достичь желаемого времени возврата из функции read - что было нужно в любом случае, так как производится непрерывный обмен с подключенными устройствами и дело было даже не столько в своевременном контроле состояния линии, сколько, еслим можно так выразится, в принципе. Итого, код выглядит так: ---------------------------------------------- //... init serial line ..... //set fifo size   struct serial_struct ser_struct;   ioctl(*fd, TIOCGSERIAL, &ser_struct);   ser_struct.flags |= ASYNC_LOW_LATENCY;   ser_struct.xmit_fifo_size = 8;   ioctl(*fd, TIOCSSERIAL, &ser_struct); Проблему с 485-портом удалось решить, используя специальный режим контроллера порта. Режим включаем, добавив новый вызов ioctl в serial.c: вызов в программе: //set auto-CRT future   ioctl(*fd, TIOCSARTS, 1); -------------------------------------------------------------------------- добавления в serial.c:         case TIOCSARTS: /* Set Auto RTS mode on/off */         {             int lcr, fctr;             lcr = serial_inp(info, UART_LCR);             serial_outp(info, UART_LCR, 0xbf);             fctr = serial_inp(info, UART_FCTR);             serial_outp(info, UART_LCR, 0xbf);             serial_outp(info, UART_FCTR, fctr | UART_FCTR_RTS_NODELAY | ((int) arg?0x8:0));             serial_outp(info, UART_LCR, lcr);             return 0;         } -------------------------------------------------------------------------- изменения в include/asm/ioctl.h: -------------------------------------------------------------------------#define TIOCSARTS    0x5462 /* Set Auto RTS mode on/off */ ------------------------------------------------------------------------- Большое спасибо за правильно указанный с самого начала источник проблемы, с нас пиво за сэкономленные безсонные ночи.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	6. "Проблема решена"
	Сообщение от klalafuda on 20-Май-04, 11:51  (MSK)
	> >Большое спасибо за правильно указанный с самого начала источник проблемы, >с нас пиво за сэкономленные безсонные ночи. да незачто :) жаль, что я редко бываю в Москве so пиво видимо будет виртуальным. // wbr
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	7. "Проблема решена"
	Сообщение от starover (ok) on 20-Май-04, 12:28  (MSK)
	Кто сказал Москва? Вообще-то дело происходит во Львове, но Киев для пива тоже возможен.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	8. "Проблема решена"
	Сообщение от klalafuda on 20-Май-04, 13:54  (MSK)
	>Кто сказал Москва? >Вообще-то дело происходит во Львове, но Киев для пива тоже возможен. а Новосибирск ? :) // wbr
		Рекомендовать в FAQ | Cообщить модератору | Наверх

Удалить

Индекс форумов | Темы | Пред. тема | След. тема

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