I was just looking at the source code and noticed something with the PWM methods.
In Main\GadgeteerCore\Gadgeteer41\Interfaces\PWMOutput.cs, there are two methods:
- Set(int frequency, byte dutyCycle)
- SetPulse(uint period_ns, uint highTime_ns)
XMLDoc comments for SetPulse describe: "signal in nano seconds"
In Main\GadgeteerCore\Gadgeteer42\Interfaces\PWMOutput.cs, there are two methods:
- Set(int frequency, double dutyCycle)
- Set(uint period_us, uint highTime_us)
XMLDoc comments for the second overload describes: "signal in microseconds"
Now I've got a few questions:
- will the precision be decreased?
- will 4.2 be API compatible with 4.1?
- when doing math in the Set-statement without casting the right type, the wrong overload could be taken. (not really a question)
Apr 18, 2012 at 12:58 AM
Thank you for this excellent catch. It turns out that we had designed the NETMF 4.2 Gadgeteer API against the NETMF 4.2 RTM version which just supported microseconds, so we changed the API thinking it was good to be in line with NETMF 4.2. However,
the NETMF folks released a QFE1 patch which
added back nanosecond support. So we should have picked this up and used it. I have now made a change which will be released with 2.42.600 which effectively moves the API back to the NETMF 4.1 API, so they will be compatible*.
* in general, we don't retain compatibility between NETMF versions, though we DO retain compatibility WITHIN a NETMF version - so anything based on NETMF 4.1 and 2.41.100 (the first release) still works under 2.42.600 (which maintains backwards
compatibility with NETMF 4.1) and will continue to work with future versions. Adding a new NETMF version gives us a chance to refactor the API slightly to take advantage of any new NETMF features (e.g. PWM!) and fix any API awkwardness that
made it hard to support certain hardware (e.g. see the LCD changes in
http://gadgeteer.codeplex.com/workitem/472 ) - but obviously we dont make any unnecessary changes since it makes it easier to forward port code.