ВходНаше всё Теги codebook 无线电组件 Поиск Опросы Закон Суббота
22 февраля
1494864 Топик полностью
POV (31.01.2025 15:06, просмотров: 103) ответил LightElf на Вопросец по USB возник. Софта работает с самопальным девайсом (USB FS, Custom HID). Софта может быть остановлена и снова запущена (или запущена другая). Как девайсу понять, что софтина изменилась? Есть какие-то стандартные (на уровне USB протокола) методы? Проблема в том, что у девайса есть очень большой out репорт (на много пакетов) и если софту срубили по Ctrl-C, то последний репорт приходит не полностью. Соответственно, при следующем запуске ранее принятый кусок репорта
Последний раз на сегодня китайцем балуюсь, честно-честно))) 

На уровне USB протокола нет встроенных механизмов для определения, что хост-приложение (софт) было перезапущено или заменено. USB протокол обеспечивает передачу данных между устройством и хостом, но не управляет состоянием приложений на хосте. Однако есть несколько подходов, которые можно использовать для решения вашей проблемы:

1. Сброс состояния устройства при подключении

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

Это можно реализовать на уровне firmware устройства, отслеживая состояние подключения (например, по наличию питания на шине USB).

2. Использование Control Transfers

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

Это позволит устройству сбросить свои буферы и подготовиться к новому набору данных.

3. Таймауты и сброс по таймауту

Устройство может отслеживать время с момента последнего пакета данных. Если пакеты не приходят в течение определенного времени, устройство может считать, что хост "умер" или был перезапущен, и сбросить свои буферы.

Это особенно полезно, если хост может быть остановлен аварийно (например, по Ctrl-C).

4. Использование специальных маркеров в данных

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

Это требует изменения протокола обмена данными между хостом и устройством.

5. Сброс устройства через USB

Хост может явно запросить сброс устройства через стандартные USB команды (например, SET_FEATURE или CLEAR_FEATURE). Это можно сделать при запуске софта, чтобы гарантировать, что устройство находится в известном состоянии.

6. Использование Endpoint Halt

Хост может остановить (halt) и снова запустить endpoint устройства. Это может быть использовано как сигнал для устройства, что начинается новая сессия.

Устройство может отслеживать состояние endpoint и сбрасывать свои буферы при снятии состояния halt.

7. Программный сброс через Custom HID команды

Если устройство поддерживает Custom HID, можно добавить специальную команду, которая будет сбрасывать состояние устройства. Хост может отправлять эту команду при запуске.

8. Использование USB Reset

В крайнем случае, хост может инициировать аппаратный сброс устройства через USB reset. Это приведет к полной переинициализации устройства.

Рекомендация:

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

Если у вас есть возможность изменить протокол обмена данными, добавление уникального идентификатора сессии в начало каждого репорта решит проблему "склеивания" данных.