First draft for new ComponentInformation support #1965

pgrawehr · 2022-10-23T13:40:20Z

Concept for first part of #1962

All important classes (GpioDriver, GpiController, I2cDriver, SpiDriver etc.) now contain a method QueryComponentInformation that return an instance of ComponentInformation. This class represents a tree of the active drivers and/or bindings. Further extension will allow to provide possible drivers as well.

[Further extension: It is intended that later ComponentInformation can be provided to a factory that constructs a device instance from such an information tree. One problem there is however, how one would know what is available. Providing a class that knows all possible drivers is quite ugly, and even instantiating a driver without initializing it (e.g. just to find out it's capabilities or whether it would work) is currently not possible without relying on exceptions. Separating the constructor from the initialization could improve this. ]

Example

This code:

using Board b = Board.Create();
using ic2 = b.CreateOrGetI2cBus(1);
Console.WriteLine("Hardware detected: ");
Console.WriteLine(b.QueryComponentInformation(true));

Generates this output on a Raspberry Pi 4:

Hardware detected: 
{Iot.Device.Board.RaspberryPiBoard} Raspberry Pi
 └{Iot.Device.Board.ManagedGpioController} Managed GPIO Controller
  └{System.Device.Gpio.Drivers.RaspberryPi3Driver} Generic Raspberry Pi Wrapper driver
   └{System.Device.Gpio.Drivers.RaspberryPi3LinuxDriver} Raspberry Pi 4 Model B Rev 1.2 linux driver with 28 pins and an interrupt driver
    └{System.Device.Gpio.Drivers.LibGpiodDriver} Gpio Driver
 └{Iot.Device.Board.I2cBusManager} I2C Bus Manager, Bus number 1

Microsoft Reviewers: Open in CodeFlow

raffaeler · 2022-10-25T06:32:44Z

With reagards to the output, it would be certainly useful to have both the tree (as an object graph), but also a string to uniquely identify the 'Component'.
In a first scenario I may disergard entirely which board I am using, but I do need libgpiod under the hood.
In an opposite scenario, I really need the RPi4 and I have to make sure the correct board was selected.

Finally I would split the driver and the board information in two different levels of the tree, so that comparing the information would be easier.

pgrawehr · 2022-10-25T14:56:35Z

@raffaeler Looks like we have a similar understanding. Look at the code, I think it exactly has what you're asking for. Each component is currently identified by it's type name.

raffaeler

Sorry for not reading the code before, but I didn't have time.
Love the general structure. I added a couple of comments even if it is still very early for a deep review.
I am thinking whether or not it could be possible to go in much detail about the "capabilities" so that it is easier to take decisions based on that instead of a raw string with the board model.

src/System.Device.Gpio/System/Device/ComponentInformation.cs

raffaeler · 2022-10-25T16:22:07Z

src/System.Device.Gpio/System/Device/ComponentInformation.cs

+        private readonly List<ComponentInformation> _subComponents;
+
+        public ComponentInformation(object instance, string name)
+            : this(instance, name, string.Empty)


This is a record, why not using the primary ctor and optional parameters with a default value?

I prefer explicit overloads, but that's just syntax and can be adjustedat the end.

src/System.Device.Gpio/System/Device/ComponentInformation.cs

src/System.Device.Gpio/System/Device/IQueryComponentInformation.cs

Make interface IQueryComponentInformation internal for now (since not used for calling), make ComponentInformation read-only, remove argument from QueryComponentInformation.

Ellerbach · 2023-01-22T17:32:30Z

I like the idea. Now, in terms of implementation, that will require to add the IQueryComponentInformation and the implementation in all Boards and associated drivers, correct?

raffaeler · 2023-01-22T18:29:31Z

I like the idea. Now, in terms of implementation, that will require to add the IQueryComponentInformation and the implementation in all Boards and associated drivers, correct?

Given that the abstract driver class implements the interface, the answer is yes.
But there is more. If I understood correctly, in your upcoming FTH binding, you should also have the opportunity to provide the IQueryComponentInformation there.

pgrawehr · 2023-01-22T21:12:53Z

I like the idea. Now, in terms of implementation, that will require to add the IQueryComponentInformation and the implementation in all Boards and associated drivers, correct?

Given that the abstract driver class implements the interface, the answer is yes. But there is more. If I understood correctly, in your upcoming FTH binding, you should also have the opportunity to provide the IQueryComponentInformation there.

I'm actually not sure yet we really need the interface itself (just yet). We will have the method in several abstract base classes, but since we don't need something like a "list of all objects which can be queried" the interface itself is probably not needed. But this won't change the overall concept.

raffaeler · 2023-01-23T21:32:02Z

@pgrawehr Not sure to understand what exactly is your current design.
Could you please describe it? (maybe the issue is a better place)

pgrawehr · 2023-01-24T05:59:32Z

I'm trying out some refactoring, to be able to check the design for the next stage. This will be separated from this PR.

pgrawehr · 2023-02-04T14:39:26Z

So, I think the concept should hold now. This is now waiting for PR #2019 to avoid conflicts.
Also, I haven't really done much testing yet.

src/System.Device.Gpio/System/Device/Pwm/PwmChannel.cs

krwq · 2023-02-23T17:11:50Z

src/System.Device.Gpio/System/Device/Gpio/Drivers/RaspberryPi3LinuxDriver.cs

+        }
+
+        return ci;
+    }


Possibly
string ToString() { return $"{{ {string.Join(Subcomponents.Select(...))} }}"; }

string ToString() { return $"{{ {_interruptDriver}, ... }}"; }

In case there's a loop in it

And keep separate list in ManagedGpioController, so we don't need to expose the list.

…rmation

tools/ArduinoCsCompiler/tests/GarbageCollectorTests.cs

tools/ArduinoCsCompiler/tests/FirmataIlExecutorTests.cs

krwq · 2023-02-27T12:03:26Z

src/System.Device.Gpio/System/Device/I2c/I2cDevice.cs

+    /// This event is raised when <see cref="QueryComponentInformation"/> of the base class is called. This is can be used for bindings
+    /// to intercept that call on their own I2C device, so they can add additional information
+    /// </summary>
+    public event Action<ComponentInformation>? OnQueryComponentInformation;


This should be just callback rather than event especially given 1:1 relationship with device. Why not Func<ComponentInformation> instead?

ok my question in the end got answered by the code below. First sentence is still valid though

btw I like this approach much more than inheritance initially proposed but I'll suggest to do only printing in the initial PR and in the following one we can focus on the approach

So you mean to remove this for now?

krwq · 2023-02-27T12:10:15Z

src/devices/Pca9685/Pca9685PwmChannel.cs

+        /// <inheritdoc />
+        public override ComponentInformation QueryComponentInformation()
+        {
+            return new ComponentInformation(this, "Pca9685 PWM Channel");


I'll suggest to move this to base class and just use type name given spaces do not add virtually any new information

You are right, however this merely serves as a place holder and, once the design is finalized, all the components should be reviewed and additional information added, if useful.

src/System.Device.Gpio/System/Device/ComponentInformation.cs

pgrawehr · 2023-03-25T16:43:38Z

I had a look at ExpandoObject and DynamicObject but neither of them are really helpful here. They allow a lot of dynamic type construction, but have several drawbacks, too:

For netstandard, a reference to "Microsoft.CSharp" is necessary, which doesn't seem very lightweight
QueryComponentInformation would need to return dynamic, which is an untyped thing, leaving the caller confused about what he can do with the object. We don't want runtime exceptions trying to get debug information.
One can define new properties on ExpandoObject, but not methods. It doesn't seem possible to override ToString() as well, which we need. ExpandoObject is sealed, so deriving from it is also not possible. DynamicObject allows deriving, but still requires users to use dynamic all over the place.
In the next release, we want to be able to construct a driver tree from an user-defined ComponentInformation tree. We can't expect people to construct correct instances of ExpandoObject. This would also be a problem for us, as eventually all bindings would create ComponentInformation instances, and we want them to be (at least somewhat) comparable and consistent.

raffaeler · 2023-03-30T08:18:54Z

For netstandard, a reference to "Microsoft.CSharp" is necessary, which doesn't seem very lightweight

This means just .NET Framework and Mono. I won't be too worried for those.

QueryComponentInformation would need to return dynamic, which is an untyped thing, leaving the caller confused about what he can do with the object. We don't want runtime exceptions trying to get debug information.

That's by design, if we want to get rid of a type.

One can define new properties on ExpandoObject, but not methods. It doesn't seem possible to override ToString() as well, which we need. ExpandoObject is sealed, so deriving from it is also not possible. DynamicObject allows deriving, but still requires users to use dynamic all over the place.

You are right, but this can be resolved with some extension methods.

In the next release, we want to be able to construct a driver tree from an user-defined ComponentInformation tree. We can't expect people to construct correct instances of ExpandoObject. This would also be a problem for us, as eventually all bindings would create ComponentInformation instances, and we want them to be (at least somewhat) comparable and consistent.

Let's discuss this. I understand @krwq being worried to introduce a new type which is basically everywhere.
The alternative solution we are discussing here is to minimize the impact by using dynamic + ExpandoObject and then a class defining the extension methods needed to make the dev experience better.
I am not completely against ComponentInformation, but the evaluation should be a fair comparison between the two solutions.

raffaeler · 2023-03-30T09:48:07Z

BTW, even if I prefer the extension methods approach, this code using Expand includes the support to methods:

dynamic GetData()
{
    dynamic d = new ExpandoObject();
    d.Name = "abc";
    d.Count = 10;
    d.ToString = (Func<string>)(() =>
    {
        return $"Name:{d.Name} Count:{d.Count}";
    });
    return d;
}

dynamic x = GetData();
Console.WriteLine(x.ToString());
// output: 
// Name:abc Count:10

src/System.Device.Gpio/System/Device/ComponentInformation.cs

…rmation

joperezr · 2023-04-06T15:47:34Z

@krwq looks like @pgrawehr has addressed your comments and this is ready to go. Can you take one final look and merge this one?

Ellerbach

Looks good, if you can add the rest of the DeviceInformation property on the FT devices, it would be perfect!

Ellerbach · 2023-05-11T15:57:51Z

src/devices/Ft232H/Ft232HI2cBus.cs

+        {
+            var self = new ComponentInformation(this, "Ftx232HI2c I2C Bus driver");
+            self.Properties["BusNo"] = "0";
+            foreach (var device in _usedAddresses)


Can you add all the properties of the DeviceInformation ?

Ellerbach · 2023-05-11T15:58:22Z

src/devices/Ft232H/Ft232HDevice.cs

+        /// <inheritdoc />
+        public override ComponentInformation QueryComponentInformation()
+        {
+            return base.QueryComponentInformation() with { Description = "Ftx232 Device" };


Can you add all the properties of the DeviceInformation ?

Ellerbach · 2023-05-11T15:58:33Z

src/devices/Ft4222/Ft4222I2cBus.cs

+            self.Properties["BusNo"] = "0";
+            self.Properties["Description"] = DeviceInformation.Description;
+            self.Properties["SerialNumber"] = DeviceInformation.SerialNumber;
+            foreach (var device in _usedAddresses)


Can you add all the properties of the DeviceInformation ?

…rmation # Conflicts: # src/devices/Board/RaspberryPiBoard.cs # src/devices/Board/samples/Program.cs

pgrawehr added api-suggestion Early API idea and discussion, it is NOT ready for implementation area-System.Device.Gpio Contains types for using general-purpose I/O (GPIO) pins labels Oct 23, 2022

raffaeler reviewed Oct 25, 2022

View reviewed changes

krwq self-assigned this Oct 27, 2022

joperezr reviewed Oct 27, 2022

View reviewed changes

src/System.Device.Gpio/System/Device/ComponentInformation.cs Outdated Show resolved Hide resolved

joperezr reviewed Oct 27, 2022

View reviewed changes

src/System.Device.Gpio/System/Device/ComponentInformation.cs Show resolved Hide resolved

joperezr reviewed Oct 27, 2022

View reviewed changes

src/System.Device.Gpio/System/Device/IQueryComponentInformation.cs Outdated Show resolved Hide resolved

pgrawehr force-pushed the ComponentInformation branch from 535755c to 5a6e024 Compare October 29, 2022 17:47

joperezr added this to the vNext milestone Dec 1, 2022

joperezr added the Priority:0 Work that we can't release without label Dec 8, 2022

krwq removed this from the vNext milestone Dec 15, 2022

krwq added Priority:1 Work that is critical for the release, but we could probably ship without and removed Priority:0 Work that we can't release without labels Dec 15, 2022

pgrawehr added 2 commits January 22, 2023 12:47

First draft for new ComponentInformation support

0ecf515

Update according discussion

bbef47b

Make interface IQueryComponentInformation internal for now (since not used for calling), make ComponentInformation read-only, remove argument from QueryComponentInformation.

pgrawehr force-pushed the ComponentInformation branch from 5a6e024 to bbef47b Compare January 22, 2023 13:33

pgrawehr force-pushed the ComponentInformation branch from 10f6c8a to bbef47b Compare January 25, 2023 19:30

pgrawehr added 5 commits January 25, 2023 21:09

Support SPI busses in ComponentInformation

7c13239

Add SPI busses

963ed24

Implementation of QueryComponentInformation for all core object types

55ea0e9

More devices completed

6d34949

Added Tca9548A with callback (to be extended)

c53f09f

krwq reviewed Feb 23, 2023

View reviewed changes

src/System.Device.Gpio/System/Device/Pwm/PwmChannel.cs Outdated Show resolved Hide resolved

krwq reviewed Feb 23, 2023

View reviewed changes

pgrawehr added 6 commits February 24, 2023 20:06

Remove IQueryComponentInformation. We don't need it for now

848a65d

Remove ComponentState.cs, as usage is still unclear

c49eb60

Prevent infinite recursion while iterating the tree

2131902

In case there's a loop in it

Provide OpenPins list from base class

3319be4

And keep separate list in ManagedGpioController, so we don't need to expose the list.

Merge remote-tracking branch 'remotes/dotnet/main' into ComponentInfo…

a08daf2

…rmation

Fix baseline compatibility errors

adf8f33

krwq reviewed Feb 27, 2023

View reviewed changes

tools/ArduinoCsCompiler/tests/GarbageCollectorTests.cs Show resolved Hide resolved

krwq reviewed Feb 27, 2023

View reviewed changes

tools/ArduinoCsCompiler/tests/FirmataIlExecutorTests.cs Show resolved Hide resolved

krwq reviewed Feb 27, 2023

View reviewed changes

krwq reviewed Mar 23, 2023

View reviewed changes

src/System.Device.Gpio/System/Device/ComponentInformation.cs Show resolved Hide resolved

Event will eventually be added later

7fb47fc

krwq reviewed Mar 30, 2023

View reviewed changes

src/System.Device.Gpio/System/Device/ComponentInformation.cs Show resolved Hide resolved

pgrawehr added 2 commits April 2, 2023 13:41

Add comment that this API is subject to change

f10bff4

Merge remote-tracking branch 'remotes/dotnet/main' into ComponentInfo…

6281352

…rmation

pgrawehr requested a review from krwq April 3, 2023 17:00

joperezr added this to the v3.0.0 milestone Apr 13, 2023

raffaeler approved these changes May 11, 2023

View reviewed changes

Ellerbach approved these changes May 11, 2023

View reviewed changes

pgrawehr added 3 commits May 14, 2023 16:13

Merge remote-tracking branch 'remotes/dotnet/main' into ComponentInfo…

fa80f1f

…rmation # Conflicts: # src/devices/Board/RaspberryPiBoard.cs # src/devices/Board/samples/Program.cs

Add ComponentInformation specifics for FtDevice

32e3cd5

Fix new linter error

508e0ad

pgrawehr merged commit 2460cd3 into dotnet:main May 18, 2023

github-actions bot locked and limited conversation to collaborators Dec 8, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

First draft for new ComponentInformation support #1965

First draft for new ComponentInformation support #1965

pgrawehr commented Oct 23, 2022 •

edited

Loading

raffaeler commented Oct 25, 2022

pgrawehr commented Oct 25, 2022

raffaeler left a comment •

edited

Loading

raffaeler Oct 25, 2022

pgrawehr Oct 26, 2022

Ellerbach commented Jan 22, 2023

raffaeler commented Jan 22, 2023

pgrawehr commented Jan 22, 2023

raffaeler commented Jan 23, 2023

pgrawehr commented Jan 24, 2023

pgrawehr commented Feb 4, 2023

krwq Feb 23, 2023

krwq Feb 27, 2023

krwq Feb 27, 2023 •

edited

Loading

krwq Feb 27, 2023

pgrawehr Feb 27, 2023

krwq Feb 27, 2023

pgrawehr Feb 27, 2023

pgrawehr commented Mar 25, 2023

raffaeler commented Mar 30, 2023

raffaeler commented Mar 30, 2023

joperezr commented Apr 6, 2023

Ellerbach left a comment

Ellerbach May 11, 2023

Ellerbach May 11, 2023

Ellerbach May 11, 2023

First draft for new ComponentInformation support #1965

First draft for new ComponentInformation support #1965

Conversation

pgrawehr commented Oct 23, 2022 • edited Loading

Example

Microsoft Reviewers: Open in CodeFlow

raffaeler commented Oct 25, 2022

pgrawehr commented Oct 25, 2022

raffaeler left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Ellerbach commented Jan 22, 2023

raffaeler commented Jan 22, 2023

pgrawehr commented Jan 22, 2023

raffaeler commented Jan 23, 2023

pgrawehr commented Jan 24, 2023

pgrawehr commented Feb 4, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

krwq Feb 27, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pgrawehr commented Mar 25, 2023

raffaeler commented Mar 30, 2023

raffaeler commented Mar 30, 2023

joperezr commented Apr 6, 2023

Ellerbach left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pgrawehr commented Oct 23, 2022 •

edited

Loading

raffaeler left a comment •

edited

Loading

krwq Feb 27, 2023 •

edited

Loading