Вопрос Что стабильнее: ESP8266 или 32?

[Cu6apum]

Завязан C++ и RTOS. А что там к ним подцепили - неизвестно.
Это надо перелопачивать всё, включая все либы в ESP/IDF.
Lwip имеет свой конфиг, где можно указать статика/динамика но как оно слеплено в ESP/IDF - неизвестно.

Ну до тех пор, пока это открытый кусок, непреодолимостей не видно. В любом сдк используемая в проекте часть плотно шерстится и часто переделывается наново, не впервой. Для avr8, считай, всё с нуля свое.

Прокурю, освоюсь, доложу. Софтовые баги обычно вылезают быстро. Вот железных опасаюсь параноидально.

 

[pvvx]

Заказаны сомики с 2 метрами psram. Могу ли я сразу релоцировать туда код, чтоб не жевать флешку, и разместить там же статически наиболее медленные буферы?

А фигу - в ESP/IDF всё на malloc(). Сделал поиск "malloc" - и даже драйверы:
[Espressif\esp-idf\components\driver\]
i2c.c
i2s.c
ledc.c
pcnt.c
rmt.c
rtc_module.c
sdio_slave.c
sdspi_host.c
sigmadelta.c
spi_master.c
spi_slave.c
timer.c
uart.c

Зы. На allwinner v3s тоже макетки заказал, хотя очень сильно сомневаюсь насчет времени загрузки линупса за секунду или меньше.

Это смотря какой "линупс" и какая плата - с какой памятью. Есть варианты, которые грузится и за менее 1 сек.
Учитывать загрузку стоит если устройство жрет не по карману. А если оно после старта в пару секунд пьет 80 мА, а затем 1 мА, то такое уже годится для стабильной и долгой работы от АКБ.

 

[pvvx]

Софтовые баги обычно вылезают быстро. Вот железных опасаюсь параноидально.

Ну там спустя годы не вставили даже delay() в инициализацию дров. От этого нехилый пик тока за 500 мА и в USB вырубает защитный тепловой(!) предохранитель. ESP/IDF пишется Ардуинщиком и имеет расчет на выполнение одной малой задачи. По этому сразу не падает, т.к. одна задача углубляясь в исполнение поэтапно занимает память в malloc(), а напечатав "Hello World!", обратно освобождает всё занятое в malloc().
Но если задачи идут динамически и открываются/закрываются всякие дрова, то оно потом падает или страдает утечками памяти. В гит куча запросов по этим нерешенным проблемам... Помогите им исправить

 

[Cu6apum]

всё на malloc()

Разок-то в жизни можно, главное, не хлопать туда-сюда, вороша кучу. Посмотрим.

работы от АКБ.

Не мой кейз. Пущай лопает. Мне нужно только держать ULP ядро включенным от часовой батарейки на время падения питания и корректно возвращаться взад. Поэтому заказал сразу кремний V3, где вроде бы побеждена бага с BOR.
Однако не фатально расстроюсь и без ULP, микруха экономичного счетчика импульсов - пятачок пучок, в конце концов.

 

[pvvx]

Для меня ESP закрыт по многим направлениям применения, т.к. не имеет PMU и/или драйвера PMU в RTOS.

Обычно в таком драйвере задаются callback по входу и выходу в/из sleep для каждого устройства и общее ядро драйвера имеет биты включения/выключения устройств в release/wakelock т.д.

Даже древний монстр с 2 МБ динамической памяти в виде RTL8195 и то потребляет 1 мА при постоянном соединении с AP, только за счет нормального PMU и драйвера к нему.

Ну и для ESP8266 они спрятали часть управления sleep режимами, а в ESP32 пока ничего по поводу аппаратных возможностей sleep не встречал.

Тест ESP32-C3 показывает, что время страта-загрузки до первого исполняемого кода пользователя (хоть в boot) после deep-sleep или reset ужасен и не может быть сокращен на менее чем у ESP8266. А о других sleep – тишина, т.к. имеющиеся характеристики не годятся для рекламы. Имеются только одни вопросы пользователей о кучи багов в имеющихся реализациях некой процедуры sleep...

 

[pvvx]

Не мой кейз. Пущай лопает.

У вас есть смартфон? Если вы включите в нем WiFi - сколько он жрет? Обычно там аналогичный или даже превосходящий по возможностям чип.
Если как ESP - то сколько оно проживет?

 

[Cu6apum]

Ну нет все же необходимости сравнивать устарелый китайский бутерброд и чипсет A15 от Яббл. Задачи разные.
Мне-то он нужен в роли ардуинки с ethernetом: опросить АЦП, плюнуть результат в modbus/mqtt, потом релейкой щелкнуть и снова спать. При этом съест он милливатт или ватт, особой разницы нету. Главное - убойная надежность, спокойные поставки, скромная цена (евроамериканцы СИЛЬНО нескромны стали), отсутствие значительных расходов на обвязку. Ну, понятно, расходов на разработку тоже. При этом вайфайка - приятный бесплатный бонус для iot.

Лидер по отсутствию расходов на разработку это, конечно, allwinner. Десяток строк на сях под openwrt или baremetal на yocto - и можно продавать. Только оттюнить время загрузки до готовности. Даже phy на борту!
Хотя - старая инженерная школа, конечно, стучит в грудь пеплом Клааса: не офигел ли я строить авианосец чтоб возить кота через речку…

 

[pvvx]

Мне-то он нужен в роли ардуинки с ethernetом: опросить АЦП, плюнуть результат в modbus/mqtt, потом релейкой щелкнуть и снова спать.

Когда сделаете Modbus RTU - не забудьте выслать для проверки на соответствие спецификации Modbus по символьным задержкам в 1.5 и 3.5 символа
И не забудьте, что при передаче от мастера всем устройствам (на номер 0) пачки фреймов должны уложиться с паузами в 1.75 ms между сообщениями уже за 38400 и обработаться всеми устройствами...
При этом ваш сервер mqtt должОн кушать более тысячи публикаций в сек от тупенького приемника modbus rtu, работающего на скорости 115200

 

[Cu6apum]

Спасибо, тестирование будет жесткое. Причем за сервер (брокер) я беспокоюсь чуть меньше, там 4-котловый soc с полгигом оперативы, а как вот именно тощий клиент себя поведет в условиях флада mqtt (включая оверсайз телеграммы), надо смотреть.

 

[pvvx]

Причем за сервер (брокер) я беспокоюсь чуть меньше, там 4-котловый soc с полгигом оперативы, а как вот именно тощий клиент себя поведет в условиях флада mqtt (включая оверсайз телеграммы), надо смотреть.

Это зря - MQTT слишком тормозной и без спец. ухищрений не тянет и десятка публикаций в сек. Т.е. медленнее чем Modbus RTU на 9600. Дожили...
А Modbus TCP на одном ядре в 200MHz - 10 тысяч транзакций в сек.

 

[pvvx]

@Cu6apum Если связываетесь с Linux, то вам придется ознакомится, что такое переключение контекста в современных OS. И как это влияет на время выполнения большинства задач. С времен первых i-386 это время не изменилось, а они не могли принимать UART более 19200, пока в UART не ввели FIFO. Тупо не успевают переключаться на уровень ядра драйвера из пользовательской задачи.
Причина этому - так ныне пишут soft.
MQTT

Google Cloud Blog | News, Features and Announcements

Official news, features and announcements for all Google Cloud products including Google Cloud Platform, Workspace, and much more.

cloud.google.com

250 ms на транзакцию. Или 4 публикации в сек

Наиболее приближенный самый простой тест скорости системы - сколько процедур fork() и vfork() она может выполнить в сек.

 

[pvvx]

А если хотите удариться в философию, то в нашем мире существуют физические ограничения – никакое неспециализированное ИИ или ещё кто не может быть быстрее мозга человека в 1.5 раза.

Только узкоспециализированные комплексы, заточенные на одну задачу. И ПО писанное на системе для решения общих задач всегда будет тупить и никогда не сравнится с узкоспециализированным комплексом.

И чтобы достичь паритета скорости MQTT на паре ядер с Modbus TCP на тупом MCU вам придется переписать всё, включая уровни ядра

 

[Cu6apum]

MQTT слишком тормозной

На текущем брокере (одноядерный ARMv7 на 900МГц с гигом памяти) сейчас идет где-то 250-500 телеграмм в секунду. Это в штатном, расслабленном режиме, без стресс-тестов. А планируется для головного контроллера четырехствольный проц на 1.2ГГц, уже сидит коллега на трассировке платы.
Сколько удастся пропихнуть через сетевой МК - узнаем на днях, макетка уже упала в страну. Начну с дефолтного кода из сдк.

Причина этому - так ныне пишут soft.

Ну. Вы еще вспомните, как нынче кино снимают.
Под линь я сейчас пишу больше, чем под МК и, по опыту, не вижу препятствий обслужить на головном ПЛК 4-8 портов rs485 по 32 устройства на 115200bps, с фиксированным временем опроса, и еще не менее чем столько же устройств по modbus/tcp, но уже с буферизацией. Трафик весьма и весьма далек от кошмарного: сравните хоть с видеозахватом.

Если esp не сможет одновременно отдавать значения по modbus/tcp и в mqtt-топик хотя бы раз в 20мс, то сразу выпадет из кандидатур на сетевую периферию, штош, буду делать на ней только тупые устройства для rtu. Allwinnerская макетка тоже уже в пути.

 

[pvvx]

Под линь я сейчас пишу больше, чем под МК и, по опыту, не вижу препятствий обслужить на головном ПЛК 4-8 портов rs485 по 32 устройства на 115200bps, с фиксированным временем опроса, и еще не менее чем столько же устройств по modbus/tcp, но уже с буферизацией. Трафик весьма и весьма далек от кошмарного: сравните хоть с видеозахватом.

Вам дали подсказку - FIFO. Без неё никаких 115200. А это значит, что вы не вписались в стандарт Modbus RTU и не отслеживаете межсимвольную паузу в 1.5 символа. Т.е. у вас бракованная система и не годится для пром. применения.
Тот-же г"ОВЕН" в тупой переходник USB-ModbusRTU-485 вешает микруху MCU отслеживающую паузы и ещё что-то... Только толку мало - всё равно оно не вписывается в стандарт уже RS-485 по уровням и токам

 

[Cu6apum]

Чо-т Вы не то прочли, сэээр.
На любом соме есть по железному фифо на уарт. Даже если не заводить поверх них еще софтовые, для специательных случаев.

Да и про мкутт инфа …гм, левовата. Загуглил неспешно бенчмарки популярных брокеров - mosquitto например (без учета ограничений железа) тянет ~240000 телеграмм в секунду. Т.е. мои текущие 500 это чих комариный.

 

[pvvx]

Чо-т Вы не то прочли, сэээр.
На любом соме есть по железному фифо на уарт. Даже если не заводить поверх них еще софтовые, для специательных случаев.

Т.е. вы никогда не связывались с modbus rtu и от этого непонимание, что FIFO не имеет указателя на байт, на котором произошел таймаут. Т.е. FIFO UART должно иметь IRQ c выставляемой паузой в символьных битах тишины вызывающее прерывание и вы должны успеть считать всю FIFO до появления в ней нового символа, что не обеспечивает никакой Linux (он не real-time)
И где вы возьмете такую модель API UART, в которой возможно указать кол-во бит символов межсимвольной тишины или время в мкс межсимвольной тишины?

Да и про мкутт инфа …гм, левовата. Загуглил неспешно бенчмарки популярных брокеров - mosquitto например (без учета ограничений железа) тянет ~240000 телеграмм в секунду. Т.е. мои текущие 500 это чих комариный.

Вы у себя проверьте, а потом уже гуглите

 

[Cu6apum]

Т.е. вы никогда не связывались с modbus rtu

Делал затычку на атмеге128, проблем не наблюл, потому и не пойму, о чем Вы. Протокол простой как дверь.

Вы у себя проверьте

Сделал 20000 телеграмм в секунду. Попискивает, но задержку не увеличил. Норм.

 

[pvvx]

Делал затычку на атмеге128, проблем не наблюл, потому и не пойму, о чем Вы. Протокол простой как дверь.

Дык "затычку" или протокол?
90% встретившихся местных устройств не могут работать по протоколу (по спецификации). Приходится вставлять дополнительные опции в меню для задержек и издержек их реализаций.
У вас видимо такое и вышло - "затычка" требующая специальных задержек и не распознающая разрывы в 1.5 символа и не понимающая что это помеха между сообщениями, т.к. не имеет даже 2-х таймеров для нескольких переключений шины и поддержки протокола?
Ей что шум на линии, что сообщения?

Сделал 20000 телеграмм в секунду. Попискивает, но задержку не увеличил. Норм.

Mosquitto is single threaded:

Mosquitto/Multi-Thread - Eclipsepedia

wiki.eclipse.org

При 20000 средний ответ на запрос превышает длительность среднего фрейма Modsbus на 19200 (без учета задержки сети)
А если это очередная "затычка" на Arduino с ESP - то открытие и закрытие соединения на каждую публикацию превышает всё и сразу.

 

[pvvx]

Потом и выходят такие IoT лампочки через сервер - нажал кнопку и жди, т.к. сообщение MQTT застряло в очереди и движется где-то между рукавами серваков доя ближайшего однопоточного Mosquitto загрузившего на 3.125% Atlon c 16 ядрами (больше не может - поток один).

 

[Cu6apum]

Всё, я, кажется, врубился в Ваши опасения.
Расскажу, как только сделаю.
Добиваться синхронности от mqtt - идея изначально гиблая, такой задачи я и не ставил, но обеспечить приемлемую реакцию и документировать конкретные ее значения - будет сделано.