AlexandrY 3 4 июля, 2019 Опубликовано 4 июля, 2019 · Жалоба 11 minutes ago, mantech said: Поэтому драйвера всегда делаю и тестирую сам, ибо уже обжигался на том же MQXe? где все должно работать на ура вроде как... Драйвер SDIO для WiFi модуля вряд ли напишите. Придется уповать только на готовые драйвера под RTOS-ы. Ибо драйверы эти огромны. А че кстати на MQX-е не пошло? Ось достойная. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mantech 53 4 июля, 2019 Опубликовано 4 июля, 2019 (изменено) · Жалоба 2 часа назад, AlexandrY сказал: А че кстати на MQX-е не пошло? USB стек. Глючило сильно при горячем подключении и отключении. Тестовые проги брал из поставляемых к оси демо программ. 2 часа назад, AlexandrY сказал: Драйвер SDIO для WiFi модуля вряд ли напишите. Придется уповать только на готовые драйвера под RTOS-ы. Не обязательно принципиально с нуля сидеть и писать, но при наличии открытых исходников, можно их просмотреть, погонять при включении необходимого функционала и проверить в соотв. с даташитом, наконец... Был типичный пример - BSP для прца МХ6, исходник от производителя, СД контроллер. Запуск - все работает, включаешь чтение блоками и случайно выдернул карту - драйвер завис намертво. На запись тоже не все ок, с "медленными" картами просто не писал блоки... Оказалось, не обрабатывается пара флагов контроллера, сделал доработку, все норм, на чтение и на запись, включая тестирование с "пристрастием". А еслиб это была закрытая либа? Что мне делать, писать авторам "помогите, спасайте", ждать 3-5 месяцев, пока они там пофиксят - да ну нафиг! Плюс, как в любом сервисе доказывать, что ты не верблюд, и правильно все используешь... Изменено 4 июля, 2019 пользователем mantech Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 4 июля, 2019 Опубликовано 4 июля, 2019 · Жалоба 1 hour ago, mantech said: USB стек. Глючило сильно при горячем подключении и отключении. Тестовые проги брал из поставляемых к оси демо программ. USB в MQX работает железно, проверено многократно. Вот в этом моторном приложении - https://habr.com/ru/post/403525/ работает на USB HS одновременно 2-а VCOM-а, чуть раньше там была статья как видео качается через USB стек MQX. Демо программы наверно запускали на демо платах. Вот это действительно плохо. Демо платы у всех отвратные в смысле схемотехники. 1 hour ago, mantech said: Не обязательно принципиально с нуля сидеть и писать, но при наличии открытых исходников, можно их просмотреть, погонять при включении необходимого функционала и проверить в соотв. с даташитом, наконец... Ну вот "Не обязательно ... с нуля". Не, не настаиваю конечно, можете полгода потерять и переписать. Но потерять полгода это слишком больно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mantech 53 4 июля, 2019 Опубликовано 4 июля, 2019 (изменено) · Жалоба 14 минут назад, AlexandrY сказал: USB в MQX работает железно, проверено многократно. Да видать не на всех камнях. Проверял на плате от стартеркита с процом vibrid mvf6... дальше циферки не помню. 14 минут назад, AlexandrY сказал: Но потерять полгода это слишком больно. Ну.. за полгода можно почти всю ось поднять, не линухового масштаба, конечно... На драйвер пару недель уходило, если уж совсем топорно написано... Изменено 4 июля, 2019 пользователем mantech Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 4 июля, 2019 Опубликовано 4 июля, 2019 · Жалоба Тогда не понял USB на MQX подняли или нет? Там кстати и WiFi драйвера к чипам Qualcomm Atheros были. Если вы такой супергерой то могли бы и похвастаться. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
yes 8 4 июля, 2019 Опубликовано 4 июля, 2019 · Жалоба а про эти Wi-FI модули вопрос: у них у всех есть прошивки (типа фирменные/протестированные) с поддержкой АT команд? есть какая-либо стандартизация этих АТ команд? то есть минимальный набор, соединится с какой-то предопределенной сетью, отправить/принять строку. ну или хотя бы какой-то метод работы с разными - ну например запрос вендора и по нему набор ... и как эти посылаемые строки выглядят на другом конце - то есть может ли там быть не идентичный удлинитель, а какое-то чужое устройство, например планшет? что там тогда - есть какой-либо явный или неявный протокол? ну там UDP, TCP с какими-то предопределенными портами, форматами. я что-то не увидел в описании АТ прошивки для ESP такого описания... на текущий момент выбрали модуль на MediaTek MT5931SA. известно ли в нашем сообществе? ------------------------- а по поводу разработки и надежности - может у нас некая особая ситуация - работаем со статистическими радиосигналами - то есть решения может и не быть, поэтому занимает вопрос параметров (динамика объекта разная, например), подбор критериев отбраковки и т.д - то есть очень много шаманства. соответственно проблемы с которыми сталкивается саппорт вообще никак не связаны с RTOS, middleware, TCP/IP и т.д. или вернее, проблемы глюков на уровне "системы" находятся (и решаются) за счет длительного тестирования продукта в процессе "шаманства". то есть тайм-ту-маркет или стоимость железа не являются критериями, что позволяет халявить. так еще сложилось, что все программистские коллективы, с которыми я сталкивался по работе, предпочитали простоту и открытость системного софта, а не сертифицированость и раскрученность. то есть продукты были на eCos, Linux, FreeRTOS, RTEMS (за 20+ лет) но ни разу на QNX, MQX и каких-то еще "профессиональных" пропиентарных системах. наверно, это не совсем правильный подход, но что есть, то есть... видимый недостаток - это нежелание переходить на новые платформы, процессоры и т.д. но вроде бы пока справляемся. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 4 июля, 2019 Опубликовано 4 июля, 2019 · Жалоба 48 minutes ago, yes said: на текущий момент выбрали модуль на MediaTek MT5931SA. известно ли в нашем сообществе? Т.е. вы выбрали модуль с MediaTek и связующим процессором на модуле обрабатывающим AT команды типа такого - http://www.hi-flying.com/hf-lpt100 ? Два сокета, 3 сек цикл приема-ответа. Суровые ограничения, зато эталон простоты! Bluetooth здесь был бы быстрее. 48 minutes ago, yes said: есть какая-либо стандартизация этих АТ команд? Ну какая стандартизация, шутите? Эт исключительно полет фантазии программера той фирмы которая делает модули. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
yes 8 4 июля, 2019 Опубликовано 4 июля, 2019 · Жалоба 1 minute ago, AlexandrY said: Т.е. вы выбрали модуль с MediaTek и связующим процессором на модуле обрабатывающим AT команды типа такого - http://www.hi-flying.com/hf-lpt100 ? Два сокета, 3 сек цикл приема-ответа. спасибо за замечание! да, этот модуль показался более простым. а как вывели это время? я так понял, что 50мс задержка The UART will wait 3 sec... я так понял (наверно ошибочно), что это некий таймаут, а не цикл обмена. Проясните, если не сложно, 3 секунды совсем не то, что надо. и вообще они обходятся одним сокетом для UART --------------------------- а какие задержки достижимы в лучшем случае, то есть с использованием другого чипсета, запрограммированного на минимум задержки? понятно, что все это вероятностное, но в идеальных условиях Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 4 июля, 2019 Опубликовано 4 июля, 2019 · Жалоба 2 hours ago, yes said: The UART will wait 3 sec... я так понял (наверно ошибочно), что это некий таймаут, а не цикл обмена. Проясните, если не сложно, 3 секунды совсем не то, что надо. и вообще они обходятся одним сокетом для UART --------------------------- а какие задержки достижимы в лучшем случае, то есть с использованием другого чипсета, запрограммированного на минимум задержки? понятно, что все это вероятностное, но в идеальных условиях Так на прием же вы не знаете сколько получите. Т.е. будете вынуждены тот самый таймаут ждать. Задержка же общения по WiFi действительно очень вероятностная. У меня минимальна получалась 950 мкс на диапазоне 5 ГГц и 1000 мкс на диапазоне 2.4 ГГц На диапазоне 5 ГГц дисперсия может составить два порядка. На 2.4 ГГц дисперсия где-то 2 мс Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
yes 8 5 июля, 2019 Опубликовано 5 июля, 2019 · Жалоба 16 hours ago, AlexandrY said: Так на прием же вы не знаете сколько получите. Т.е. будете вынуждены тот самый таймаут ждать. ну это таймаут бай дезайн - то есть так запрограммировано, чтобы команды от данных отличать... а если в прозрачном режиме, то есть без АТ команд, должно определятся стеком+передатчиком, я так понимаю, что используют ТСР, то есть с подтверждением доставки - вот тут нет у меня опыта. если говорите 2мс, то нормально... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 243 5 июля, 2019 Опубликовано 5 июля, 2019 · Жалоба 1 час назад, yes сказал: ну это таймаут бай дезайн - то есть так запрограммировано, чтобы команды от данных отличать... Прямые реализации протокола обмена не должны зависеть от каких-то задержек. Задержки - это костыль. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_3m 9 5 июля, 2019 Опубликовано 5 июля, 2019 (изменено) · Жалоба 2 часа назад, yes сказал: ну это таймаут бай дезайн - то есть так запрограммировано, чтобы команды от данных отличать... За протокол на основе таймаутов - пожизненный эцих с гвоздями !!! Перепиливать придется. При передаче по wifi задержки плавают: более 90% - 1ms, 95% - 10ms а 0,5% доходит до сотен ms. Я тестировал UDP echo на ESP32 в локальной сети. Потерь пакетов за день не было. С TCP примерно так же только минимальное время 1,5-2ms. Изменено 5 июля, 2019 пользователем _3m Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
yes 8 5 июля, 2019 Опубликовано 5 июля, 2019 · Жалоба 2 hours ago, _3m said: За протокол на основе таймаутов - пожизненный эцих с гвоздями !!! Перепиливать придется. При передаче по wifi задержки плавают: более 90% - 1ms, 95% - 10ms а 0,5% доходит до сотен ms. Я тестировал UDP echo на ESP32 в локальной сети. Потерь пакетов за день не было. С TCP примерно так же только минимальное время 1,5-2ms. там реализован АТ модем - есть два режима: данных и команд (+++ и все-такое - я с АТ модемом в прошлом тысячелетии имел дело в последний раз - детали не помню уже) в даташите 3 с (уж не знаю о них или о чем-то другом писал AlexandrY) встречается только в описаниях передачи блока данных в командном режиме. там текст китайский и копирование запрещено, поэтому небольшой кусок руками печатаю: The UART port will wait 3 seconds for input after this command is sent OK я этот китайский понял так, что после отправки этой команды (выдачи ОК) модем на 3 сек переходит в режим данных, и все что будет передано за это время (включая и АТ последовательности) будет передано -------------------- спасибо за задержки Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 243 5 июля, 2019 Опубликовано 5 июля, 2019 · Жалоба 19 минут назад, yes сказал: там реализован АТ модем - есть два режима: данных и команд (+++ и все-такое - я с АТ модемом в прошлом тысячелетии имел дело в последний раз - детали не помню уже) в даташите 3 с (уж не знаю о них или о чем-то другом писал AlexandrY) встречается только в описаниях передачи блока данных в командном режиме. Переходы "командный режим" <-> "режим данных" (и все эти +++...) - такое было в АТ-командах ещё dial-up модемов. Сейчас есть вполне пристойные реализации даже АТ-командного протокола без таких переключений и без пауз (без "прозрачного" режима). Например как сделано в ESP8266 и в SIMCOM-ских модемах. Там отправлять/принимать данные можно в командном режиме не переходя в режим данных. И тогда никакие паузы не нужны. И поэтому возможны многоканальные подключения. И есть возможность получать от модема внеполосные уведомления даже при открытом соединении. Эти же модули позволяют работать и по-старому в стиле "командный режим" <-> "режим данных" (прозрачный режим). Для совместимости. Но лучше так не делать. Вобщем: все эти паузы - издержки "прозрачного режима". Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mantech 53 5 июля, 2019 Опубликовано 5 июля, 2019 (изменено) · Жалоба 17 минут назад, jcxz сказал: Там отправлять/принимать данные можно в командном режиме не переходя в режим данных. И тогда никакие паузы не нужны. Так никаких пауз не нужно и в прозрачном режиме, для переключения в модеме есть линия DTR, никаких плюсов отправлять не надо. И вообще, зачем постоянно переключаться? Открыл канал и гонишь туда-сюда, отвалилось соединение, шлепнул DTR и вошел снова... Плюс прозрачного режима - можно напрямую гнать бинарник, а в вашем случае надо либо замены или в hex кодировать... 3 часа назад, _3m сказал: За протокол на основе таймаутов - пожизненный эцих с гвоздями !!! Эт точно! Таймаут в протоколе может быть только один - обработка отвалившегося соединения или потеря подтверждения передачи, все остальное должно быть с подтверждениями. Исключения - только специализированные радиомодемные протоколы с таймслотами.. Изменено 5 июля, 2019 пользователем mantech Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
