-
Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram
Нужна помощь Usb удлинитель из v3
- Автор темы Alex58
- Дата начала
Попробую объяснить, почему ни STM, ни TLSR не поможет в вашей затее. Вы продолжаете считать что любой абстрактный сигнал USB можно передать по wifi, а это не так. Что CAN, что USB - это физический транспорт, в которых полезная информация строго завязана на тайминги при передачи сигналов. Это означает, что никакие задержки сигнала недопустимы, а если возникнут, то с большой вероятностью приведут к разрушению полезной информации. Следовательно, соединение CAN и USB должны быть проводными для возможности получить информацию по какому либо протоколу. А это значит, что декодирование протокола должно осуществляться на стороне диагностического оборудования. CAN <-> USB <-> Decoder. Дальше уже можно задействовать каналы wifi, поскольку это уже интерфейс связи с человеком, который тайминги соблюсти не может в силу своей природы.
Поэтому ваше устройство со стороны диагностики должно уметь полностью поддерживать те протоколы CAN, о которых вы упомянули. Т.е. Вы эти протоколы должны реализовать в МК, декодировать информацию и передать условному приемнику. А если так, то на принимаемой стороне программа уже либо заподозрит "ненужное соседство", либо всю процедуру реализации протокола CAN нужно будет провернуть в обратную сторону, как фарш через мясорубку.
И это я ещё не говорю про обратную связь от условного приемника до диагностического оборудования. Программы же считают что у них физическое соединение и ответ ожидают соответственно. Не удивлюсь, если Panasonic там ставит свои драйвера для работы с оборудованием в обход операционной системы.
То что вам предложили по ссылкам выше, как раз реализует связку CAN <-> USB <-> Decoder/Encoder. Но вот дальше с ним уже должна работать программа, которая понимает что она подключается к такому оборудованию, и не пугаться этого.
Поэтому ваше устройство со стороны диагностики должно уметь полностью поддерживать те протоколы CAN, о которых вы упомянули. Т.е. Вы эти протоколы должны реализовать в МК, декодировать информацию и передать условному приемнику. А если так, то на принимаемой стороне программа уже либо заподозрит "ненужное соседство", либо всю процедуру реализации протокола CAN нужно будет провернуть в обратную сторону, как фарш через мясорубку.
И это я ещё не говорю про обратную связь от условного приемника до диагностического оборудования. Программы же считают что у них физическое соединение и ответ ожидают соответственно. Не удивлюсь, если Panasonic там ставит свои драйвера для работы с оборудованием в обход операционной системы.
То что вам предложили по ссылкам выше, как раз реализует связку CAN <-> USB <-> Decoder/Encoder. Но вот дальше с ним уже должна работать программа, которая понимает что она подключается к такому оборудованию, и не пугаться этого.
я например понял автора иначе.
У него есть устройство которое управляется через USB и отдает данные через USB
Он хочет сделать адаптер USB-воздух-usb.
что вполне реально.
Выше ссылка на устройство в котором уже есть bluetooth
т е в комп надо поставить свисток.
-------------------
либо сделать эту связь на TLSR или на ESP266 реализация USB есть в инете.
Девайсы для проброса usb по ethernet клепают. Но продукт не массовый, к нему нужны драйвера и есть сомнения в совместимости с устройствами. И stm32 + пара вечеров там и не пахнет
Вы уверены, что два условия совместимы? Я нет.
поясните о каких условиях вы говорите.
-------------------
@nikolz
1. о том что дилерская программа со своей виндой заработает при установке в комп свистка
2. То что дилерская программа сможет работать через свисток
По вашей ссылке предлагается оборудование для работы с программами адаптированными для этого. Это отличное решение, если оно устроит ТС, конечно.
Ну и отзывов реальных там к сожалению нет. Только сообщение, что диски пришли без этих самых программ
1. о том что дилерская программа со своей виндой заработает при установке в комп свистка
2. То что дилерская программа сможет работать через свисток
По вашей ссылке предлагается оборудование для работы с программами адаптированными для этого. Это отличное решение, если оно устроит ТС, конечно.
Ну и отзывов реальных там к сожалению нет. Только сообщение, что диски пришли без этих самых программ
согласен, что чип за 100 копеек не решает проблему.@nikolz
1. о том что дилерская программа со своей виндой заработает при установке в комп свистка
2. То что дилерская программа сможет работать через свисток
По вашей ссылке предлагается оборудование для работы с программами адаптированными для этого. Это отличное решение, если оно устроит ТС, конечно.
Ну и отзывов реальных там к сожалению нет. Только сообщение, что диски пришли без этих самых программ
если работать серьезно то лучше купить готовое.
из своего опыта знаю что продавцы отвечают на проблемы и дают софт если просят
pvvx
Активный участник сообщества
Читаем хотя-бы вики, со слов "Управляющий канал предназначен для обмена с устройством короткими пакетами «вопрос-ответ»."
USB — Википедия
Мотом смотрим на табличку пропускной способности.
Получаем, чтобы обеспечить USB1.1 уже в предел хватает времени "пинга" по проводной местной интрасети...
ESP сразу отпадает, т.к. это на пределе его возможностей и писать уже с asm вставками, а не какие Arduino.
В принципе USB1.1 - это пакетики до 64 байт с шагом в 1 ms. Но надо обеспечить и прием-передачу заголовков.
Под полностью разобранное USB1.1 устройство (зная полную карту) что-то сделать можно.
USB — Википедия
Мотом смотрим на табличку пропускной способности.
Получаем, чтобы обеспечить USB1.1 уже в предел хватает времени "пинга" по проводной местной интрасети...
ESP сразу отпадает, т.к. это на пределе его возможностей и писать уже с asm вставками, а не какие Arduino.
В принципе USB1.1 - это пакетики до 64 байт с шагом в 1 ms. Но надо обеспечить и прием-передачу заголовков.
Под полностью разобранное USB1.1 устройство (зная полную карту) что-то сделать можно.
Есть такая штука как USB/IP. Оно встроено в mainline linux начиная c 3.17
Клиент под Win: barbalion/usbip-win-client
Вроде бы можно поднять в openwrt:
OpenWrt Project: USB over IP tunnel
Т.е в теории берем роутер на openwrt с усб хстом втыкаем в егойный усб хост фирменный свисток, на винду ставим usbip клиента и оно по tcp/ip пробрасывает usb.
Но как оно будет работать с фирменными программами (и будет ли работать вообще) - тайна покрытая мраком.
Может несколько не в тему. ТС Вы уверены что решив ЭТУ задачу Вы сохраните свою зарплату ??? Кому нужен сотр. который не подходя к машине сидя в сторонке на компе будет впаривать ШЕФУ что все отлично с авто ? С технической стороны я за ВАС руками и ногами, а с практической ты роешь себе могилу.
pvvx
Активный участник сообщества
Плохо "работает". На USB1.1 пакетики бегают чаще 1 мс:
А пинг сети зависит от нагрузки. На WiFi вообще никак...
Обычно USB софт ожидает завершение транзакции в течение какого-то времени и в большинстве случаев существенно больше чем 1ms. Так что среднестатистические усб устройства могут работать при некотором везении. Софт от вендоров надо проверять. Если он заточен на жесткий реалтайм с проприетарными драйверами и спецвиндой - не заработает.
Пинг в конфигурации ПК-роутер при отсутствии других клиентов существенно менее 1ms. При забитом эфире и множестве клиентов wifi а также через интернет работать не будет 100%.
pvvx
Активный участник сообщества
А это ныне норма в городе.
При включении простой usb-wifi заглушки (размером с разъем и без внешней антенны) в комп сразу ловит от 50-ти AP
Колесо мыши крутить в списке WiFi в Win10 надоело...
pvvx
Активный участник сообщества
Вот сегодня испытывал свою прогу с USB CDC в TLSR8269. По USB1.1 вышли пакеты по 64 байта идущие в среднем данных каждые 0.5 us (это не предел, т.к. расчет на несколько через хаб). И функция близка к требуемой у ТС - запись внешнего контроллера (запрос-ответ по USB).
Пример такой-же дуплексной передачи на ESP-NOW можете представить?
Пример такой-же дуплексной передачи на ESP-NOW можете представить?