Мой первый KitRover: попытка сделать машинку с управлением по сети (часть 2)

[Coder007]

В ходе предыдущих попыток, сжег два Pico и решил перейти на что-то подешевле

Расскажи, как? Как можно сжечь микроконтроллер такой банальщиной?

Проект для запуска на одноплатнике, в задачи которого входит отправка AT-команд

Т.е. вместо нормальной кодировки одним байтом нескольких команд, ты перешёл на AT команды с тупым парсингом? Бред! И ты на этом хочешь сделать управление по сети?

Так как в планах иметь возможность подключать LiDAR к проекту, у меня есть подозрения, что для такой сборки лучше иметь два аппаратных UART. Те LiDAR'ы, которые я видел, отдают данные на скорости 230400, а у меня основная работа идет на скорости 115200. Есть ощущение, что, работая по одному каналу, придется либо иметь небольшой лаг в данных с LiDAR, либо будут проблемы с ответами от основных команд.

С таким подходом ты лидар увидишь после того, как твоя машинка прилетит в стену.

Ощущение такое, что автор прикладной начинающий программист и пока ещё не понимает принципов обмена информацией на уровне микроконтроллеров и датчиков.

Для динамично системы нужно использовать не меньше чем SPI (желательно самый быстрый), а не UART.

Вычитав в сети о том, что UDP не имеет встроенных механизмов защиты, а заниматься реализацией по этой теме мне показалось не лучшей идеей для MVP проекта, было решено искать другой вариант коммуникации. В качестве способа решил использовать gRPC, где Backend работает с Unary процедурами, а Proxy со Stream.

Нет слов...

Вы вообще что делаете? Машинку с дистанционным управлением по сети или клиент-северное приложение? Хоть немного понимаете или пытаетесь понимать о том, что такое скорость передачи данных, отклик устройства и реакция?

Если собрать всю картину воедино, получается катастрофическая цепочка:

1. Видеопоток и команды пакуются в тяжелый gRPC (TCP).

2. Прокси-сервер разрывает поток на Unary-запросы и пинает Бэкенд.

3. Команды управления превращаются в длинные текстовые AT-строки.

4. Эти строки летят на слабый чип RP2040.

5. Программа на Go судорожно пытается распарсить тонны текста, постоянно спотыкаясь о сборщик мусора.

Предполагаемый итог: Это не MVP, это технический мазохизм. Проект соберет комбо из всех возможных видов задержек: сетевых (из-за TCP), серверных (из-за прокси) и вычислительных (из-за парсинга текста в Go на слабом чипе). Машинка будет реагировать на пульт с грацией и скоростью лунохода.

Для RP2040 стандарт — это C/C++