Advice on doing away with the C generic parameters (ble_bas_peripheral)

[lure23]

The ble_bas_peripheral has a comment:

/// ## Alternative
///
/// If you didn't require this to be generic for your application, you could statically spawn this with i.e.
///
/// #[embassy_executor::task]
/// async fn ble_task(mut runner: Runner<'static, SoftdeviceController<'static>>) {
///     runner.run().await;
/// }
///
/// spawner.must_spawn(ble_task(runner));

I am only targeting ESP32, so don't need the C generics (I assume they are there to have the same code support many platforms).

1. How should I code the "alternative"?

Every place in trouble code using spawner is in the main(). But I cannot place the line 104 to main since it uses runner - and runner is direved within run() here.

I can surely get this working one way or the other, but would like to hear how you would change the code for the alternative approach.

2. How about... not needing the generics?

This is a suggestion from a newcomer - so bear with me. If the normal use case is for a certain platform (like mine is), and if the C is only needed for supporting multiple platforms, how about:

• features to state the wanted platform
• conditional code based on those

The idea is that it's far easier to strip away unneeded conditional lines than it is to unravel a generic parameter. If you are okay to see a PR of this approach, I can make one. Then we'd be able to discuss the pros/cons with two working solutions... If there's a reason this approach is a dead-end, please comment.

[lulf]

The ble_bas_peripheral has a comment:

/// ## Alternative
///
/// If you didn't require this to be generic for your application, you could statically spawn this with i.e.
///
/// #[embassy_executor::task]
/// async fn ble_task(mut runner: Runner<'static, SoftdeviceController<'static>>) {
///     runner.run().await;
/// }
///
/// spawner.must_spawn(ble_task(runner));

I am only targeting ESP32, so don't need the C generics (I assume they are there to have the same code support many platforms).

Yes, it makes ensuring the examples work a little easier for us.

1. How should I code the "alternative"?

Every place in trouble code using spawner is in the main(). But I cannot place the line 104 to main since it uses runner - and runner is direved within run() here.

I think the easiest is if you just copy everything from the example into your main.rs, then add a

typedef Controller = ExternalController<BleConnector, 20>;

Then replace all instances of fn foo<C: Controller>(bar: C) with foo(bar: Controller)

I can surely get this working one way or the other, but would like to hear how you would change the code for the alternative approach.

2. How about... not needing the generics?

This is a suggestion from a newcomer - so bear with me. If the normal use case is for a certain platform (like mine is), and if the C is only needed for supporting multiple platforms, how about:

* features to state the wanted platform

* conditional code based on those

The idea is that it's far easier to strip away unneeded conditional lines than it is to unravel a generic parameter. If you are okay to see a PR of this approach, I can make one. Then we'd be able to discuss the pros/cons with two working solutions... If there's a reason this approach is a dead-end, please comment.

I would instead maybe keep a minimal example that's per platform that does not use examples/apps, that can show how the app works without. As long as it's a simple minimal example (just an advertising beacon for instance), then I think that's an OK compromise for maintainability.

I'm against using features for this, because it brings a lot of problems wrt. target architecture etc. as well.

[jamessizeland]

I agree, this is the way I've done it for an easily swappable application (I use a very similar architecture on a private esp project)

https://github.com/jamessizeland/microbit-ble-gamepad/blob/main/src%2Fble%2Fmod.rs

So I can define the platform specific types in one place.