Жизнеспособность туннелирования проприетарных CUNet rs485 соединений по IP - PullRequest
Новая
       78

Жизнеспособность туннелирования проприетарных CUNet rs485 соединений по IP

0 голосов
/ 06 февраля 2020

Мне было поручено создать средство туннелирования устаревшего проприетарного соединения RS485 по IP. Рассматриваемые устройства - это видеокамера Pan / Tilt head и ее панель управления, сделанные Panasoni c. Неудобное дополнение заключается в том, что устройства используют микросхемы MKY40 от StepTechnica, которая использует свой протокол CUNet для распределенной совместно используемой памяти для микроконтроллеров.

Краткий обзор протокол CUNet: каждая сеть имеет 256 байтов памяти, разделенных на количество подключенных устройств. На каждом цикле каждая микросхема передает свой срез по очереди. Поэтому он может записывать только свой собственный фрагмент и читает каждый второй фрагмент. Далее следуют два дополнительных цикла для бухгалтерского учета и прямой системы обмена сообщениями между чипами. Существует процедура рукопожатия и синхронизации, которая четко не описана в руководстве.

Это то, что я знаю и то, что я пробовал до сих пор:

  • Использование осциллографа Я измерил сигнал 3 МГц на линиях. Я предполагаю, что это означает, что используется скорость 3 Мбит / с. StepTechnica перечисляет устройство, способное использовать 3, 6 или 12 Мбит / с.
  • Я использовал два кабеля FTDI rs485-usb и попытался написать простую C программу, которая записывает все, что читает с кабеля A на кабель B и наоборот.
  • Вышеуказанный подход, конечно, ограничен задержками от порта USB. Я пытаюсь минимизировать это, устанавливая время буфера в 1 в драйверах FTDI (я использую Linux). Я также попытался использовать локальное эхо-включение или отключение и правильно подключил кабели.
  • Из руководства CUNet я пришел к выводу, что время, которое обычно требуется для распределения 256 байтов разделяемой памяти на MKY40 составляет 1,5 мс. Я предполагаю, что после нескольких попыток он истечет, и, возможно, я просто недостаточно быстр (учитывая задержки в моей системе и хост-контроллер / драйверы USB и т. Д. c).

Следующий шаг, о котором я думаю, - это использование аппаратного обеспечения, которым я имею больше контроля, чем USB. Например, я мог бы использовать дифференциальные операционные усилители RS485 для подключения сигналов к GPIO RaspberryPi. Тем не менее, я также обеспокоен тем, что, даже если это сработает, присущие IP задержки в конечном итоге сделают это непригодным для использования. Протокол CUNet кажется действительно неумолимым.

Любой вклад приветствуется, особенно в отношении жизнеспособности этого проекта:)

...