search

sharpbrick / powered-up

.NET implementation of the LEGO PoweredUp Protocol
MIT License
98 stars 19 forks source link

Add Options based configuration into CLI and Examples for BlueGiga #155

Closed tthiery closed 3 years ago

tthiery commented 3 years ago

BlueGiga in focus because currently the only one needing configuration

See details in #154

rickjansen-dev commented 3 years ago

An options object would be useful for BlueZ implementation too. Mainly to specify a specific bluetooth adapter (eg hci0) instead of simply using the first available one. Kind of optional since multiple available bluetooth adapters seems like a bit of a edge case.

Maybe best to open a separate issue to complete if this one is done?

tthiery commented 3 years ago

Let us focus on finishing bluez first. We see which delivery beat which and then we adjust :)

dkurok commented 3 years ago

I've tested today with BlueGiga on a RaspberryPi with the actual Master-branch - works like a charme! The BleuGiga-adapter gets recognized on the Pi without any additional installation and is just a SerialPort:

./SharpBrick.PoweredUp.Examples --usebluegiga /dev/ttyACM0

..and it works. Also with two Hubs in parallel (ExampleTwoHubsMotorControl) 😄 Surley I had to remove the dependency on the SharpBrick.PoweredUp.WinRT from SharpBrick.PoweredUp.Examples because WinRT cannot build for linux-arm target. Also instead of net5.0-windows10.0.19041.0 just only use net5.0 in the TargetFramework for Examples and BleuGigaBLE. And some small changes in BaseExample.cs(comment line 97 which is calling AddWinRTBluetooth() and Program.cs (just for making sure the options are given over to InitHostandDiscoveryasync(); line 82 instead of 80) publish for Raspberry Pi: 

cd GitHub\sharpbrick\powered-up\examples\SharpBrick.PoweredUp.Examples
dotnet publish -r linux-arm -o bin\\linux-arm\\publish --no-self-contained

Why do I mention it here? Because we need to think about how to separte the different BLE-implementations into different independent Nuget-packages later, so it gets easy to build for differnt platforms. With Bluez-implementation in near future it will be an additional candidat which probably will not compile for windows-target. So it should be in mind also here...

tthiery commented 3 years ago

Oh that is nice. Create a PR updating the README

second: Yes, I agree. We need to decouple the dependency to the bluetooth stacks in the tools etc. There is a "plugin"-like concept called AssemblyLoadContext which can load assemblies at runtime. With a small generic helper, all the CLI, Examples, TestScript Runner can dynamically load an adapter. The only thing I am not sure is, does it work with the -windows target when called from a command line part. To be tested. In doubt, we can multi-target.

dkurok commented 3 years ago

I've tested on a Raspberry Pi 4. I will do another test on a Raspi 3 and also on an Ubuntu 20.0 LTS (PC-based). As soon as I have finished these tests, I will update the README. Shall I go for an own file BlueGigaReadme.md for bringing all the information for BlueGiga centralized or put it into the big README? It's more a question of wanted style from your side.

tthiery commented 3 years ago

That is indeed a good idea. Put it somewhere reasonable in the docs folder and link it from the main readme. That declutters the project start page.