Комментарии 25
Забыли сказать про cargo add для добавления зависимостей через консоль — как по мне удобнее, чем возиться с текстовым конфигом
потому что в Rust иначе нельзя
однако
Можно, конечно, скомпилить .rs вручную через rustc
Нельзя, но оказывается можно.
Rust edition (
2015,2018,2021— сейчас это важно, особенно для async/await),
Rust edition (2015, 2018, 2021, 2024 — сейчас это важно, особенно для async || {}),
И стоило, кмк, упомянуть
[[example]]
name = "foo"
.
├── Cargo.lock
├── Cargo.toml
├── src/
│ └── lib.rs
│
└── examples/
└── foo.rs
Очень удобно, что линкуются сразу с [dependencies] и [dev-dependencies].
И именно
Cargo.tomlпозволяет создавать то, что в других языках потребовало бы 10 конфигов, 3 генератора и одинbuild.rs.
Тут несколько лукавите. Далеко не для всех проектов достаточно Cargo.toml.
Мало того, что нужен еще и упомянутый build.rs, так еще не редко требуется .cargo/config.toml, rust-toolchain.toml, sdkconfig.defaults и cfg.toml
Для примера.
И вы лукавите будем честны, пример весьма специфичный
Чем специфичен? Необходимостью биндинга к исходному коду на отличных от Rust языках? Или в кросскомпиляции? Ну так Rust и предназначен для замены C. В том числе и на встраиваемых системах, где C/C++ сейчас используются повсеместно.
Лично я бы предпочел, чтобы Cargo мог стать заменой make/cmake и т.п. Что в этом плохого?
Потому что большинство разрабов это веб-разрабы )
Не скажу за все встраиваемые системы, но на микроконтроллерах STM32 и других Cortex-M этого списка файлов я использую .cargo/config.toml всегда, build.rs иногда, остальные не нужны.
toolchain.toml не нужен, т.к. код собирается на стабильном компиляторе.
sdkconfig.defaults вообще не понятно зачем, видимо ваш FreeRTOS требует.
cfg.toml это что-то специфичное только для ESP32, к Cargo отношения не имеет.
И биндинг к другим языкам на микроконтроллерах не нужен, FreeRTOS не единственный RTOS, и как бы не самый худший из них. Посмотрите лучше на Embassy.
на микроконтроллерах STM32 и других Cortex-M
toolchain.toml не нужен, т.к. код собирается на стабильном компиляторе
Как-то Вы лихо заявили о наличии стабильной поддержки кодогенерации и оптимизации для весьма широкой серии МК, да еще не только сейчас, но и в произвольный момент в будущем. Не погорячились?
sdkconfig.defaults вообще не понятно зачем, видимо ваш FreeRTOS требует
Не только FreeRTOS, но и масса иного кода не на Rust требует установки переменных окружения при сборке.
Нравится Вам это или нет, но "золотого молотка" не существует. Так же как и самого лучшего языка программирования. И реальные проекты часто объединяют исходники на нескольких языках.
cfg.toml это что-то специфичное только для ESP32, к Cargo отношения не имеет.
Это стандартный toml-cfg. На STM32 конфигурацию я точно так же задаю.
И биндинг к другим языкам на микроконтроллерах не нужен
Только если Вы являетесь производителем МК и разрабатываете весь софт для него сами сразу на Rust. Вы уж простите, но, для примера, я бы полгигабайта исходников ESP-IDF переписывал бы с C на Rust лет десять, явно не успевая за Espressif.
Посмотрите лучше на Embassy.
Как по мне, лучше биндится к исходникам на C, чем к блобам как тут в Embassy.
Что самое смешное, Embassy ссылается на esp-rs, который сидит сверху ESP-IDF.
Как-то Вы лихо заявили о наличии стабильной поддержки кодогенерации и оптимизации для весьма широкой серии МК, да еще не только сейчас, но и в произвольный момент в будущем. Не погорячились?
Нет не погорячился. Несколько проектов для 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, один для NRF и для RISC-V АМУР вполне себе собираются стабильным компилятором.
И из этого следует, что все остальные будут не только собираться, но еще и оптимально?
Для RP2040 мне, например, пришлось одно время на nightly-2024-05-09 сидеть из-за PIO.
Но если вам так хочется, используйте ночной.
Furthermore, for ESP32-C3, a nightly version of the Rust toolchain is currently required
Как видите, не "хочется", а "требуется".
А теперь найдите в этом esp-rs зависимость от Embassy
А это при чем? С точностью наоборот, применение embassy_net на ESP32 невозможно без esp-wifi с блобами. А esp-rs, естественно, вполне может обходиться без Embassy, пользуясь ESP-IDF, предоставляемого в исходниках.
В Embassy никаких блобов конечно нет.
Но он на них непосредственно ссылается в embassy-net.
Можно взять RTOS из Embassy, и написать свою (или взять стороннюю) либу под конкретный микроконтроллер, как например я сделал для АМУР.
Перепишите весь ESP-IDF на Rust. Я не против. А до этого экономически нецелесообразно отказываться от уже имеющихся средств в пользу гипотетического успешного переписывания их в будущем.
Если же вам нужен сетевой стек, то есть например https://github.com/smoltcp-rs/smoltcp, и он будет одинаково работать на STM32Wx и ESP32
Как минимум, только навскидку, ESP-NOW, ESP-MESH и ESP-MESH-LITE там работать не будут.
И мне нужен далеко не только сетевой стек.
И из этого следует, что все остальные будут не только собираться, но еще и оптимально?
Из этого следует, что 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-wififor WiFi support on bare-metal ESP32 chips. Maintained by Espressif.
Сам Embassy поддерживает только те семейства микроконтроллеров, которые есть в его репозитории. Это STM32, NRF, RP2040, RP235x и еще парочка (но их добавили прям только что, и пока нет стабильности).
Вижу, что Вы не в теме, ау меня времени нет, Вам все разжевывать. Поэтому кратко, по пунктам.
С ESP32 на Xtensa как раз никаких проблем нет. Это достаточно старое ядро, как и те CortexM, с которыми Вы работаете.
Необходимость nightly возникает с новыми ядрами. Преимущественно это как раз RISC-V. Поэтому код для устаревших Xtensa (ESP32, ESP32-S) собирается stable. А вот для новых ядер RISC-V (ESP32-C,-H и -P) - пока nightly.
Такая же необходимость nightly была и с RP2040 из-за PIO (хоть знаете, что это?). Возможно, она сохраняется и до сих пор. Не проверял. И то же самое будет и дальше с появлением новых ядер и различных сопроцессорах. Никуда Вы от этого не денетесь.
Правильная архитектура - это когда можно использовать все возможности MK. Я уже указывал на ESP-MESH и ESP-NOW. Могу добавить, что Embassy не поддерживает аффинити и жесткого real-time с тайм-слайсинг. Этого мало?
Сравнивать распространенность МК с WiFi и BLE и МК общего назначения без них выглядит по дилетантский. Когда нужен WiFi, решения Expressif пока вне конкуренции. Можете убедиться сами, покопавшись в различных IoT устройствах с WiFi.
Рекомендую всё же признать, что "золотого молотка" не существует.
Вот по-этому вам в самом начале и написали, что пример слишком специфичный. Вы приводите новое железо как пример, и обобщаете на все встраиваемые устройства. При этом условные 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), так что вы тоже не в теме.
Вы приводите новое железо как пример
ESP32-C3 выпускается с 2020 года.
99% новых разработок делаются на старом железе
Докажите, что 99% новых разработок ведутся на МК выпускаемых свыше пяти лет. Я наблюдаю обратное, но у меня нет репрезентативной выборки для указания чисел, как у Вас. А вот с Вашей выборкой мне очень хочется ознакомиться. И думаю, далеко не только мне.
А я вот например пишу
не надо её сводить только к одному решению
Вы правда не видите, что первое Ваше предложение противоречит второму? )))
вы не осилили написать свой модуль для Embassy
А зачем, если эта задача уже решена в FreeRTOS? Я удивлен, что Вам оплатили это велосипедостроение.
Вобщем каждый раз надо писать под конкретную задачу по-разному.
Вот еще один минус сами указали. Выше трудоемкость и требования к квалификации разработчика, чем в случае FreeRTOS.
А еще можно запустить несколько Executor с разным приоритетом (привет FreeRTOS), так что вы тоже не в теме.
Изучите FreeRTOS, прежде чем глупости писать. Наоборот, короутины (кооперативная мультизадачность) там появились не так давно, а уж приоритизация задач была от рождения.
ESP32-C3 выпускается с 2020 года.
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 всё на этом построено.
все пишут на STM32F4
Докажите.
У меня тоже только личная выборка по общению с ~10 другими компаниями моего города.
99% новых разработок делаются на старом железе
То есть Вы не можете доказать своё утверждение? Зачем писать догмы, которые не можете доказать? Мы тут не Ветхий Завет вообще-то обсуждаем.
А в чем противоречие, если не секрет?
Внимательней перечитайте, что пишете. Начинаете с того, что исходя из того, что лично Вам ESP32 не нужен, делаете из этого странный вывод:
ESP32 не так уж и распространен,
После чего вдруг идете на попятную
не надо её сводить только к одному решению
Вот именно. Если Вам лично что-то не нужно, из этого не следует вообще ничего, кроме Ваших желаний и субъективной оценки.
Во FreeRTOS одно из самых медленных (вероятно даже самое медленное) переключений контекста среди всех RTOS на С и С++.
Докажите.
RTIC в среднем в 3 раза быстрее переключает контекст, чем Embassy, который в среднем в 2 раза быстрее FreeRTOS (пруф).
Сами хоть читали на что ссылаетесь? Там сравнивают вытесняющую мультизадачность с кооперативной. Если хотели сравнивать вытесняющую мультизадачность, то почему не порождали в RTIC отдельные задачи со своим стеком? А если хотели сравнивать кооперативную, то почему не сравнивали с короутинсами в FreeRTOS? Ну или хотя бы с родными async/await?
FreeRTOS так не умеет
Что не умеет? Короутинсы поддерживает. Родные async/await тоже. О чем речь?
А вот ни Embassy, ни RTIC не поддерживают С ABI, что не позволяет обращаться к ним из других языков, кроме Rust. А это уже огромный минус, очень сильно сужающий их область применения.
Я наоборот вам показал, что связь не обязательно реализуется через 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 и аналоги, чтобы запускать безопасно С код.
Я наоборот вам показал, что связь не обязательно реализуется через WiFi и BLE.
То есть, Вы придумали тезис, а теперь его опровергаете? Оригинально. Или Вы можете процитировать, где я писал обратное?
Уже доказал.
Напомню фразу, сказанную в контексте "Докажите, что 99% новых разработок ведутся на МК выпускаемых свыше пяти лет."
все пишут на STM32F4
При этом массово доступны ESP32-C3/C6 и т.п., RP2040, TLSR82696 и многие другие, появившиеся за последние пять лет.
И даже STM32G431 доступен на Aliexpress лишь чуть дороже,, что и STM32F412RET6
Вот я и прошу доказать, что "все пишут на STM32F4" и никто не пишет на ESP32-С/H/P*, RP2040, TLSR82696 и т.п.
Всё новое содержит баги, и это просто здравый смысл выждать время. Все мои знакомые так и поступают.
Но именно новое дает конкурентные преимущества. Добиться на старом конкурентного преимущества чрезвычайно сложно.
Там сравнение идет вытесняющей мультизадачности в RTIC с кооперативной в Embassy (на тот момент там еще не было вытесняющей), и с вытесняющей во FreeRTOS.
В RTIC не совсем вытесняющая мультизадачность. Там общий стек, что по идеологии ближе к кооперативной мультизадачности. Я даже не представляю, как он может работать на двух и более ядрах. И тем более не может работать при использовании разных языков программирования.
аппаратный планировщик NVIC
Во-первых, это не аппаратный планировщик, а лишь контроллер прерываний. Во-вторых, он есть только в CortexM. Как Вы собрались его применять в RP2040 или TLSR82696 мне совершенно неясно.
Запустите на FreeRTOS несколько кооперативных планировщиков с разным приоритетом.
fn spawn_runtime(priority: ThreadPriority, policy: ThreadSchedulePolicy) -> Runtime {
let thread_id = thread_native_id();
let current_priority = get_current_thread_priority().unwrap();
let current_policy = thread_schedule_policy().unwrap();
if set_thread_priority_and_policy(thread_id, priority, policy).is_err() {
warn!("can't set policy {policy:?} with priority {priority:?}");
};
let runtime = tokio::runtime::Builder::new_multi_thread()
.enable_all()
.build()
.unwrap();
info!("starter runtime with scheduling policy {policy:?} and priority {priority:?}");
if set_thread_priority_and_policy(thread_id, current_priority, current_policy).is_err() {
warn!("can't set policy {policy:?} with priority {priority:?}");
};
runtime
}
static HIGH_PRIORITY_RUNTUME: LazyLock<Runtime> = LazyLock::new(|| {
spawn_runtime(
22.try_into().unwrap(),
ThreadSchedulePolicy::Realtime(RealtimeThreadSchedulePolicy::RoundRobin),
)
});
static NORMAL_PRIORITY_RUNTUME: LazyLock<Runtime> = LazyLock::new(|| {
spawn_runtime(
21.try_into().unwrap(),
ThreadSchedulePolicy::Realtime(RealtimeThreadSchedulePolicy::RoundRobin),
)
});Если получится, я скажу что был не прав.
)))
А причем тут RTOS вообще?
Как и любая OS, RTOS обязан поддерживать задачи на любых языках программирования. Вы сами согласились бы работать под OS, которая поддерживает один и только один язык программирования? Так почему на современных MK, которые намного мощней первых ПК должно быть иначе?
во вторых небезопасно, легко вызвать race condition, и получить невоспроизводимый баг
На MicroPython, nanoFramework, Java(MICROEJ) и т.п.? )))
Я боюсь, что скорее небезопасность Вы обнаружите в unsafe блоках, которыми изобилует Rust на МК или к Вам прилетит use-after-free от DMA, который не остановили по целому ряду причин. Уж поверьте коммитеру esp-rs, что таких приколов в Rust для embeded еще много не вычищено.
Откажитесь от своего "золотого молотка". Это тупик. Rust - замечательный язык программирования. Но он никогда не сможет заменить все языки программирования по объективным причинам.
То есть, Вы придумали тезис, а теперь его опровергаете? Оригинально. Или Вы можете процитировать, где я писал обратное?
Какой именно я опровергаю? Вы сами придумали, и мне приписываете. Процитируйте.
При этом массово доступны 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.
А теперь процитируйте, где я утверждал обратное.
Я писал про сравнение STM32F4 против STM32G4 как пример что G4 новые, а F4 старые. Причем тут другие МК?
Я попросил Вас доказать Ваше утверждение
99% новых разработок делаются на старом железе
В ответ получил
STM32G4xx тоже выпускается с 2021 года. Но все пишут на STM32F4, т.к. их проще купить
Я подумал, что человек просто ошибся, и напомнил о множестве других МК.
Но Вы доказали, что это была не ошибка, а https://ru.wikipedia.org/wiki/Демагогия#Подмена_тезиса
Прошу прощения, но доказывать что-либо демагогу считаю бессмысленным. Прощайте.
Цитируйте, так уж полностью:
Я наоборот вам показал, что связь не обязательно реализуется через WiFi и BLE. И в этом случае вовсе не обязательно использовать ESP32, подойдет любой МК.
Кроме того связь только одно из многих направлений, и для всех остальных подходит опять же любой МК, либо специализированный (не в нем вряд ли будет WiFi).
Всё это было к обсуждению, что новые ESP32 очень узкий случай. Для остального можно взять например старые ESP32, для которых не нужен Nightly компилятор.
Я вам ничего не приписывал, а пытался показать, что ваш случай очень узкий, а вы его обобщаете на все МК.
Но почему же вы ничего не отвечаете про RTOS? Это очень удобно, заострить внимание на чем то одном, и уйти от остальных вопросов. https://ru.wikipedia.org/wiki/Демагогия#Концентрация_на_частностях
Как работает Cargo