Non generic examples?

[jrjdavidson]

As i mentioned in #408 , I've been testing this repo on esp using esp-generate. Thanks for all the excellent work on this!

Bear in mind that I am not expert in embedded rust, however I thought I might share my experience. I've been attempting to read and notify data from an imu sensor that is connected to an esp32-c3 ( essentially the ble_bas_peripheral example). I managed to get this working as I expected, however it took me a while to wrap my head around it. Just when I tought I had everything working as expected, the process would hang at random points. I was getting quite frustrated, but it turns out it was mostly my implementation that was the issue. A few suggestion that might help others like me:

• The ble_peripheral example doesn't actual read any actual data. I wasn't sure how to pass a sensor to the data- especially given that my sensor data is updated in an async embassy_task, unlike the current bluetooth examples that are not generic and therefore cannot be spawned as tasks. It seems to me that in the current example, the bluetooth cannot be set up as async tasks and need to be awaited on the main loop once all other tasks have been set up? In the end, I set up a channel: pub static SENSOR_CHANNEL: Channel<CriticalSectionRawMutex, SensorData, 1> = Channel::new(); and this allowed me to pass and read data to the notify function, but it took me a while to implement it correctly.

• There is a suggestion that using non-generic controllers (and packet pools?) would allow you to spawn embassy_tasks ( before the ble_task function). I got stuck for a while trying to follow this suggestion, as I wasn't sure what the non generic controller type should be for the esp family. I gave up that route after a while. It it possible to follow this pattern on esp? An example that shows how to implement this would be a great addition!

Like I said, I got it working in the end and its preforming the way I had hoped, thanks again for this great project.

[jamessizeland]

I've made a non-generic example and put a link to it in the examples/esp32 readme here for just this reason https://github.com/embassy-rs/trouble/blob/main/examples%2Fesp32%2FREADME.md

I'm in the process of updating it for the new esp-hal changes. Happy to take advice on how to make it more prominent and/or useful. 😊

[lulf]

Thanks for the feedback @jrjdavidson !

The non-generic examples cause a lot of code duplication, but we should be able to make them somewhat customizeable by passing embedded-hal traits for interacting with a sensor (and create some dummy in-memory sensors)

Also, maybe if we had one example that just spelled out all the types for each platform, containing only very basic BLE functionality, we could prevent the code duplication, but have something to refer to for the platform-specificness

[jrjdavidson]

I've made a non-generic example and put a link to it in the examples/esp32 readme here for just this reason https://github.com/embassy-rs/trouble/blob/main/examples%2Fesp32%2FREADME.md

Ah - I missed that. I had looked at the examples a month ago to try and understand the repository was set up, and had a good look at the content of the esp32 folder then . Given that esp-generate set up most of the code in esp32 folder, I only had a look at the apps folder this time around. Sorry!

Also, maybe if we had one example that just spelled out all the types for each platform, containing only very basic BLE functionality, we could prevent the code duplication, but have something to refer to for the platform-specificness

I think this would be really great, a simple example that shows one (or more ) intended patterns of how to interact with the rest of the embassy eco-system, like how to read data that might exist in a separate async embassy task? Regarding non-generic types, a list of the what the non-generic types are would probably have been enough for me.

[finalyards]

I've been doing something very similar, https://github.com/finalyards/ZOO-esp32/tree/main/comms . Would you be willing to collab on the subfolder, perhaps?

Thinking of the larger picture, I'm - as a user of trouble - fine with the scope that the examples currently carry. They work for making sure that things compile, and show the basics of getting things on air. Adding more details means opinionated choices. One such is of the MCU platform. I've faced this in my own work (above), where I only support two ESP32 devkits. Luckily, ESP32-C3 happens to be one of them.

So. Wouldn't it be sufficient to have other repos, showing off the use of TrouBLE in their own liking. Like @jamessizeland mentioned about the reference to his (already there, choices start to matter - his work is for the Rust devkit, reducing my interest by a lot).

Suggestion: such a list could be within Trouble as a "showcase" - that gets occasionally updated, but doesn't guarantee the examples are e.g. up to date with the latest Trouble release. James' entry could be the starting point. I'm fine having ZOO.comms added in a few weeks, when I've caught up with the releases.

[lulf]

Suggestion: such a list could be within Trouble as a "showcase" - that gets occasionally updated, but doesn't guarantee the examples are e.g. up to date with the latest Trouble release. James' entry could be the starting point. I'm fine having ZOO.comms added in a few weeks, when I've caught up with the releases.

I think that's a great idea. We could have such a list in the README.md and/or in a dedicated page in the documentation.