Что я могу сделать, чтобы уменьшить задержку от этих последовательных портов, которые подключены к ПК через адаптер Serial to USB?

Я думаю, что я случайно обнаружил потребность в встроенных системах. Что здорово! И довольно страшно. И мне нужна помощь.

Предыстория : меня наняли для создания приложения с графическим интерфейсом, которое берет сканы с двух SICK LMS-291 и интегрирует их с GPS с точностью до дюйма, чтобы вы знали, где происходило каждое сканирование. Как я наивный веб-программист, я понимал, что время будет иметь важное значение, но не понимал, что это также будет сложно! Если вы не знаете, когда произошла каждая точка GPS и каждое сканирование, вы не сможете определить, где происходит сканирование. К сожалению.

Они указали Windows 7 в качестве платформы, а также купили коробку SeaLevel RS422 для USB, чтобы подключить датчики и GPS, и в скором времени я обнаружил свою глупость. Где-то между датчиками и моей компьютерной программой что-то препятствовало своевременному поступлению сканов. LMS выдает 75 сканирований в секунду или 13,32 мс / сканирование. Моя программа не получает их своевременно. Он получает их каждые 100 или около того миллисекунд, группами по 7, 8, 10 или около того. Также иногда появляется недостаточно сканов, или они искалечены. Либо этот адаптер SeaPort отправляет только десять раз в секунду (это возможно? Я не знаю, как работает USB), либо Windows не проверяет буфер (где-то должен быть буфер, верно?) Достаточно часто.

Сегодняшний день : это приводит к некоторым неточностям, с которыми клиент в основном согласен. Я не, тем не менее, и так как у меня есть шанс сделать аналогичную работу для клиента (объединяя больше входов датчиков!), Я хотел бы выяснить, как сделать это правильно, например, учитывая точность GPS , быть в состоянии дать гарантии о точности и точности мест сканирования.

На что это похоже? Мне нужен пользовательский интерфейс и возможность проверять ввод с этих трех устройств каждые 13,32 миллисекунды. Если бы я использовал FreeRTOS с, скажем, Nano-X для графического интерфейса пользователя, работающего на ноутбуке, который они предоставляют, это звучало бы как нормальное решение? Возможно ли, что переход от RS-422 к USB вызывает эти задержки, и использование Windows на самом деле вполне подходит для этой цели?

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

Самым простым решением будет лучший интерфейс RS422, в идеале на основе PCI / PCI-e. Это решило бы проблемы с задержкой.

Вы также можете изменить частоту опроса USB, хотя это довольно сильно зависит от операционной системы хоста (на какой платформе вы работаете?).

Что бы это ни стоило, я заглянул на веб-сайт системы sealevel, и он МАССОВНО заражен маркетинговой ерундой. Они буквально тратят, как 10 страниц и несколько официальных документов, говоря: «Мы используем USB-концентратор внутри, а не выполняем мультиплексирование MCU».

Эй, SeaLevel! Вот что делает дешёвый 4-портовый USB-последовательный интерфейс за $ 50, который я купил на e-bay в Китае! Вы не особенный человек, даже если вы пишете полдюжины пустых листовок, пытаясь заставить их звучать так, как вы!

Вы пытались заставить эти вещи использовать драйверы FTDI? Я бы положил на это деньги, они просто используют болотный стандарт FTDI FT232 или аналогичный. Можете ли вы открыть коробку на одном из них и сфотографировать?

Если вы действительно хотите раскрутить свое собственное оборудование для развлечения или обучения, я настоятельно рекомендую вам не пытаться делать все на оборудовании. Поскольку вам нужно просто коррелировать по времени все три сигнала, все, что вам действительно нужно, это что-то, что может прослушивать три последовательные линии (две RS422, одна RS232 (GPS)), снабжать метками времени данные и направлять их на главный компьютер. ,

После того, как данные имеют временную отметку, вы можете свободно использовать любую задержку буфера, поскольку вы всегда можете просто посмотреть на временные отметки.

Реально, если у вас нет базовых аппаратных средств, разработка чего-либо с достаточной сложностью для создания хорошего графического интерфейса - это достаточно сложная задача.

Лично я бы, наверное, бросил довольно массивный ARM MCU на проблему с буферизацией, и с этим покончено. Несмотря на то, что это Arduino, у Arduino Due много SRAM, и он более чем достаточно быстр для того, что вам нужно (и есть много поддержки, что всегда приятно).
В качестве альтернативы, серия STM32 имеет аналогичную производительность и больше предназначена для «продвинутых» пользователей (читайте, примеров меньше или нет ссылок для ссылок). ST делает много очень хороших, очень недорогих плат для оценки .

Благодаря Due вы получаете собственный USB-порт, для которого вы можете использовать свой собственный драйвер CDC, если хотите. Некоторые платы STM32 также имеют встроенный USB.

Если я понимаю вопрос, к чему это сводится, так это к получению сообщений времени / места от GPS по одной последовательной линии и корреляции сообщений данных о дальности, полученных по другим последовательным линиям. В идеале сообщения дальномера должны иметь свою собственную метку времени, и если бы вы могли синхронизировать все часы, вы могли бы определить местоположение, где был взят диапазон, путем интерполяции метки времени между двумя сообщениями GPS с помощью метки времени ближайшего совпадения. Но, конечно, у вас этого нет.

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

Таким образом, для более простого решения все, что вам нужно, это какой-то способ собрать все сообщения из нескольких различных последовательных линий, объединить их в один поток в порядке их поступления и накачать их на ПК. Вы можете сделать вывод, что любое сообщение дальномера между двумя сообщениями GPS происходило когда-то между этими двумя сообщениями.

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

Для более сложного решения вы можете сформировать локальные часы в микро и использовать GPS для синхронизации этих часов, так что когда вы получаете сообщение о дальности, вы можете получить отметку времени, используя часы микро. Используя микро с кристаллической временной базой, вы, вероятно, могли бы обойтись с сообщениями GPS на 1 Гц и все еще получить намного лучше, чем времена точности миллисекунды, отмеченные на сообщениях диапазона. Компетентный специалист по встраиваемым системам, вероятно, мог бы также выполнить это в ассемблере на нижнем конце микро, но вы упомянули, что только начинаете. Вы могли бы взглянуть на более мощный микро, который может работать под Linux, и, возможно, найти уже существующее решение для синхронизации часов Linux с GPS.

Я бы, вероятно, сделал бы мультиплексирование последовательных данных в новый последовательный поток данных с более высокой скоростью со статическим чередованием. Затем передайте поток данных через USB-UART на компьютер. Таким образом, вы бы знали, что первый байт от устройства 1, второй байт от устройства 2, третий байт от устройства 3 и в этом случае четвертый байт как CRC или порядковый номер. Добавьте пару байтов начала маркера кадра для синхронизации в потоке данных, добавляя байты, если нет доступных данных, и все готово. Вы можете не знать абсолютное время, но вы знаете, что это относительное время между различными порциями данных.

Я также пошел бы с микроконтроллером, чтобы получить данные RS, отметку времени и передать это к ПК. Вы не можете выполнять работу, связанную с синхронизацией ввода / вывода, с ПК с Windows (возможно, за исключением звуковой карты), потому что программное обеспечение и драйверы постоянно меняются по мере обновления драйверов за вашей спиной.

Но первое, что я хотел бы сделать, - это приобрести USB-логический анализатор, вы можете купить его менее чем за 100 долларов США, получить некоторые сообщения от GPS-приемника и точно проверить, когда будет получен каждый байт. Используйте эту информацию, чтобы попытаться / точно рассчитать, насколько точны данные в первую очередь: например, что именно и когда передает блок GPS. Затем вы сможете выяснить, какая точность достижима и сколько усилий вы готовы приложить, чтобы достичь определенного уровня точности.

Выше фото какого-то (Saleae?) USB логического анализатора.

[Править] Ха-ха, использование звуковой карты может быть забавным способом заставить ее работать на самом деле; Вы можете подключить данные UART к входу звуковой карты (через некоторые резисторы и конденсаторы) и написать программное обеспечение для обнаружения каждого фронта в последовательном потоке, обеспечивая прекрасную точность синхронизации !. Хорошо, я не действительно предлагаю это серьезно, просто для некоторых смеется!