Чтение данных из разных драйверов UART

c serial-port linux-device-driver embedded-linux uart

429 просмотра

1 ответ

79 Репутация автора

У меня проблема из-за различий в поведении драйвера UART при переносе приложения из старой системы на основе ARM в новую. Это встроенные системы Linux, одна из которых Atmel AT91 с ядром 2.6.14, а другая - Freescale iMX6 с 3.14.38. Мое заявление написано в с.

Старый, похоже, имеет 10 приемных буферов по 50 байт каждый (я видел это в исходном коде ядра), в то время как новый, кажется, по крайней мере 1 из 4096 (вычтено из тестирования).

Это означает, что когда я пытаюсь прочитать данные из порта, в старой системе мне нужно будет подождать 50 раз символьное время, прежде чем я получу некоторые данные, тогда как в новой системе мне, возможно, придется ждать 4096 символов, прежде чем я получу данные. получить любые данные. Это связано с работой DMA в драйвере UART. Драйвер не будет передавать никакие данные, пока не будет заполнен буфер или не будет обнаружен конец передачи.

Это не было бы проблемой, если бы я узнал, что я получу ответ каждый раз (т. Е. Передача занимает то, что требуется, в зависимости от объема данных), но при работе в качестве ведущего и при общении с подчиненными на шине вы можете отправлять запросы на устройства, которых там нет, поэтому вы не получите ответ. В этом сценарии мои конфигурации тайм-аута должны быть очень разными, поскольку старая система дает мне намного более быстрый ответ на тайм-аут.

Я проиллюстрирую это на примере. У меня есть функция чтения из порта, пока нет больше данных. «читать» блоки до тех пор, пока не появятся какие-либо данные или не истечет время ожидания.

Если передача составляет 2048 байтов:

В старой системе функция читает: 50 байтов 20 раз, а затем 48 байтов. В новой системе функция читает: 2048 байт.

  • При 9600 бод 50 байтов занимают 52 миллисекунды
  • На 9600 бод 2048 байт требуется 2,13 секунды
  • При 9600 бод 4096 байт занимают 4,26 секунды

Поскольку я не знаю длину ответа, который я собираюсь получить, я должен пойти в худшем случае и предположить, что он может быть> 4096 байт:

В моей старой системе я мог настроить порт на время ожидания ConfiguredTimeoutTime+ 52 миллисекунды. В новой системе мне нужно будет установить значение ConfiguredTimeoutTime+ 4260 миллисекунд.

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

Это значительная разница, означающая, что каждый не отвечающий раб вводит почти 4-х секундную задержку в моем времени опроса.

Вопросы:

  • Могу ли я что-нибудь сделать из своего кода, чтобы получить результаты, подобные тем, что были в моей старой системе?
  • Могу ли я попросить поставщика новой системы измениться при сборке ядра?
  • Я полностью упускаю суть, и есть гораздо лучший способ сделать это на обеих системах?

Извините за длину сообщения, я не мог видеть, как сократить это дальше! Спасибо!

Автор: Dan Источник Размещён: 18.07.2016 11:56

Ответы (1)


1 плюс

89 Репутация автора

Попробуйте установить тайм-аут чтения на 100 миллиллисекундов, как показано ниже, чтобы добиться свободы от буферов разных размеров. При чтении и возврате он либо будет иметь данные, либо нет.

currentconfig.c_cc[VTIME] = 1;
currentconfig.c_cc[VMIN] = 0;

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

Автор: samuel05051980 Размещён: 22.08.2016 05:02
Вопросы из категории :
32x32