Implementing a new Gpio Controller

Archive
1

I know this is not a “Windows 10 IoT” forum, but I figured there were enough like minded people that read these posts that it might be a good place to bring something up.

I was looking at one of the samples for the Raspberry Pi 2 that talked to the MCP23008 chip. This is basically a chip that will give you 8 new GPIO ports over I2C. So, I went back to my .NET Micro Framework code where I implemented a driver for this chip. I decided the best way to try to learn the new framework was to convert my code over into the new “model”.

So, I see that a GpioController is probably want I want to create. I would follow the same basic implementation that is provided in the core framework. However, its a bad model. There is no base abstraction or interface that I can have in common (IGpioController is internal). And then on top of that the GpioPin is also non-abstract and its interface is internal.

I’d like to create a GpioControler/GpioPin implementation that can be easily share and used. I can see A LOT of these types of things being created for different hardware devices (a new SPI device even).

So why would the necessary classes in something that is meant to be expanded on with new hardware have a “contract” that is so restrictive? Are we to the point of having to implement a new “Framework on top of Framework” layer. The good news is that the current Framework CAN be changed without breaking existing code/contracts … it just has to be better structured internally. But getting Microsoft to actually do that is a whole bigger issue.

Roy

2 Likes
2

This is a good point. I’ll bump it to the team to see what they have in mind.

That all said, the Gadgeteer code GHI is working on for Windows 10 perfectly abstracts stuff like this.

Pete

1 Like
3

@ Pete

Does the Windows 10 Core team plan to support Onewire?

Wolfgang

4

… and CAN? 8)

1 Like
5

Not sure on plans for future busses and protocols. There’s desire to support as much as possible, for sure.We can’t talk to future support yet, though.

On the plus side, GHI has experience with CAN modules (there used to be a Gadgeteer CAN module). It seems reasonable to think they could start that back up if there’s market for it, and port the drivers to Windows.

On the GpioController: currently, it’s optimized for companies implementing their own on-SOC GPIO. We want to do more with things like external/add-on GPIO, but as you found out, it’s not possible at the moment using the GpioController pattern as-is. I don’t want to promise or make predictions about the future, so I’ll leave it at that for now.

Pete

6

GPIO is a core feature of every chip I know; even FT232H has some. It would be [em]very[/em] nice to have it abstracted as interfaces. That, together with abstracted I2C and SPI, would really untie hands for developers to create many flexible derivatives. Take I2C, for example. NETMF has it, but it a) works only on specific hardware pins and b) it’s one of the most awkward C# thing I have ever used. Outcome? Gadgeteer has it’s own implementation, GHI has their own reimplementation, and, heck, even I have my own reimplementation! And all those implementations are totally incompatible, although doing exactly the same thing.

CAN would be nice to have, but I’ll probably survive without it, as it is not a very trivial thing to abstact, and, in any case, requires some external hardware. As far as I remember, neither MinnowBoard nor RPi2 has CAN controller on their dies, so CAN, with its tight timings, would probably require kernel-level implementation…

7

Agreed. What we’re looking at out there right now is v1.0 of our GPIO approach. We’re getting a LOT of feedback from makers, industry, etc. on things we can/should do differently. Making things more extensible is a big part of that feedback.

Pete

2 Likes