Пропуск данных при приеме через UART средствами VISA

[Artem.spb]

Когда прилетает сплошным потоком, абсолютно неважно сколько вычитывать за раз.

Если запросить 100, а выдаст только 10, ещё и ошибку выдаст. Не люблю я это

[AndreyDmitriev]

Когда прилетает сплошным потоком, абсолютно неважно сколько вычитывать за раз.

Если запросить 100, а выдаст только 10, ещё и ошибку выдаст. Не люблю я это

Это, кстати, именно то, что рекомендовали на форуме NI — запрашивать гарантированно больше данных, чем прилетает в сообщении (скажем 4096), но мне такой путь тоже не нравится. Запрашивать надо столько, сколько ожидается. Вообще там всё достаточно детерминировано, как выше отмечалось, работает по прерываниям, и использовать запрос количества байтов нужно ну очень редко (такой код имеет тенденцию периодического опроса, что не есть хорошо), чистого VISA Read с правильно установленным значением ожидаемого количества байт в 99% случаях достаточно.

[Borjomy_1]

Просто если запрашивать больше, то не избежать задержек по таймауту чипа. А это иногда критично

[AndryG]

Просто если запрашивать больше, то не избежать задержек по таймауту чипа. А это иногда критично

Вот кстати еще проблема,принимаю несколько разных пакетов по протоколу MavLink и Visa жутко тормозит,пакеты читаются ,но с задержками превышающими 200 и более мс,в контоллере я использую очередь,каждый пакет отправляется ,примерно, каждые 6 мс,вот как реализовывать прием протокола? Это пока черновик,но принцып приема виден.

[Borjomy_1]

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

[AndryG]

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

Bytes at Port нужен для понимания есть ли вообще что-то в буфере,я читал на форуме,как его не любят),длины пакетов разные,длина пакета,вернее полезных данных,находится в 5 байте,только тогда понятно сколько принимать.Да я еще заметил,что на разных скоростях работы порта по разному обрабатываются данные,причем не обязательно эта скорость передачи должна быть выше.

[Borjomy_1]

В любом случае, при вызове VISA read происходит ожидание прихода заданного числа символов по таймауту.

[AndryG]

Сделал некое подобие Сишарковского кода,но работает еще хуже чем первый вариант(image-removebg-preview (20).png

Удивительно, что оно вообще заработало

Вот мы ищем синхро последовательность, для этого организовали FIFO на два байта.
Если нашли - читаем информацию, если нет - продолжаем искать.
1.png
Читаем 12byte.
Следующий этап - проверка синхронизации.
2.png
Если синхро последовательность - читаем информацию, если нет - ищем синхронизацию.
3.png

Как-то так, но нужно проверить, т.к. делал без запусков, по наитию
Serial.vi

У меня еще вопрос по приему данных.Принимаю непрерывно поток данных ,контроллер выдает их с периодичностью 12 мс,я не всегда успеваю обработать данные,как организовать фиксированный FIFO буфер,настроенный при инициализации,чтобы я дальше в программе обрабатывал данные ,накопленные в нем и не терял пакеты.

[Borjomy_1]

Буфер VISA по умолчанию, фактически, если не изменяет память, не менее 8кБ. Это надстройка над аппаратным буфером микросхемы приемо-передатчика. Поэтому беспокоиться о том, что он закончится, не имеет смысла. Но для повышения быстродействия отклика имеет смысл в ДРАЙВЕРЕ последовательного порта установить FIFO на прием, как раз 1 байт. Тогда буфер VISA будет обновляться по каждому принятому байту.
Ну и напоследок задам вопрос про 12 мс. А скорость-то у вас какая? Просто при скорости 9600 время передачи каждого байта составляет 10.4 мс.

[IvanLis]

У меня еще вопрос по приему данных.Принимаю непрерывно поток данных ,контроллер выдает их с периодичностью 12 мс,я не всегда успеваю обработать данные,как организовать фиксированный FIFO буфер,настроенный при инициализации,чтобы я дальше в программе обрабатывал данные ,накопленные в нем и не терял пакеты.

Что касается буфера UART Вам ответили.
Если не успеваете именно между пакетами обработку сделать, то нужно ....
В принципе не рекомендуют вообще в циклах, работающих в RealTime делать недетерминированные вычисления.

Делайте очереди и отправляйте данные в другой цикл. Т.е. один цикл работает только на прием (с железом), а другие циклы занимаются обработкой.
Можно сделать обработку в несколько этапов, каждый этап в своем цикле, в этом случае Вы как бы разносите задачу, что позволяет уменьшить латентность.

[AndryG]

Буфер VISA по умолчанию, фактически, если не изменяет память, не менее 8кБ. Это надстройка над аппаратным буфером микросхемы приемо-передатчика. Поэтому беспокоиться о том, что он закончится, не имеет смысла. Но для повышения быстродействия отклика имеет смысл в ДРАЙВЕРЕ последовательного порта установить FIFO на прием, как раз 1 байт. Тогда буфер VISA будет обновляться по каждому принятому байту.
Ну и напоследок задам вопрос про 12 мс. А скорость-то у вас какая? Просто при скорости 9600 время передачи каждого байта составляет 10.4 мс.

Спасибо,примерно понятно,скорость порта 38400 , 56 байт в пакете.

[AndryG]

У меня еще вопрос по приему данных.Принимаю непрерывно поток данных ,контроллер выдает их с периодичностью 12 мс,я не всегда успеваю обработать данные,как организовать фиксированный FIFO буфер,настроенный при инициализации,чтобы я дальше в программе обрабатывал данные ,накопленные в нем и не терял пакеты.

Что касается буфера UART Вам ответили.
Если не успеваете именно между пакетами обработку сделать, то нужно ....
В принципе не рекомендуют вообще в циклах, работающих в RealTime делать недетерминированные вычисления.
5C0E158F-ADC8-4668-BE9D-DA58BBB42EEB.png
Делайте очереди и отправляйте данные в другой цикл. Т.е. один цикл работает только на прием (с железом), а другие циклы занимаются обработкой.
Можно сделать обработку в несколько этапов, каждый этап в своем цикле, в этом случае Вы как бы разносите задачу, что позволяет уменьшить латентность.

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

[Borjomy_1]

Подождите... на дворе 2025 год. Вы не можете 56 байт посылку за 12 мс обработать?

[AndryG]

Подождите... на дворе 2025 год. Вы не можете 56 байт посылку за 12 мс обработать?

При скорости 38400 56 байт передаются по времени ≈14.6ms,что и является похоже проблемой,потому как я пропускаю синхробайт следующего пакета,нужно поток байт сохранять,а я этого не делаю,вот и вопрос из-за этого возникает.Буфер на стороне контроллера есть,он непрерывно перезаполняется и байты из пакета не теряются.Скорость поднять больше не могу из-за особенностей радиомодема.

[IvanLis]

При скорости 38400 56 байт передаются по времени ≈14.6ms,что и является похоже проблемой,потому как я пропускаю синхробайт следующего пакета,нужно поток байт сохранять,а я этого не делаю,вот и вопрос из-за этого возникает.Буфер на стороне контроллера есть,он непрерывно перезаполняется и байты из пакета не теряются.Скорость поднять больше не могу из-за особенностей радиомодема.

Читайте по 1 байту из аппаратного буфера, т.е. фактически он постоянно будет пустой.
И сделайте программный буфер, который Вы уже будите обрабатывать в программе, искать там синхропоследовательность и все остальное.... Но только делайте отдельные циклы на прием и обработку.

В принципе мне не очень проблема понятна, если сначала был пакет 14byte, теперь 56byte.
Вы можете описать структуру пакета и протокол обмена?

Если длина пакета не меняется, то нет необходимости постоянно искать синхропоследовательность.
Достаточно ее один раз найти и потом только проверять ее наличие (пример)