Использует char*-строки и функции <string.h> вместо std::string и std::string_view. (единственное исключение - строковые константы через constexpr).
А это хорошо или плохо? String упрощает взаимодействие со строками, но char* и char str[] дает возможность строго определить занимаемое место. Работаю в основном с программированием микроконтроллеров, и неопределенность, которую вносит string, недопустима, и его стараюсь избегать, используя там, где действительно нужно.
Например, при определении структуры, которая будет передаваться и использоваться в очередях FreeRTOS, string уже не прокатит: недетерминированное поведение строки при передаче через очередь
Это пригодилось бы больше для Embedded Linux, но тогда нужны программные интерфейсы, чтобы можно было этим эквалайзером управлять, причем без перезапуска ALSA
Помню, пользовался Lua в свое время, даже 2 проекта работали на нем. Прекрасная вещь, в какой-то степени даже заменяла RTOS на ESP8266. Но от нее пришлось отказаться по трем причинам:
Нет четкого разделения кода и данных. Приходилось настройки писать в файл, который лежит вместе с файлами кода
Утечки памяти, особенно во время работы веб-сервера, когда открыта страничка с периодическим опросом
Плюсом идет снижение порога вхождения в айти: если лет 10-15 назад приходилось изучать атомарное взаимодействие с компонентами программы/страницы/железки/прочего, потому что иного выхода не было, то теперь большинство из этого взяли на себя фреймворки. Ну, и мнимая открытость некоторых платформ, на которых можно поучиться и даже создавать мелкосерийные устройства, но серьезное что-либо с таким набором знаний не создать, или проблем не оберешься: зачастую, открытые только интерфейсы взаимодействия, при этом принцип работы покрыт мраком, и непонятно, какие там баги, и будет ли производитель чипов гарантировать полное отсутствие багов, большой вопрос.
С одной стороны да — открытое железо — открытая прошивка. Однако на ней уже нельзя хранить чувствительные данные, такие как ключи, токены, пароли, да и в даташите говорится, что он не предназначен для таких применений как медицинских, automotive систем, а также систем, чувствительных к компрометации.
Помимо ревизии BootROM потребуется хранилище фьюзов или optionbytes.
В случае с ESP32 ситуация получше, там есть функционал защиты данных, но им можно воспользоваться только с фреймворком esp-idf. Если можно защитить прошивку и с фреймворком Arduino, дайте знать. Опции защиты указываются при сборке проекта.
Интересно, а как обстоят дела с защитой прошивки/данных? Ну, типа, шифрование флешки, secure boot. Похоже на решение для хобби, внутреннего использования в компаниях, домашней автоматизации, но не для коммерции.
С одной стороны. С другой стороны — заказчик не нашел готовых решений, которые покрыли бы его хотелкипотребности, но нашел человека, который сделает такой источник
А есть возможность подключать реле/ключ, чтобы при включении размыкал цепь разряда конденсаторов, чтобы PFC работал, а при отключении реле замыкалось, и подключался резистор?
> не понятно пока как перебросить web интерфейс, чтоб делать обновление по воздуху.
Куда пробрасывать интерфейс? Если ты хочешь делать обновление по воздуху вручную через веб-морду, то лучше поднять веб-морду на стороне esp32 и форму отправки прошивки.
Если хочешь, чтобы МК сам забирал прошивку по OTA, то реализуй свой сервер внешний и в прошивке делай периодическую проверку. По какому протоколу обновлять автоматически/вручную — это уже на твой выбор;)
Если же ты хочешь пробросить веб-морду вовне, чтобы можно было обновлять из любой точки мира, то это делается на стороне роутера, а домой к каждому ты не зайдешь;)
Что касается Vref, то тебе необязательно его знать, в esp-idf есть функция, которая просто выдаст тебе напряжение на входе, и если ты меришь через делитель, учти его коэффициент
Мне все же понравилась идея с солнечной батареей, как упоминали в комментариях, и дисплей либо e-ink, либо ЖК, как в калькуляторах, а дисплеи можно взять из них же
Любимый момент:
А это хорошо или плохо? String упрощает взаимодействие со строками, но char* и char str[] дает возможность строго определить занимаемое место. Работаю в основном с программированием микроконтроллеров, и неопределенность, которую вносит string, недопустима, и его стараюсь избегать, используя там, где действительно нужно.
Например, при определении структуры, которая будет передаваться и использоваться в очередях FreeRTOS, string уже не прокатит: недетерминированное поведение строки при передаче через очередь
Это пригодилось бы больше для Embedded Linux, но тогда нужны программные интерфейсы, чтобы можно было этим эквалайзером управлять, причем без перезапуска ALSA
Помню, пользовался Lua в свое время, даже 2 проекта работали на нем. Прекрасная вещь, в какой-то степени даже заменяла RTOS на ESP8266. Но от нее пришлось отказаться по трем причинам:
Нет четкого разделения кода и данных. Приходилось настройки писать в файл, который лежит вместе с файлами кода
Утечки памяти, особенно во время работы веб-сервера, когда открыта страничка с периодическим опросом
Проект Lua слабо развивается
Плюсом идет снижение порога вхождения в айти: если лет 10-15 назад приходилось изучать атомарное взаимодействие с компонентами программы/страницы/железки/прочего, потому что иного выхода не было, то теперь большинство из этого взяли на себя фреймворки. Ну, и мнимая открытость некоторых платформ, на которых можно поучиться и даже создавать мелкосерийные устройства, но серьезное что-либо с таким набором знаний не создать, или проблем не оберешься: зачастую, открытые только интерфейсы взаимодействия, при этом принцип работы покрыт мраком, и непонятно, какие там баги, и будет ли производитель чипов гарантировать полное отсутствие багов, большой вопрос.
Вообще-то, Келли ее в экселе не писала, она ее туда приняла
Вопрос такого характера: планируется ли использование драйвера libusb вместо WinUSB для обеспечения совместимости с Linux и Android, например?
Помимо ревизии BootROM потребуется хранилище фьюзов или optionbytes.
В случае с ESP32 ситуация получше, там есть функционал защиты данных, но им можно воспользоваться только с фреймворком esp-idf. Если можно защитить прошивку и с фреймворком Arduino, дайте знать. Опции защиты указываются при сборке проекта.
Интересно, а как обстоят дела с защитой прошивки/данных? Ну, типа, шифрование флешки, secure boot. Похоже на решение для хобби, внутреннего использования в компаниях, домашней автоматизации, но не для коммерции.
А что с ним не так?
хотелкипотребности, но нашел человека, который сделает такой источникКуда пробрасывать интерфейс? Если ты хочешь делать обновление по воздуху вручную через веб-морду, то лучше поднять веб-морду на стороне esp32 и форму отправки прошивки.
Если хочешь, чтобы МК сам забирал прошивку по OTA, то реализуй свой сервер внешний и в прошивке делай периодическую проверку. По какому протоколу обновлять автоматически/вручную — это уже на твой выбор;)
Если же ты хочешь пробросить веб-морду вовне, чтобы можно было обновлять из любой точки мира, то это делается на стороне роутера, а домой к каждому ты не зайдешь;)
Если можно исходники, то сбрось и бинарники, и исходники. Ну, ссылку на облако, где это все лежит
Был бы очень признателен за пак прошивок, а то телек у меня валяется на этом чипе без дела
Что касается Vref, то тебе необязательно его знать, в esp-idf есть функция, которая просто выдаст тебе напряжение на входе, и если ты меришь через делитель, учти его коэффициент
Есть eFuse у ESP32, где программируются ключи шифрования и параметры, типа опорное напряжение, разрешение отладочного вывода и другие
Мне все же понравилась идея с солнечной батареей, как упоминали в комментариях, и дисплей либо e-ink, либо ЖК, как в калькуляторах, а дисплеи можно взять из них же