AlexandrY

Т.е. нам предлагают обсуждать то чего еще нет. Я смотрел ветку этого пацана в каком-то форуме где он искал подходящий WiFi модуль. Ему там навалили кучу бесполезной трухи. Он не умеет даже организовать поиск. Подозреваю что всю движуху ему сделали хабровцы поскольку распологают хорошей статистикой по целевой аудитории. Они били не на угад. Знать что есть любители мало, надо детализировать их потребности, ибо обещать все невозможно. О! Они уже ищут разработчиков на стороне - https://habr.com/ru/post/514326/ Почему-то бояться только китайцев, а их "главный" программист не знает даже об Azure RTOS.

Azure RTOS это ThreadX и они сертифицированы по какому-то очень жесткому стандарту. Но вот в Nucleus Plius тоже есть немеряно goto. И тож сертифицировано. Очевидно что вопрос применения goto не вопрос квалификации.

В моем последнем проекте я нашел 320 мест использующих goto. Интересно что в Azure RTOS нет ни одного goto. Там тупо и упорно на каждой ошибке оформляют отдельное восстановление состояния и возвращение памяти. Нет goto и в проекте uCOS-II А вот в платформе mbed я насчитал аж 1270 использований goto. Т.е. goto не вопрос веры или предпочтений, а скорее вопрос сертификации и корпоративной культуры. По своей воле никто от goto не отказывается.

Чет я не понял где на гитхабе этот проект? Дайте посмотреть

Скорее всего проблема в документированности оси и консистентности ее API. Скажем FreeRTOS отвратительно документирована. На ее применение разработчики убъют больше времени чем на ту же Azure RTOS О мультипроцессорности во FreeRTOS можно узнать только из каких-то отрывочных блогов. Консистентность API в плане мультиядерности вызывает большие вопросы. Понятно что уважаемый TC бъется о FreeRTOS как рыба об лед . С другой стороны кто сказал что на UART нужна одна задача? Хорошая практика на каждый коммуникационный интерфейс иметь две задачи: на RX и на TX. На TCP может и 4-х задач нехватить. Мигалка тоже требует свою задачу помимо основной. Красивые RGB мигалки с переливами требуют двух задач. Кооперативность имеет место в бизнеслогике основной задачи. Она автоматически реализуется если вы используете среду разработки с поддержкой нотации иерархических диаграмм состояний. Но для беспроблемной реализации диаграм состояний опять же нет ничего лучше вытесняющей RTOS. Словом даже если вам кажется всего одна задача все равно используйте RTOS.

Я может быть и поключился бы к проекту, но просто нет совершенно времени. Такие контакты сильно отвлекают. Спасибо что вы им сообщили об ошибке, значит сообщество таки растет. Мне к описанию ошибки добавить сильно нечего. Да, просто забыли освободить пакет. Возможно из-за того что в Azure RTOS принято пакет освобождать после передачи далее на более высоком уровне. Но именно при подключении в клиенте FTP этого высокого уровня нет, он не предусмотрен.

HiveMQ еще не умеет ничего делать с SQL базами. Это написано на его странице фичей - https://www.hivemq.com/hivemq/features/ Как понимаю, вы пытаетесь советовать то о чем сами слышали краем уха. Далее, между брокером и базой работать должен не "бридж", а нормальный бэкэнд с бизнеслогикой. Либо где по вашему должна располагаться бизнеслогика?

Тут честно ничего нового вы уже не скажете. У проектов есть middleware и оно вам требуется серьезное. Оно всегда сложнее и труднее в реализации чем весь уровень приложения. Что бы ваш дивайс ни делал самая трудная его часть абсолютно ясна. Но проблема в том что платформу вы выбрали скверную с бедными средствами отладки. На такой платформе разработка обходится дороже.

То что у TC нет денег ясно с самого начала было. RTOS здесь обязательна, а вот два ядра нафиг не нужны. Вот график достигнутых минимальных скоростей в Azure RTOS на некоей SD карте. По оси Х отложены номера итераций, по оси Y минимальная скорость на каждой итерации. Каждая итерация представляет собой запись файла в 1 Гбайт. Скрость измерялась после передачи каждых 4-х килобайт. Как видно можно добиться гарантированной скорости в 60 Кбайт в сек. НО чтобы портировать это на ESP 32 требуется серьезный бюджет.

Модульность хороша только для коллективной разработки. Каждый выбрал себе максимально изолированный модуль и счастлив. Потом они весело переругиваются друг с другом чей модуль косячит. Для вас же модульность - смерть проекта. Ваше решение должно быть максимально интегрированным и консолидированным. Таких реально на пальцах можно пересчитать. Одно из них - среда RAD Studio. В ней и базу данных любую развернете, и клиента MQTT и тестовый генератор трафика, и любые виды графиков. https://habr.com/ru/post/388343/

Думаю TC просто еще не назвал все сопутствующие обстоятельства. Пока вангую - он видит спорадические задержки от десятков до сотен милисекунд и чем дальше тем больше.

В принципе можно за 3 мс записать, но труда будет стоить. Боюсь у ТС столько денег не будет.

Ок, + температуру воды.

+GPS, +инерциалка в самой лодке, +карта реки.

Это, конечно, неправда. Я находился в доме с закрытыми окнами при жаре в 30 град на улице. Температура в доме была около 21-22 град. Эт тоже неверно. Регулировать частоту вращения асинхронного двигателя тиристором довольно просто.