Ха... чип дип не перестает удивлять, отдельно AD620 стоит 2600р

с другой стороны, если там написано AD620 - это еще не значит, что настоящий

Ну я заказал, приедет, подробно с осликом изучу.

На киви курс, к слову 83р.

Ну я заказал, приедет, подробно с осликом изучу.

у меня есть платы с разбора медтехники, там настоящие AD620 и еще много чего

Ну я заказал, приедет, подробно с осликом изучу.

Растворить и глянуть что на кристалле написано. Их куда реже подделывают

Так вот и спрашиваю мнения гуру

platformio - лишняя необходимость возиться с JSON, хватает только idf + vscode / clion

родного С++ АПИ не хватает

приходится чет свое наколхожевать =\

вот эт печально

IDF

Хз, всего? Если хочешь писать на ++ приходиться обертки писать.

Над IDF

Не хватает родного апи на С++

Потому что родное апи на С

а на С++ его нет

поэтому его не хватает

Я кстати хз, там ВРОДЕ бы в std внедрили частично FreeRTOS

но я не пробовал не щупал

Если его нет это не значит что это хорошо.

термин апи настолько широкий что это не возможно.

Не надо путать API и ABI

Чем апи еспшного шарпа не является апи?

Вот у меня такой же вопрос.

Вы перевели разговор, что фреймворк != апи. Что для пользователя имеет не особо много смысла. Т.к. фреймворк по умолчанию диктует архитектуру работы, а значит и подменяет АПИ на свое.

То что можно залезть в кишки и дернуть за асм какой мы опустим.

Да сорт той же ардуины какой? Чем она не пример. Тот же самый фреймворк на С++ считай.

Ну ожидаемо =)

Которое представляет свой плюсовый АПИ, верно же.

В плане вы сейчас что пытаетесь, академический спор решить, что является фреймворком и его апи для есп?

Мне вот интересно: а что люди на C++ такого пишут на тех же ESP32/8266?

Та же Tasmota на чем написана?

хотя там смесь всего, что есть с корее всего)

На арм так то и в поменьше плюсы тащат вполне успешно.

Как пример того, что в младших АРМ флешки сильно меньше

понять бы - где начинается необходимость делать embedded проект на C++ вместо C

Примерно с того места где начинается необходимость языков высокго уровня? Тоесть вот с самого начала.

Это же всегда вопрос баланса.

Типо ну нужно тебе где-то проверочивать реалтайм - ну напиши ты там хоть на асме. Нахрена остальную часть кода писать на нем?

Вопрос оверхеда это вопрос уложения(привет русяз) в требования.

Примерно с того места где начинается необходимость языков высокго уровня? Тоесть вот с самого начала.

Угу. У меня был проект связанных по радиоканалу устройств в котором около 9 прошивок. Вот тут классно сделать виртуальную систему на C++, потому что к слою HAL с момента его написания несколько лет назад больше не возвращался.

Но еспл это уже 2ядр 240МГц проц с 320кб ОЗУ для щелканья реле

лол

@setpoint_f прикинь, запускаешь .exe и наблюдаешь как твоя реальная система в виде кучи разложенных по офису устройств работает в одном "окошке" с логами, брекпоинтами, кайф же!

Понимаете проблему? Когда люди берут пик12 для щелканья реле по радиоканалу И ТУДА ПИХАЮТ С++ это не адекват

А потом переносишь в прошивку те же C++ классы

Когда берут есп32 и для щелканья реле берут АСМ это тоже неадекват =)

я понимаю, сам по этим граблям ходил и бошка пухла от отладки этого добра!

С++ позволяют писать на статическом выделении, без наследования. Там оверхеда почти нет.

Не говоря уже что STL можно не использовать. А использовать ETL какую, заточенную под МК.

@setpoint_f я вообще за то, чтобы разделять embedder'ов и проггеров высокого уровня в тех же проектах, связанных с железом. Чтобы эмбедеры именно железо отлаживали, интерфейсы, схему и HAL. При этом high-level-щики сидели на удаленке, с котами, пивом и чем еще угодно, создавая абстрактный и покрытый тестами код

встречал проект, полностью заполненный конечными автоматами, макросами, структурами, указателями на указатели и с 0 unit тестов!

который делал именно эмбеддер, которому нравится с железом заниматься

А нужно же везде - на высоком уровне делать бизнес-логику))

Которая собственно и содержит основное кол-во багов и глюков 😁

который делал именно эмбеддер, которому нравится с железом заниматься

Меее. Я ща кукарекну не по масти. Но это не проблема того, что эмбеддер не может писать нормальный код, это проблема того, что эмбеддед переполнена микрооптимизациями ненужными. Короче не потому, что люди работающие с железом не могут писать нормально, а потому что не пишут.

@setpoint_f не соглашусь, это уже пройденный этап, а вот архитектуру строить и тестировать свой код - этого в эмбеддед нет

@setpoint_f не соглашусь, это уже пройденный этап, а вот архитектуру строить и тестировать свой код - этого в эмбеддед нет

Уже много где есть.

В соседней конфе люди обсуждали не раз.

значит и тут прогресс, а чего они тогда до сих пор микрооптимизациями увлекаются?

Там даже кто-то сервис пилит для удаленного запуска тестов на любых процах.

значит и тут прогресс, а чего они тогда до сих пор микрооптимизациями увлекаются?

У меня не достаточно компетенций что бы это осуждать или называть не нужным.

таки строки в C ужасны - как минимум небезопасны)

Проблема тестов на эбеддед в том, что тесты нормально не ложатся на не заточенную под тесты архитектуру. А подобная архитектура будет действительно создавать оверхед.

Хотя мб возможно что то на шаблонах навертить, но это все печально заканчивалось вроде.

Я тип видел проект эмбеддед опенсорсный, где ради того что бы усидеть на обоих стульях и тесты и ООП иметь, имелся обезумевший фреймворк на макросах с кодогенерацией. И блин помоему он больше багов делал =)

Нужно сделать еще одно, только простое решение!

Вы вот зря ушли. Я бы не прочь обсудить и послушать.

Оно с динамическим выделением памяти работает?

Оно с динамическим выделением памяти работает?

Это не к языку относится немножко. А к стандартной библиотеке.

Без явного на то указания С++ ничего в куче не выделит.

(хотя я вот гарантировать не буду, я его не знаю достаточно для таких утверждений).

Что-то не найду никак пример использования select() перед чтением через recv() для ESP32, не встречали такое? Заметил, что с опцией MSG_DONTWAIT recv() нормально детектит дисконнекты, но слишком часто вызывается.

хм, наверное здесь подойдет lwip_select()

Я тут до сих пор размышляю по ide, а вы как раз про c++. В esp idf в vs code либы так же как в ардуино интегрируются?

Я тут до сих пор размышляю по ide, а вы как раз про c++. В esp idf в vs code либы так же как в ардуино интегрируются?

я в вижулгдб пишу

она говно но можно жить, лучше чем вскод для С++

Что-то не найду никак пример использования select() перед чтением через recv() для ESP32, не встречали такое? Заметил, что с опцией MSG_DONTWAIT recv() нормально детектит дисконнекты, но слишком часто вызывается.

Вам дисконект tcp/ip ловить?

Вам дисконект tcp/ip ловить?

да, в основном это

Я тут до сих пор размышляю по ide, а вы как раз про c++. В esp idf в vs code либы так же как в ардуино интегрируются?

Ide тут не при чем. Берешь и в компоненты оборачиваешь если до тебя не обернули...