PWM examples with TinyClr 0.3.0

NETMF & Gadgeteer
1

Pwm have changed in new version of TinyClr. I can’t succeed to make it working. Someone has an code example ?

2

@ Bauland - At the bottom of the notes section for the 0.3.0 release notes on https://www.ghielectronics.com/docs/350/tinyclr-os you’ll see code examples for the new APIs in TinyCLR 0.3.0: Examples.cs · GitHub

After creating a pin and controller the usage is the same as before.

1 Like
3

@ John - Sorry John, I was so excited to test new version that I don’t have seen link with examples :wall: :wall: :wall:

For Pwm, is it possible for next version to access pin and controller with same object ?

For example:


var controller = PwmController.FromId(G30.PwmPin.Controller1.PA8.Controller); 
var pin = controller.OpenPin(G30.PwmPin.Controller1.PA8.pin);

So Module could be declare as this:


Tunes tunes=new Tunes(G30.PwmPin.Controller1.PA8)

So Tunes class can access controller and open pin with just one param.

It could be useful, to create module which needs only to pass which pin is connected. (Who said to me porting gadgeteer to TinyClr ? ) :wink:

1 Like
4

I guess the question is, how to determine the controller of a specific pin programmatically?

5

@ Gus - Yes it is exactly what I mean.

6

@ Bauland - One potential issue with that is to be able to pass it somewhere as a whole, it needs to be an instance of something. We could of course make something like “G30.PwmPin.PA8” be an instance of a new “class PwmPinDefinition { public string ControllerId {get;} public int Pin {get;}}” but then the pins class would have an allocation for every PWM pin and would grow in size. Right now, everything in GHI.TC.Pins is a const so it gets inlined at the use-site.

If we invert the relationship but keep things const, we could have inside G30.PwmPin another static class for each pin “public static class A8 { public const int Pin = 0; public const string Controller = “…”;}” but then you lose the relationship between pins and controllers and it’ll be harder to know which allocated controller object you can use.

In your example, if we changed it to be const and not static like discussed above, when you keep Controller1, have A8 under it, and have a pin and controller field in A8, Controller is used twice so it’s a bit redundant looking and then creating the controller object has A8 in the statement so some may think the controller is only for A8 when in fact it is for multiple pins on that controller.

We do have some ideas on how this can be improved in the future as part of a larger overhaul of the pins library and what it does, so stay tuned for that. While not ideal at the moment, the way it’s organized right now maps clearly to the model the hardware exposes and how the API works. Keep in mind that the UWP API is based around providers. So today in TinyCLR you could create your own PWM controller and register it with the system such that you can use a GHI.TC.Devices.PwmPin object that is backed by your controller instead of the hardware that may delegate over I2C to an external PWM controller chip. You create a controller based on its ID and then you can open the various pins exposed by that controller.

7

I know that it must be difficult to implement. But I know you love challenge at GHI, so yes, I’m staying tuned ! :whistle: