Вероятно вы путаете неявное приведение и автоматический вывод типов. Или вы скажете, что auto a = ... в С++ тоже неявное приведение?
Вот это неявное приведение: uint8_t a = -100. А вот это автоматический вывод типов: let a: u8 = (-100).into().
При этом макросы куда хуже сишных, это отдельный какой-то регекс язык
<sarcasm on> Да да, препроцессор гораздо лучше разбора AST. Это просто сказка! <sarcasm off>
Муторный синтаксис, язык настроен так, что при любом самом мелком изменении приходится менять много кода.
Утиная типизация в С++ тоже имеет свои плюсы и минусы. Лично я думаю, что минусы перевешивают. Лучше написать чуть больше кода, но иметь больше контроля.
потому что язык слаб в шаблонах (джнериках)
Единственное с чем соглашусь. Но это пока, посмотрим через пару лет.
Теперь буду знать, что unsafe - это не для компилятора, а для программиста. Указание на то, что надо посмотреть документацию или реализацию.
unsafe - это контракт между программистом и компилятором. Если все его придерживаются, то он полностью избавляет от многих классов UB. На практике все ошибаются, и шанс не равен нулю, но очень мал.
Вообще я удивляюсь, что все так прицепились к unsafe блокам, как будто видят их впервые. В C# например они были еще с версии 1.0, задолго до Rust. И никого не смущало, что нужно оборачивать опасные места в коде в блоки unsafe.
Использовать у себя код, которому нет доверия? Вы серьезно?
В С например в документации к memcpy описано несколько вариантов, когда может случиться UB. В контексте этого обсуждения, это и есть тот самый недоверенный код. Но ведь все используют memcpy! Просто нельзя нарушать её инварианты.
В Rust такие функции помечают как unsafe, и в документации также как и в С описано, как её вызывать правильно, т.к. компилятор не может это проверить сам (а в случае asm! он вообще ничего проверить не может). А компилятор не даст просто так вызвать unsafe функцию.
Через unsafe блок программист говорит компилятору: я добавил в код все необходимые проверки (которые описаны в документации), и гарантирую что функция вызвана правильно. Ровно то же самое нужно делать на С с опасными функциями, но реализуется это не компилятором, а статическими анализаторами, санитайзерами и т.д.
Если же в unsafe блоке в коде ошибка, то может произойти UB с теми же последствиями, что и в С. Но тут программист хотя бы знает где начать искать ошибку.
Я наоборот вам показал, что связь не обязательно реализуется через WiFi и BLE. И в этом случае вовсе не обязательно использовать ESP32, подойдет любой МК.
Кроме того связь только одно из многих направлений, и для всех остальных подходит опять же любой МК, либо специализированный (не в нем вряд ли будет WiFi).
Всё это было к обсуждению, что новые ESP32 очень узкий случай. Для остального можно взять например старые ESP32, для которых не нужен Nightly компилятор.
Я вам ничего не приписывал, а пытался показать, что ваш случай очень узкий, а вы его обобщаете на все МК.
То есть, Вы придумали тезис, а теперь его опровергаете? Оригинально. Или Вы можете процитировать, где я писал обратное?
Какой именно я опровергаю? Вы сами придумали, и мне приписываете. Процитируйте.
При этом массово доступны ESP32-C3/C6 и т.п., RP2040, TLSR82696 и многие другие, появившиеся за последние пять лет.
Я писал про сравнение STM32F4 против STM32G4 как пример что G4 новые, а F4 старые. Причем тут другие МК?
Вот исходная моя цитата:
STM32G4xx тоже выпускается с 2021 года. Но все пишут на STM32F4, т.к. их проще купить (еще недавно G4 было вообще не купить) и их возможностей достаточно. Переход начался только сейчас, когда их цена почти сравнялась.
Демагогией развлекаетесь, да? Хватит выдирать из контекста!
В RTIC не совсем вытесняющая мультизадачность. Там общий стек, что по идеологии ближе к кооперативной мультизадачности.
Вытесняющая/кооперативная мультизадачность и общий/раздельный стек вообще разные вещи, и могут встречаться в любых сочетаниях друг с другом.
Например в RTIC вытесняющая с общим стеком, в FreeRTOS вытесняющая или кооперативная с раздельным, в Embassy вытесняющая или кооперативная с общим.
Во-первых, это не аппаратный планировщик, а лишь контроллер прерываний. Во-вторых, он есть только в CortexM.
И его можно использовать как планировщик. Но FreeRTOS не использует, из-за чего проигрывает в 6 раз по производительности на Cortex-M.
Как Вы собрались его применять в RP2040
Там есть ядра Cortex-M0+, в них есть NVIC.
)))
Ок, я был не прав. Как давно это добавили? Это обычный FreeRTOS, или специально допиленный для ESP32?
Как и любая OS, RTOS обязан поддерживать задачи на любых языках программирования.
Вы выступаете за интеграцию всего в RTOS, а я за подход "каждая библиотека делает только одну вещь". Это уже начало напоминать спор "Торвальдс против Танненбаума". Тут мы принципиально не сойдемся, нет смысла спорить.
Но замечу, что можно было бы выработать универсальное API для RTOS, как сделали в Embedded HAL для периферии. И тогда вопрос отпал бы сам собой, можно было бы применять любой подход.
Я боюсь, что скорее небезопасность Вы обнаружите в unsafe блоках, которыми изобилует Rust на МК или к Вам прилетит use-after-free от DMA, который не остановили по целому ряду причин. Уж поверьте коммитеру esp-rs, что таких приколов в Rust для embeded еще много не вычищено.
За это отвечают библиотеки HAL. А RTOS отвечает за безопасность переключений контекста. И код из разных языков ничего не знает о других языках. В С вылазят проблемы со статическими переменными и выделением/освобождением памяти, а в С++ (подключенном через С API) с RTTI, исключениями, выбрасыванием кода ошибки из деструкторов и т.д.
По-этому я за нормальные обертки на Rust, и категорически против прямого вызова С и С++ кода из RTOS.
Откажитесь от своего "золотого молотка".
Тезис про золотой молоток вы придумали сами, и как обычно мне приписываете. Берите нормальную обертку, которая учитывает времена жизни и проброс ошибок, и используйте код на других языках.
Уж поверьте коммитеру esp-rs
Это какое-то давление авторитетом? Я вот тоже например коммитил в Embassy, stm32f4xx-hal и т.д. и что?
А еще я писал свою RTOS с нуля на С, а потом переписал на Rust. А вы писали свою RTOS? Предлагаю не играть в авторитеты, а обсуждать по существу.
Я наоборот вам показал, что связь не обязательно реализуется через WiFi и BLE. И в этом случае вовсе не обязательно использовать ESP32, подойдет любой МК.
Кроме того связь только одно из многих направлений, и для всех остальных подходит опять же любой МК, либо специализированный (не в нем вряд ли будет WiFi).
Докажите.
Уже доказал. Зайдите на элитан, и посмотрите наличие. Любой новый МК будет пара штук в России, доставка от 30 дней, и не факт что вообще привезут. Могу еще привести Errata файлы, которые в момент выпуска МК неизвестны, и только через пару лет производитель их публикует.
Всё новое содержит баги, и это просто здравый смысл выждать время. Все мои знакомые так и поступают. Исключение - если нужен какой-то уникальный функционал, как у вас.
Сами хоть читали на что ссылаетесь? Там сравнивают вытесняющую мультизадачность с кооперативной. Если хотели сравнивать вытесняющую мультизадачность, то почему не порождали в RTIC отдельные задачи со своим стеком? А если хотели сравнивать кооперативную, то почему не сравнивали с короутинсами в FreeRTOS? Ну или хотя бы с родными async/await?
Это доказывает, что вы не читаете не только ссылки, но и комментарии. Я выше уже писал, что в RTIC у задач нет отдельного стека, и это гигантская экономия для процессора. Не нужно сохранять/подгружать регистры на стек, и еще делать кучу действий.
Там сравнение идет вытесняющей мультизадачности в RTIC с кооперативной в Embassy (на тот момент там еще не было вытесняющей), и с вытесняющей во FreeRTOS.
Но если всё переписать на вытесняющую, то результат не изменится, т.к. в Embassy и RTIC аппаратный планировщик NVIC против программного во FreeRTOS.
Что не умеет? Короутинсы поддерживает. Родные async/await тоже. О чем речь?
Запустите на FreeRTOS несколько кооперативных планировщиков с разным приоритетом. Если получится, я скажу что был не прав. Но не получится. И перестаньте читать по диагонали!
А вот ни Embassy, ни RTIC не поддерживают С ABI, что не позволяет обращаться к ним из других языков, кроме Rust. А это уже огромный минус, очень сильно сужающий их область применения.
А причем тут RTOS вообще? Это во первых не его задача, а во вторых небезопасно, легко вызвать race condition, и получить невоспроизводимый баг. Напишите / возьмите готовую обертку для нужной библиотеки, и используйте, в чем проблема?
Возможно вам больше подойдет TockOS и аналоги, чтобы запускать безопасно С код.
STM32G4xx тоже выпускается с 2021 года. Но все пишут на STM32F4, т.к. их проще купить (еще недавно G4 было вообще не купить) и их возможностей достаточно. Переход начался только сейчас, когда их цена почти сравнялась.
А вот с Вашей выборкой мне очень хочется ознакомиться. И думаю, далеко не только мне.
У меня тоже только личная выборка по общению с ~10 другими компаниями моего города.
Вы правда не видите, что первое Ваше предложение противоречит второму? )))
А в чем противоречие, если не секрет?
А зачем, если эта задача уже решена в FreeRTOS? Я удивлен, что Вам оплатили это велосипедостроение.
3 раза хаха. Во FreeRTOS одно из самых медленных (вероятно даже самое медленное) переключений контекста среди всех RTOS на С и С++. И это пример жесткого real-time? xD
Когда мне нужно действительно жесткий real-time, я беру RTIC. Это RTOS, полностью работающая на прерываниях и без отдельных стеков для потоков. Нет входа в PendSV и SVCall, нет планировщика, всё планирование на аппаратном NVIC.
RTIC в среднем в 3 раза быстрее переключает контекст, чем Embassy, который в среднем в 2 раза быстрее FreeRTOS (пруф).
Изучите FreeRTOS, прежде чем глупости писать. Наоборот, короутины (кооперативная мультизадачность) там появились не так давно, а уж приоритизация задач была от рождения.
Глупость пишите вы, т.к. не понимаете, что несколько планировщиков с разным приоритетом, внутри которых кооперативная многозадачность, будут работать значительно быстрее обычной вытесняющей многозадачности. Разделение ресурсов внутри кооперативной многозадачности не требует атомарных инструкций или отключения прерываний.
FreeRTOS так не умеет, но некоторые RTOS на С умеют. А в RTIC и Embassy всё на этом построено.
Вот по-этому вам в самом начале и написали, что пример слишком специфичный. Вы приводите новое железо как пример, и обобщаете на все встраиваемые устройства. При этом условные 99% новых разработок делаются на старом железе, и всё отлично собирается на stable.
Давайте вы наконец признаете, что это
Мало того, что нужен еще и упомянутый build.rs, так еще не редко требуется .cargo/config.toml, rust-toolchain.toml, sdkconfig.defaults и cfg.toml
вам нужно только под новые версии ESP, и не будете вводить всех в заблуждение.
Сравнивать распространенность МК с WiFi и BLE и МК общего назначения без них выглядит по дилетантский. Когда нужен WiFi, решения Expressif пока вне конкуренции. Можете убедиться сами, покопавшись в различных IoT устройствах с WiFi.
А я вот например пишу связь на LoRa и LoRaWAN, и еще на WiFi Broadcast. И WiFi с BLE мне не нужны, т.к. расстояние для связи >20км (на скольки метрах отваливается BLE?). Зато отлично подходят МК общего назначения.
Связь бывает разная, не надо её сводить только к одному решению.
Могу добавить, что Embassy не поддерживает аффинити и жесткого real-time с тайм-слайсинг. Этого мало?
У меня умеет. Просто вы не осилили написать свой модуль для Embassy. И это тоже очень специфичная вещь, требует тонкой настройки приоритетов прерываний, либо событий для запуска DMA. Вобщем каждый раз надо писать под конкретную задачу по-разному.
А еще можно запустить несколько Executor с разным приоритетом (привет FreeRTOS), так что вы тоже не в теме.
И из этого следует, что все остальные будут не только собираться, но еще и оптимально?
Из этого следует, что Nightly нужен только конкретным библиотекам под ESP32, я же писал про "на микроконтроллерах STM32 и других Cortex-M", читайте внимательнее.
С оптимизациями на Cortex-M и RISK-V тоже все норм. Не совсем понятно, какая кодогенерация вам нужна, но описание регистров для ESP32 и NRF точно кодогенерируется из yaml файлов, и без Nightly.
Как видите, не "хочется", а "требуется".
Как видите, требуется именно под ESP32. Но ESP32 не так уж и распространен, абсолютное большинство микроконтроллеров на архитектурах Cortex-M и RISK-V.
Перепишите весь ESP-IDF на Rust. Я не против. А до этого экономически нецелесообразно отказываться от уже имеющихся средств в пользу гипотетического успешного переписывания их в будущем.
На С есть реализации TCP стека (например CycloneTCP). Но в ESP-IDF написали свою реализацию всего на свете, вы считаете это правильная архитектура? И теперь внезапно огромная куча кода, которая жестко привязывает к своему API.
Теперь сравните это с Embedded HAL например. Я на нем один раз пишу драйвер для датчика, и он одинаково работает на любых микроконтроллерах и архитектурах.
Исходя из этого, я считаю целесообразным использовать ESP-IDF только если невозможно использовать другие чипы с WiFi. И код буду писать скорее на С, чтобы избавиться от всех тех проблем с Nightly, блобами и т.д., от которых вы так страдаете.
А это при чем? С точностью наоборот, применение embassy_net на ESP32 невозможно без esp-wifi с блобами. А esp-rs, естественно, вполне может обходиться без Embassy, пользуясь ESP-IDF, предоставляемого в исходниках.
Еще раз, все библиотеки для ESP32, использующие Embassy RTOS, это сторонняя разработка. Предъявляйте претензии по блобам к их авторам. В embassy_net нет зависимостей к этим библиотекам, убедитесь сами.
Если бы вы прошли по своей же ссылке (лол), то могли бы прочитать следующее:
esp-wifi for WiFi support on bare-metal ESP32 chips. Maintained by Espressif.
Сам Embassy поддерживает только те семейства микроконтроллеров, которые есть в его репозитории. Это STM32, NRF, RP2040, RP235x и еще парочка (но их добавили прям только что, и пока нет стабильности).
Как-то Вы лихо заявили о наличии стабильной поддержки кодогенерации и оптимизации для весьма широкой серии МК, да еще не только сейчас, но и в произвольный момент в будущем. Не погорячились?
Нет не погорячился. Несколько проектов для STM32, один для NRF и для RISC-V АМУР вполне себе собираются стабильным компилятором. Но если вам так хочется, используйте ночной.
Не только FreeRTOS, но и масса иного кода не на Rust требует установки переменных окружения при сборке.
Просто вы привыкли пользоваться FreeRTOS, и не хотите пробовать альтернативы. И про другой код хотелось бы поконкретнее.
Только если Вы являетесь производителем МК и разрабатываете весь софт для него сами сразу на Rust. Вы уж простите, но, для примера, я бы полгигабайта исходников ESP-IDF переписывал бы с C на Rust лет десять, явно не успевая за Espressif.
Про пол гигабайта мне видится явным преувеличением .. раз в 100 так. И зачем писать все самому, когда можно контрибьютить в существующие библиотеки?
Как по мне, лучше биндится к исходникам на C, чем к блобам как тут в Embassy.
А теперь найдите в этом esp-rs зависимость от Embassy xD) Не найдете, её не существует.
В Embassy никаких блобов конечно нет. Я вообще имел ввиду не весь проект, а конкретно RTOS. Можно взять RTOS из Embassy, и написать свою (или взять стороннюю) либу под конкретный микроконтроллер, как например я сделал для АМУР.
Если же вам нужен сетевой стек, то есть например https://github.com/smoltcp-rs/smoltcp, и он будет одинаково работать на STM32Wx и ESP32. И переписывать гигабайты не потребуется.
Не скажу за все встраиваемые системы, но на микроконтроллерах STM32 и других Cortex-M этого списка файлов я использую .cargo/config.toml всегда, build.rs иногда, остальные не нужны.
toolchain.toml не нужен, т.к. код собирается на стабильном компиляторе. sdkconfig.defaults вообще не понятно зачем, видимо ваш FreeRTOS требует. cfg.toml это что-то специфичное только для ESP32, к Cargo отношения не имеет.
И биндинг к другим языкам на микроконтроллерах не нужен, FreeRTOS не единственный RTOS, и как бы не самый худший из них. Посмотрите лучше на Embassy.
Тоже не понимаю, зачем обсуждать аргументы 2004 года. Очевидно, что за 20 лет ситуация поменялась.
Но по вашей же ссылке можно прочесть:
It was only in 2022 meanwhile that the Linux kernel began moving from C89 to C11. Especially if there is consensus to permit a subset of C++14/C++20 programming in the kernel, it may still be some time before it's adopted to allow for broader compiler support to roll out before raising the base compiler requirements and even if receiving the miraculous endorsement of Torvalds it's not a decision to be taken lightly.
Если стандарты С в ядре внедряются так медленно, то что же будет с С++? Так что вы выдаёте желаемое за действительное.
Спасибо за наглядную демонстрацию психологического типажа религиозных фанатов С++. Вполне очевидно, что вы не считаете нужным знать другие языки хотя бы поверхностно.
От того и пишите глупые ошибки про Rust или Java, в которых вас может уличить любой новичок, который потратил пару недель на изучение языка.
подменить контекст обсуждения ядра на микроконтроллеры и потом обвинять в этом собеседника - очень достойно
Про ядро я вам тоже ответил. И про разделение ответственности между библиотеками и прикладным кодом (к которому относится и код драйверов в ядре).
Вообще по последнему посту видно, что по сути сказать вам нечего, переход на личности это вполне доказывает.
при это игнорируя собственно практически важные вещи из треда
Укажите какие именно, и я на них отвечу. Телепатией пока не владею.
Вы можете собрать код без Cargo. Для этого нужно для каждого .rs файла запускать компилятор rustc с набором ключей компиляции, на выходе будут обычные .o файлы. Далее можно их слинковать системным линкером, желательно lld.
Но я не понимаю, зачем? Cargo это просто система сборки, как CMake для С и С++.
Теоретически можно использовать Cargo без rustup, и указать путь к компилятору rustc через переменную окружения, или .cargo/config.toml файл. Тогда можно будет использовать системный пакет с компилятором rustc, во многих дистрибутивах он есть (Debian и Ubuntu например).
Весь код на чистом Rust, и нет зависимостей от С или С++, соответственно и от gcc и llvm. Конечно компилятор Rust где-то внутри содержит llvm, но устанавливать системный не нужно.
Чтобы собрать, нужно установить компилятор Rust, и запустить строку cargo r -r -p crt < scenes/utah.crt > out.ppm (она скомпилирует и запустит код). И пожалуй всё на этом.
И? Там нет слова "неявное", что логично, т.к.
.into()
надо явно написать.Давайте приведу другой пример, тут уж должно быть абсолютно очевидно. Неявное приведение:
void func(uint8_t a) { ... }
func(-100)
Явное приведение с автоматическим выводом типа:
fn func(a: u8) { ... }
func((-100).into())
Если убрать
.into()
, то код не скомпилируется, т.к. в Rust сильная типизация, и неявных преобразований нет.Напишу на что не ответили другие.
Вероятно вы путаете неявное приведение и автоматический вывод типов. Или вы скажете, что
auto a = ... в С++
тоже неявное приведение?Вот это неявное приведение:
uint8_t a = -100
. А вот это автоматический вывод типов:let a: u8 = (-100).into()
.<sarcasm on> Да да, препроцессор гораздо лучше разбора AST. Это просто сказка! <sarcasm off>
Утиная типизация в С++ тоже имеет свои плюсы и минусы. Лично я думаю, что минусы перевешивают. Лучше написать чуть больше кода, но иметь больше контроля.
Единственное с чем соглашусь. Но это пока, посмотрим через пару лет.
unsafe - это контракт между программистом и компилятором. Если все его придерживаются, то он полностью избавляет от многих классов UB. На практике все ошибаются, и шанс не равен нулю, но очень мал.
Вообще я удивляюсь, что все так прицепились к unsafe блокам, как будто видят их впервые. В C# например они были еще с версии 1.0, задолго до Rust. И никого не смущало, что нужно оборачивать опасные места в коде в блоки unsafe.
В С например в документации к memcpy описано несколько вариантов, когда может случиться UB. В контексте этого обсуждения, это и есть тот самый недоверенный код. Но ведь все используют memcpy! Просто нельзя нарушать её инварианты.
В Rust такие функции помечают как unsafe, и в документации также как и в С описано, как её вызывать правильно, т.к. компилятор не может это проверить сам (а в случае asm! он вообще ничего проверить не может). А компилятор не даст просто так вызвать unsafe функцию.
Через unsafe блок программист говорит компилятору: я добавил в код все необходимые проверки (которые описаны в документации), и гарантирую что функция вызвана правильно. Ровно то же самое нужно делать на С с опасными функциями, но реализуется это не компилятором, а статическими анализаторами, санитайзерами и т.д.
Если же в unsafe блоке в коде ошибка, то может произойти UB с теми же последствиями, что и в С. Но тут программист хотя бы знает где начать искать ошибку.
Цитируйте, так уж полностью:
Всё это было к обсуждению, что новые ESP32 очень узкий случай. Для остального можно взять например старые ESP32, для которых не нужен Nightly компилятор.
Я вам ничего не приписывал, а пытался показать, что ваш случай очень узкий, а вы его обобщаете на все МК.
Но почему же вы ничего не отвечаете про RTOS? Это очень удобно, заострить внимание на чем то одном, и уйти от остальных вопросов. https://ru.wikipedia.org/wiki/Демагогия#Концентрация_на_частностях
Но тут описано всё правильно, и слог не похож на нейросеть. Статья полезная.
Лучше позвать модератора в те статьи, где все плохо.
Но в данной статье поднята важная проблема, и пути решения описаны правильно, за исключением одной маленькой опечатки.
Какой именно я опровергаю? Вы сами придумали, и мне приписываете. Процитируйте.
Я писал про сравнение STM32F4 против STM32G4 как пример что G4 новые, а F4 старые. Причем тут другие МК?
Вот исходная моя цитата:
Демагогией развлекаетесь, да? Хватит выдирать из контекста!
Вытесняющая/кооперативная мультизадачность и общий/раздельный стек вообще разные вещи, и могут встречаться в любых сочетаниях друг с другом.
Например в RTIC вытесняющая с общим стеком, в FreeRTOS вытесняющая или кооперативная с раздельным, в Embassy вытесняющая или кооперативная с общим.
И его можно использовать как планировщик. Но FreeRTOS не использует, из-за чего проигрывает в 6 раз по производительности на Cortex-M.
Там есть ядра Cortex-M0+, в них есть NVIC.
Ок, я был не прав. Как давно это добавили? Это обычный FreeRTOS, или специально допиленный для ESP32?
Вы выступаете за интеграцию всего в RTOS, а я за подход "каждая библиотека делает только одну вещь". Это уже начало напоминать спор "Торвальдс против Танненбаума". Тут мы принципиально не сойдемся, нет смысла спорить.
Но замечу, что можно было бы выработать универсальное API для RTOS, как сделали в Embedded HAL для периферии. И тогда вопрос отпал бы сам собой, можно было бы применять любой подход.
За это отвечают библиотеки HAL. А RTOS отвечает за безопасность переключений контекста. И код из разных языков ничего не знает о других языках. В С вылазят проблемы со статическими переменными и выделением/освобождением памяти, а в С++ (подключенном через С API) с RTTI, исключениями, выбрасыванием кода ошибки из деструкторов и т.д.
По-этому я за нормальные обертки на Rust, и категорически против прямого вызова С и С++ кода из RTOS.
Тезис про золотой молоток вы придумали сами, и как обычно мне приписываете. Берите нормальную обертку, которая учитывает времена жизни и проброс ошибок, и используйте код на других языках.
Это какое-то давление авторитетом? Я вот тоже например коммитил в Embassy, stm32f4xx-hal и т.д. и что?
А еще я писал свою RTOS с нуля на С, а потом переписал на Rust. А вы писали свою RTOS? Предлагаю не играть в авторитеты, а обсуждать по существу.
Я наоборот вам показал, что связь не обязательно реализуется через WiFi и BLE. И в этом случае вовсе не обязательно использовать ESP32, подойдет любой МК.
Кроме того связь только одно из многих направлений, и для всех остальных подходит опять же любой МК, либо специализированный (не в нем вряд ли будет WiFi).
Уже доказал. Зайдите на элитан, и посмотрите наличие. Любой новый МК будет пара штук в России, доставка от 30 дней, и не факт что вообще привезут.
Могу еще привести Errata файлы, которые в момент выпуска МК неизвестны, и только через пару лет производитель их публикует.
Всё новое содержит баги, и это просто здравый смысл выждать время. Все мои знакомые так и поступают.
Исключение - если нужен какой-то уникальный функционал, как у вас.
Это доказывает, что вы не читаете не только ссылки, но и комментарии. Я выше уже писал, что в RTIC у задач нет отдельного стека, и это гигантская экономия для процессора. Не нужно сохранять/подгружать регистры на стек, и еще делать кучу действий.
Там сравнение идет вытесняющей мультизадачности в RTIC с кооперативной в Embassy (на тот момент там еще не было вытесняющей), и с вытесняющей во FreeRTOS.
Но если всё переписать на вытесняющую, то результат не изменится, т.к. в Embassy и RTIC аппаратный планировщик NVIC против программного во FreeRTOS.
Запустите на FreeRTOS несколько кооперативных планировщиков с разным приоритетом. Если получится, я скажу что был не прав. Но не получится.
И перестаньте читать по диагонали!
А причем тут RTOS вообще? Это во первых не его задача, а во вторых небезопасно, легко вызвать race condition, и получить невоспроизводимый баг. Напишите / возьмите готовую обертку для нужной библиотеки, и используйте, в чем проблема?
Возможно вам больше подойдет TockOS и аналоги, чтобы запускать безопасно С код.
STM32G4xx тоже выпускается с 2021 года. Но все пишут на STM32F4, т.к. их проще купить (еще недавно G4 было вообще не купить) и их возможностей достаточно. Переход начался только сейчас, когда их цена почти сравнялась.
У меня тоже только личная выборка по общению с ~10 другими компаниями моего города.
А в чем противоречие, если не секрет?
3 раза хаха. Во FreeRTOS одно из самых медленных (вероятно даже самое медленное) переключений контекста среди всех RTOS на С и С++. И это пример жесткого real-time? xD
Когда мне нужно действительно жесткий real-time, я беру RTIC. Это RTOS, полностью работающая на прерываниях и без отдельных стеков для потоков. Нет входа в PendSV и SVCall, нет планировщика, всё планирование на аппаратном NVIC.
RTIC в среднем в 3 раза быстрее переключает контекст, чем Embassy, который в среднем в 2 раза быстрее FreeRTOS (пруф).
Глупость пишите вы, т.к. не понимаете, что несколько планировщиков с разным приоритетом, внутри которых кооперативная многозадачность, будут работать значительно быстрее обычной вытесняющей многозадачности. Разделение ресурсов внутри кооперативной многозадачности не требует атомарных инструкций или отключения прерываний.
FreeRTOS так не умеет, но некоторые RTOS на С умеют. А в RTIC и Embassy всё на этом построено.
Вот по-этому вам в самом начале и написали, что пример слишком специфичный. Вы приводите новое железо как пример, и обобщаете на все встраиваемые устройства. При этом условные 99% новых разработок делаются на старом железе, и всё отлично собирается на stable.
Давайте вы наконец признаете, что это
вам нужно только под новые версии ESP, и не будете вводить всех в заблуждение.
А я вот например пишу связь на LoRa и LoRaWAN, и еще на WiFi Broadcast. И WiFi с BLE мне не нужны, т.к. расстояние для связи >20км (на скольки метрах отваливается BLE?). Зато отлично подходят МК общего назначения.
Связь бывает разная, не надо её сводить только к одному решению.
У меня умеет. Просто вы не осилили написать свой модуль для Embassy. И это тоже очень специфичная вещь, требует тонкой настройки приоритетов прерываний, либо событий для запуска DMA. Вобщем каждый раз надо писать под конкретную задачу по-разному.
А еще можно запустить несколько Executor с разным приоритетом (привет FreeRTOS), так что вы тоже не в теме.
Из этого следует, что Nightly нужен только конкретным библиотекам под ESP32, я же писал про "на микроконтроллерах STM32 и других Cortex-M", читайте внимательнее.
С оптимизациями на Cortex-M и RISK-V тоже все норм.
Не совсем понятно, какая кодогенерация вам нужна, но описание регистров для ESP32 и NRF точно кодогенерируется из yaml файлов, и без Nightly.
Как видите, требуется именно под ESP32. Но ESP32 не так уж и распространен, абсолютное большинство микроконтроллеров на архитектурах Cortex-M и RISK-V.
На С есть реализации TCP стека (например CycloneTCP). Но в ESP-IDF написали свою реализацию всего на свете, вы считаете это правильная архитектура? И теперь внезапно огромная куча кода, которая жестко привязывает к своему API.
Теперь сравните это с Embedded HAL например. Я на нем один раз пишу драйвер для датчика, и он одинаково работает на любых микроконтроллерах и архитектурах.
Исходя из этого, я считаю целесообразным использовать ESP-IDF только если невозможно использовать другие чипы с WiFi. И код буду писать скорее на С, чтобы избавиться от всех тех проблем с Nightly, блобами и т.д., от которых вы так страдаете.
Еще раз, все библиотеки для ESP32, использующие Embassy RTOS, это сторонняя разработка. Предъявляйте претензии по блобам к их авторам. В embassy_net нет зависимостей к этим библиотекам, убедитесь сами.
Если бы вы прошли по своей же ссылке (лол), то могли бы прочитать следующее:
Сам Embassy поддерживает только те семейства микроконтроллеров, которые есть в его репозитории. Это STM32, NRF, RP2040, RP235x и еще парочка (но их добавили прям только что, и пока нет стабильности).
Нет не погорячился. Несколько проектов для STM32, один для NRF и для RISC-V АМУР вполне себе собираются стабильным компилятором. Но если вам так хочется, используйте ночной.
Просто вы привыкли пользоваться FreeRTOS, и не хотите пробовать альтернативы. И про другой код хотелось бы поконкретнее.
Про пол гигабайта мне видится явным преувеличением .. раз в 100 так. И зачем писать все самому, когда можно контрибьютить в существующие библиотеки?
А теперь найдите в этом esp-rs зависимость от Embassy xD) Не найдете, её не существует.
В Embassy никаких блобов конечно нет. Я вообще имел ввиду не весь проект, а конкретно RTOS. Можно взять RTOS из Embassy, и написать свою (или взять стороннюю) либу под конкретный микроконтроллер, как например я сделал для АМУР.
Если же вам нужен сетевой стек, то есть например https://github.com/smoltcp-rs/smoltcp, и он будет одинаково работать на STM32Wx и ESP32. И переписывать гигабайты не потребуется.
Не скажу за все встраиваемые системы, но на микроконтроллерах STM32 и других Cortex-M этого списка файлов я использую .cargo/config.toml всегда, build.rs иногда, остальные не нужны.
toolchain.toml не нужен, т.к. код собирается на стабильном компиляторе.
sdkconfig.defaults вообще не понятно зачем, видимо ваш FreeRTOS требует.
cfg.toml это что-то специфичное только для ESP32, к Cargo отношения не имеет.
И биндинг к другим языкам на микроконтроллерах не нужен, FreeRTOS не единственный RTOS, и как бы не самый худший из них. Посмотрите лучше на Embassy.
Тоже не понимаю, зачем обсуждать аргументы 2004 года. Очевидно, что за 20 лет ситуация поменялась.
Но по вашей же ссылке можно прочесть:
Если стандарты С в ядре внедряются так медленно, то что же будет с С++? Так что вы выдаёте желаемое за действительное.
А не они ли для этого написали свой компилятор, свой стандарт С++ и свою STL, из которого кроме исключений выпилили почти все UB?
То что получилось, уже никак нельзя называть языком С++.
Спасибо за наглядную демонстрацию психологического типажа религиозных фанатов С++. Вполне очевидно, что вы не считаете нужным знать другие языки хотя бы поверхностно.
От того и пишите глупые ошибки про Rust или Java, в которых вас может уличить любой новичок, который потратил пару недель на изучение языка.
Про ядро я вам тоже ответил. И про разделение ответственности между библиотеками и прикладным кодом (к которому относится и код драйверов в ядре).
Вообще по последнему посту видно, что по сути сказать вам нечего, переход на личности это вполне доказывает.
Укажите какие именно, и я на них отвечу. Телепатией пока не владею.
Вы можете собрать код без Cargo. Для этого нужно для каждого .rs файла запускать компилятор rustc с набором ключей компиляции, на выходе будут обычные .o файлы. Далее можно их слинковать системным линкером, желательно lld.
Но я не понимаю, зачем? Cargo это просто система сборки, как CMake для С и С++.
Теоретически можно использовать Cargo без rustup, и указать путь к компилятору rustc через переменную окружения, или .cargo/config.toml файл. Тогда можно будет использовать системный пакет с компилятором rustc, во многих дистрибутивах он есть (Debian и Ubuntu например).
Весь код на чистом Rust, и нет зависимостей от С или С++, соответственно и от gcc и llvm. Конечно компилятор Rust где-то внутри содержит llvm, но устанавливать системный не нужно.
Чтобы собрать, нужно установить компилятор Rust, и запустить строку
cargo r -r -p crt < scenes/utah.crt > out.ppm
(она скомпилирует и запустит код). И пожалуй всё на этом.А вы всегда отвечаете вопросом на вопрос?
Я на ваши вопросы отвечал, пусть ответы вас не устроили. Предлагаю ради разнообразия хоть раз ответить на мой вопрос.