Comments 3
В ходе предыдущих попыток, сжег два Pico и решил перейти на что-то подешевле
Расскажи, как? Как можно сжечь микроконтроллер такой банальщиной?
Проект для запуска на одноплатнике, в задачи которого входит отправка AT-команд
Т.е. вместо нормальной кодировки одним байтом нескольких команд, ты перешёл на AT команды с тупым парсингом? Бред! И ты на этом хочешь сделать управление по сети?
Так как в планах иметь возможность подключать LiDAR к проекту, у меня есть подозрения, что для такой сборки лучше иметь два аппаратных UART. Те LiDAR'ы, которые я видел, отдают данные на скорости 230400, а у меня основная работа идет на скорости 115200. Есть ощущение, что, работая по одному каналу, придется либо иметь небольшой лаг в данных с LiDAR, либо будут проблемы с ответами от основных команд.
С таким подходом ты лидар увидишь после того, как твоя машинка прилетит в стену.
Ощущение такое, что автор прикладной начинающий программист и пока ещё не понимает принципов обмена информацией на уровне микроконтроллеров и датчиков.
Для динамично системы нужно использовать не меньше чем SPI (желательно самый быстрый), а не UART.
Вычитав в сети о том, что UDP не имеет встроенных механизмов защиты, а заниматься реализацией по этой теме мне показалось не лучшей идеей для MVP проекта, было решено искать другой вариант коммуникации. В качестве способа решил использовать gRPC, где Backend работает с Unary процедурами, а Proxy со Stream.
Нет слов...
Вы вообще что делаете? Машинку с дистанционным управлением по сети или клиент-северное приложение? Хоть немного понимаете или пытаетесь понимать о том, что такое скорость передачи данных, отклик устройства и реакция?
Если собрать всю картину воедино, получается катастрофическая цепочка:
Видеопоток и команды пакуются в тяжелый gRPC (TCP).
Прокси-сервер разрывает поток на Unary-запросы и пинает Бэкенд.
Команды управления превращаются в длинные текстовые AT-строки.
Эти строки летят на слабый чип RP2040.
Программа на Go судорожно пытается распарсить тонны текста, постоянно спотыкаясь о сборщик мусора.
Предполагаемый итог: Это не MVP, это технический мазохизм. Проект соберет комбо из всех возможных видов задержек: сетевых (из-за TCP), серверных (из-за прокси) и вычислительных (из-за парсинга текста в Go на слабом чипе). Машинка будет реагировать на пульт с грацией и скоростью лунохода.
Для RP2040 стандарт — это C/C++
Если собрать всю картину воедино, получается катастрофическая цепочка:
Видеопоток и команды пакуются в тяжелый gRPC (TCP).
Прокси-сервер разрывает поток на Unary-запросы и пинает Бэкенд.
Команды управления превращаются в длинные текстовые AT-строки.
Эти строки летят на слабый чип RP2040.
Программа на Go судорожно пытается распарсить тонны текста, постоянно спотыкаясь о сборщик мусора.
Видео поток не взаимодействует с моими сервисами которые используют gRPC;
Не совсем понял почему такой итог. Backend и Proxy работают отдельно. Backend по Unary отдает JWT, а Proxy переотправляет команды по Stream;
Тут всё верно. Для удобства разработки решил использовать то, что удобно на этом этапе. Дальшейшие переделки и сравнения это поводы для статей. Цели сделать сразу хорошо и уложиться в одну статью нет. В будущих итерациях планируется улучшать. Сейчас задача сделать то, что катается по комнатам.
Ответ пересекается с пт.3
Будет интересно рассмотреть работу c Go от
-gc=conservativeчерез-gc=leakingк-gc=none.
Машинка будет реагировать на пульт с грацией и скоростью лунохода.
Сейчас машинка вполне неплохо едет для технического мазохизма.
Вы правы насчет "автор прикладной начинающий программист", это мой первый проект с микроконтроллерами, выходящий за рамки Blink. Цели браться за C/C++ у меня нет, даже если это стандарт.
Спасибо за конструктивную критику.
Цели браться за C/C++ у меня нет, даже если это стандарт
Понимаю вас, потому как сам программист, это сложно, но если хотите делать взаимодействие между низкоуровневым железом, то стоит именно изучать и C и C++, потому что это то самое, которое позволяет организовать работу, а не имитацию работы. На остальных ЯП вы сможете сделать что-то подобное, но вам нужны будут аппаратным возможности железа преаышающие базовые требования, иными словами, что бы сделать простой вывод данных вам нужен будет микроконтроллер вмещающий как минимум все библиотеки GO или трпнслятоо Python, а это уже не меньше ESP32-S3, А если делать систему реального времени вам нужен будет RP или что-то серьёзнее.
Вот и начинается избыточность, удорожание, но программистам зато удобно, писать легко и быстро.
Самое печальное, что здесь должна падать стоимость программного кода ввиду того, что это стало быстро и просто, но этого не происходит, потому что программисты верхнего уровня считают что они вкладывают много сил и их код не может стоить дёшево. А потом и код раздувается и требования к железу растут, а итог не меняется, только цена лезет вверх.
На днях наткнулся на статью про датчик температуры, влажности и качества воздуха, которому оптимизировали память, из за сборщика мусора, потому что было переполнение, а объем памяти там был 128 Килобайт. У меня аж челюсть отвисла, когда я прочитал, как и куда там используется память. Это как раз один из примеров, когда используется мощное железо и прикладное ПО. Датчик получается измеряет банальные вещи, по минимальным объемам, а его задействовали как полноценный процессор и пытаются на высокоуровневом языке получить и передать 10 байт банальной информации. Итог - для датчика, стоимостью 2 доллара применяется архитектура за 30 долларов, высокоуровневое ПО, загрузка ядра и памяти на 100%. Чего не должно происходить в принципе, для простых систем.
Получается, что вы используете микроскоп что бы им заколачивать гвозди. Дорого, но эффект есть....
Если это разделить, то нет проблем, но когда прикладные программисты начинают лезть на системный уровень со своим языком (а это сейчас вполне возможно), то чаще всего происходит именно такой диссонанс.
Разделяйте системное и прикладное!
Управление, датчики, автономный системы - это системный уровень, почитайте теорию автоматического управления, протоколы, сигналы, изучите электронику и прочее.
Камера для контроля - это уже прикладной уровень, там творите что хотите, но учтите что от железа, протоколов, сигналов, зависит как быстро получите картинку.
Ну и из этого уже можно сделать симбиоз, качественный и корректный.
Удачи в проектах и не стесняйтесь изучать новое, хоть это и сильно старое...
Мой первый KitRover: попытка сделать машинку с управлением по сети (часть 2)