Update Rust crate esp-idf-svc to 0.51.0 #16
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![renovate[bot]](https://avatars.githubusercontent.com/in/2740?s=60&v=4){kind=small}
renovate
bot
force-pushed
the
renovate/esp-idf-svc-0.x
branch
from
2e192fe to
21d58f6
Compare
renovate
bot
force-pushed
the
renovate/esp-idf-svc-0.x
branch
from
21d58f6 to
3945b73
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
0.25.0->0.51.0Warning
Some dependencies could not be looked up. Check the Dependency Dashboard for more information.
Release Notes
esp-rs/esp-idf-svc (esp-idf-svc)
v0.51.0Compare Source
Breaking
embassy-time-driverimplementation compatible withembassy-time-driverV0.2 (#548)Added
wifi_dhcp_with_hostnameto demonstrate setting a custom hostname when establishing a DHCP connectionv0.50.1Compare Source
Fixed
v0.50.0Compare Source
Deprecated
EspFirmwareInfoLoaderuseEspFirmwareInfoLoadinsteadBreaking
Added
esp_idf_log_timestamp_rtosfor ms since boot andesp_idf_log_timestamp_source_systemfor system time in rust logging (#494)EspFirmwareInfoLoadthat has a reduced memory consumption (#531)std::io::stdinFixed
eth_esp32_emac_default_config- 5.3 compatibilityv0.49.1Compare Source
Fixed
v0.49.0Compare Source
Deprecated
ESP-IDF v4.4 Please start upgrading to ESP-IDF v5.
Breaking
handler,fn_handlerandhandler_chainall now only accept'staticcallbacks,which is the only safe option in the presence of
core::mem::forgeton the HTTP server. All of those have theprevious behavior preserved in the form of
unsafe*_nonstaticvariants which were added. (#437)core::netwhich is re-exported byembedded-svcand is stable since Rust 1.77)Added
Fixed
v0.48.1Compare Source
esp_idf_svc::io::vfsmodule if the ESP IDF VFS component is not enabled eitherUnblockerutility was missingdropand therefore did not delete its task properly, resulting in a crash when the async MQTT client is droppedAsyncWifiwas notSendanymore (regression).Sendrestored.EspEventPostDatafrom&[u32]to&[u8]SendforAsyncWifiv0.48.0Compare Source
eventloop:esp-idf-svcevent loop types, as theembedded_svc::utils::asyncifymodule is now goneEspTypedEventLoopandEspPostboxare now retired. UseEspEventLoopdirectly, as it has the same functionalityEspEventFetchDatarenamed toEspEvent; bothEspEventandEspEventPostDatanow lifetimed instead of using raw pointersEspTypedEventSourceis renamed toEspEventSourceand marked as unsafe (i.e., implementors should dounsafe impl EspTypedEventSource for ...); check the documentation of the trait for justificationEspTypedEventDeserializerandEspTypedEventSerializerrenamed to justEspEventSerializerandEspEventDeserializer; more importantly, their payload is now modeled using a lifetimed GAT member calledData<'a>; this allows deserializers to implement zerocopy deserialization by referencing the event payload which is owned by the event loop; allesp-idf-svcdeserializers (notably -WifiEventandIpEvent) are now implemented with zerocopy, thus reducing the pressure on the system event loop task stack sizeEspEventtype is now also a dummy (no op)EspEventDeserializer; theEspEventPostDatatype is now also a dummy (no op)EspEventSerializersubscribe*andpost*are now slightly less convenient to use in that they need the (de)serializer specified using turbofish syntax, i.e.event_loop.subscribe::<WifiEvent, _>(...); this is so because these methods no longer require (and cannot require - due to the lifetimed GAT from above)where P: EspEvent(De)serializer<P>, i.e. the event type itself to implement the (de)sderializer, even if all event types provided byesp-idf-svcdo thatpost*andspinmethods now take a timeout of typeTickType_tas everywhere rather than the complexOption<Duration>http::server:embedded_svc::http::server, whereasHandlerErrorandHandlerResultwere removed, these types are no longer used in theembedded_svc::http::servermodule either. Check the Changelog ofembedded_svcfor more detailstimer: all async timer functionality now implemented directly on theesp-idf-svctimer types, as theembedded_svc::utils::asyncifymodule is now gonemqtt::client:esp-idf-svcMQTT types, as theembedded_svc::utils::asyncifymodule is now goneembedded_svc::mqtt::clientAPI contract:EspMqttClientandEspMqttConnection, as well as the number of offered constructorsEspMqttEventwhich implements theembedded_svc::mqtt::client::Eventtrait - valid for both callback-based event processing as well as for connection-based blocking and asynchronous event processingAsyncEspTlsrenamed toEspAsyncTlsheaplessto 0.8embassy-timeand replace it with a dependency onembassy-time-driver; get rid of the custom embassy time queue as it was anyway re-implementing something like a generic timer queue, which is available in theembassy-timecrate (with its featuregeneric-queueenabled)http::server::Configuration::max_resp_handlersrenamed tohttp::server::Configuration::max_resp_headersEspPingto 64EspWifito swap STA and AP netifs separately from each otherv0.47.3Compare Source
services
EspNow, driverEthDriver,EventLoop,Wait,EspHttpServer,EspMqttClient,EspSntp,EspTimerService,driver
WifiDriverandEspWebSocketClientno longer accept non-static callbacks, as these lead to UB / crash when the service/driver/subscriptionis forgotten with e.g.
core::mem::forget. Since local borrows are a very useful feature however, these are still allowed via the newly-introducedand
unsafemethods/constructors that follow the naming pattern of the safe methods/constructors, but with a_nonstaticsuffix attached.v0.47.2Compare Source
AtomicU64which is no longer supported by the upstream*-espidftargetsv0.47.1embedded-svc0.26.1v0.47.0experimentalmodule -bt- providing Bluetooth support based on the ESP-IDF Bluedroid implementationtlsmodule viaEspTlsand (for async mode)AsyncEspTlsmqttesp-idf-sysandesp-idf-halare now re-exported asesp_idf_svc::sysandesp_idf_svc::halembedded-svc0.26EspOta::finishthat allows to postpone/avoid setting the updated partition as a boot oneEspOtaUpdatenow parametric over the lifetime of a mutable reference toEspOtaand returned by valueEspOtaUpdate::abortandEspOtaUpdate::completenow takeselfinstead of&mut selfEspHttpServerinstance. Therefore,EspHttpServeris now lifetimed:EspHttpServer<'a>EspHttpRequestrenamed toEspHttpRawConnectionEspWebSocketClientinstance. Therefore,EspWebSocketClientis now lifetimed:EspWebSocketClient<'a>EspTimerinstance. Therefore,EspTimeris now lifetimed:EspTimer<'a>EspSubscriptioninstance. Therefore,EspSubscriptionis now lifetimed:EspSubscription<'a, ...>EspMqttClientinstance. Therefore,EspMqttClientis now lifetimed:EspMqttClient<'a, ...>EspNowinstance. Therefore,EspNowis now lifetimed:EspNow<'a>EspSntpinstance. Therefore,EspSntpis now lifetimed:EspSntp<'a>EspPing::ping_detailsnow takes aFnMutcallback, however the callback needs to beSendhttpdand the dependency onanyhownotifyremoved as it was rarely - if ever - used, and there is a simplerhal::task::notificationmodule nowv0.46.2Compare Source
v0.46.1Compare Source
wifi_scan_config_t)v0.46.0Compare Source
experimentalstatus from all formerly experimental featuresnightlyfeature flag guard from allasyncifymodules as Rust GATs are stable nowWifi,EthandEspNetifthat abstract away the ESP IDF system event loop (for easier initial configuration) - API breakage innetifEthSPI driver rebased on top ofesp-idf-hal'sSpiDeviceDriver; it can now either borrow or own the SPI device driver (API breakage)Ethdriver now supports SPI bus sharing with other SPI devices (API breakage)NVS- additional APIs that support the serde format of the ESP IDF NVS C codeSNTP- new, callback APIlog- support for setting target level per moduleOTA- small API extensionsnetif- compilation errors when PPP & SLIP support is enabled are addressedEspError::from_infalliblev0.45.0Compare Source
HTTP server:
embedded-svcV0.24fn_handlerthat addresses HRTB lifetime issues when converting a Fn closure to aHandlerinstanceEspHttpFnTraversableChain; it is not necessary, now that thefn_handlerfunction from above does existv0.44.0Compare Source
Rebase on top of
esp-idf-sys0.32:esp-idf-sys::c_typesin favor ofcore::fficstr_coredependency asCstrandCStringare now part of Rust coreusizetou32and back now thatesp-idf-sysis compiled with--size_t-is-usizeenabledv0.43.5Compare Source
Patch releases:
v0.43.4Compare Source
Patch releases:
v0.43.3Compare Source
Patch releases:
v0.43.2Compare Source
Patch releases to fix compilation errors under no_std.
v0.43.1Compare Source
Patch releases to fix compilation errors under no_std.
v0.43.0Compare Source
Release 0.43 is a backwards-incompatible release where almost all services were touched in one way or another.
Major Changes
The main themes of the 0.43 release are:
embedded-svcnvs_storagemodule intonvsembassy-timecrate by providing alarm implementationembassy-timecrate by providing timer queue implementationMajor changes elaboration
Public API
In addition to implementing the
embedded-svctraits where possible, all services now have public API. While the public API loosely follows the APIs fromembedded-svc, it deviates where appropriate so that the native underlying ESP IDF service is better utilized.These public APIs mean that the user is no longer required to depend on the
embedded-svccrate so as to consume theesp-idf-svcservices.Consuming the services via the
embedded-svctraits is now only necessary when the user is targetting cross-platform portability of their application code.Expose access to the wrapped ESP IDF services / drivers
All services now implement the
Handletrait which does provide a reference to the native underlying ESP IDF service or driver. This is useful when the Rust wrapper for the service does not expose a particular functionality, as in that case, users can still call the functionality by using the rawesp-idf-svcbindings for the service.Wifi & Eth: separate layer 2 (Ethernet) from layer 3 (IP)
The Wifi and Ethernet drivers are now split into two separate structures:
WifiDriver/EthDriver- these are layer 2 (Ethernet) drivers which follow all the conventions of the other drivers in theesp-idf-halcrate, including the need to own or mutably borrow the actual petihperal (the Wifi modem peripheral or the RMII / SPI peripheral fromesp-idf-hal). They are however part ofesp-idf-svcas this is better aligned with their native ESP IDF counterparts, which actually do use/rely on certain ESP IDF services, like the event loop and NVS storage, which - being services - are also exposed as part ofesp-idf-svc, and not as part ofesp-idf-hal. These drivers implement theWifiandEthtraits respectively, which were redesigned to not have any IP-related semantics. Users are allowed to use the Layer 2 drivers directly by providing their own custom RX callbacks, thus completely bypassing the ESP IDF LwIP IP & Netif layer (i.e. withsmoltcpor other 3rd party IP stack)EspWifi/EspEth- these are layer 3 (IP) + layer 2 (Ethernet) services, which - on construction - are expected to own aWifiDriver/EthDriver- either by constructing it themselves, or by the user passing the driver. These services "glue" the ESP IDF IP & Netif layer (EspNetif) with the ethernet layer provided by the drivers. These services also implement theWifi/Ethtraits, as they are wrapping Layer 2 functionality anyway. The Layer 3 functionality (configuring the network interface as well as fetching IP-related information from the network interfaces) however uses custom methods on the services' themselves and is not (yet) abstracted usingembedded-svctraits.Additionally, the
WifiandEthtrait implementations now provide finer grained control over the behavior of their drivers / services in that users should explicitly callstart/stopto start/stop the driver, as well asconnect/disconnect(for the Wifi driver in STA mode) to connect to an access point. While this makes the driver configuration a bit more involved, these changes provide the necessary flexibility for some corner use cases:EspNowESP NOW service, there is no need to actuallyconnectthe driver at all, which is now possibleHttp client & server: implement the new traits from
embedded-svcSubject says it all, so to say.
Merge the
nvs_storagemodule intonvsRawStoragetrait, which provides facilities for reading / writing blobs. It is up to the user to layer aStorageimplementation on top of theRawStorageimplementation, but the benefit of that is that user is in control of how their structures are serialized/deserialized into binary. To ease the layering, users may take advantage of theStorageImplstructure fromembedded-svcand only provide aSerdetrait implementation which abstracts away the concrete Rust SerDe implementation (i.e.serde-json,postcard, etc.)Support for the
embassy-timecrate by providing alarm implementationesp-idf-svcprovides an implementation ofembassy-time's alarm interface (theDrivertrait), which is implemented in terms of the ESP IDF Timer service (also exposed in thetimermodule ofesp-idf-svc).To use this feature, users need to enable the
embassy-time-driverCargo feature.Support for the
embassy-timecrate by providing timer queue implementationesp-idf-svcdoes provide a customembassy-timeTimer Queue implementation (also implemented in terms of the ESP IDF Timer service), even though in the meantimeembassy-timefeatures a generic timer queue which works everywhere and can also be used. This custom timer queue does not rely on the alarms interface provided by theembassy-timecrate (see the previous section).The one major difference between
embassy-time's generic timer queue, and the one provided byesp-idf-svcis that the latter has a slightly lower latency in that it does support theCONFIG_ESP_TIMER_SUPPORTS_ISR_DISPATCH_METHOD=yESP IDF configuration parameter. When this parameter is enabled, theesp-idf-svctimer queue does not use the ESP IDF Timer Service dispatch task/thread and notifies the executor about due timers directly from the ISR routine. When this parameter is not enabled, theesp-idf-svctimer queue has no benefits compared to the generic timer queue inembassy-time.NOTE:
esp-idf-svctimer queue should only be used with async executors that are ISR safe, in that they can be awoken from an ISR.edge-executoris such an executor.embassy-executoris currently NOT ISR safe, because it relies - for its synchronization - on thecritical-sectioncrate, yet the critical section implementation that thecritical-sectioncrate uses on top ofesp-idf-halis based on a FreeRTOS mutex, and NOT on a disable-all-interupts ISR-safe implementation (that is, unless the user has configured a more elaborate setup with their own critical section implementation). On the other hand,embassy-executorhas its own highly optimized timer queue which should probably be used anyway and is enabled by defaultembassy-timecrateTo use this feature, users need to enable the
embassy-time-isr-queueCargo feature.v0.42.5Compare Source
v0.42.4Compare Source
v0.42.3Compare Source
v0.42.2Compare Source
v0.42.1Compare Source
v0.42.0Compare Source
v0.41.4Compare Source
v0.41.3Compare Source
v0.41.2Compare Source
v0.41.1Compare Source
v0.41.0Compare Source
v0.40.1Compare Source
v0.40.0Compare Source
v0.39.2Compare Source
v0.39.1Compare Source
v0.39.0Compare Source
v0.38.2Compare Source
v0.38.1Compare Source
v0.38.0Compare Source
v0.37.3Compare Source
v0.37.2Compare Source
v0.37.0Compare Source
v0.36.10Compare Source
v0.36.9Compare Source
v0.36.8Compare Source
v0.36.7Compare Source
v0.36.6Compare Source
v0.36.5Compare Source
v0.36.4Compare Source
v0.36.3Compare Source
v0.36.2Compare Source
v0.36.1Compare Source
v0.36.0Compare Source
v0.35.2Compare Source
v0.35.1Compare Source
v0.35.0Compare Source
v0.34.3Compare Source
v0.34.2Compare Source
v0.34.1Compare Source
v0.34.0Compare Source
v0.33.0Compare Source
v0.32.3Compare Source
v0.32.2Compare Source
v0.32.1Compare Source
v0.32.0Compare Source
v0.31.1Compare Source
v0.31.0Compare Source
v0.30.0Compare Source
v0.29.2Compare Source
v0.29.1Compare Source
v0.29.0Compare Source
v0.28.1Compare Source
v0.28.0Compare Source
v0.27.2Compare Source
Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.