Starting from jay proposition, I structured my code to create the Community namespace.
I found that release the whole code as jay did first can’t keep in sync with GHI open source code. Thus I decided to release only the difference to merge with NETMF4.3+GHI OSHW code.
The result is available on github: GitHub - NicolasG3/NETMF4.3_Community: NETMF 4.3 Community features and GCC compatibility
Some code was already released in CodeShare to compile NETMF 4.3 with GCC.
The “Community” directory contains all the code for Community namespace and the following features:
[title]Community.Hardware.QuadratureEncoder.dll[/title]
Quadrature encoder hardware driver with output compare and input capture capability. The HAL driver is provided to allow implementation for other platforms.
[title]Community.Hardware.SignalGenerator.dll[/title]
Software binary signal generator. Implemented at HAL level, this feature is platform independant and can be added to any solution.
[title]Community.Hardware.Settings.dll[/title]
Access to debug port settings (COM or USB), hardware serial and persistent user settings (internal Flash). HAL driver is provided for porting hardware serial to other platforms. Others features are platform independant.
[title]Community.System.dll[/title]
BitConverter class implementation.
Check the wiki for more info: Home · NicolasG3/NETMF4.3_Community Wiki · GitHub
6 Likes
@ NicolasG - Very nice. I like the approach you have taken with the code and that BitCoverter is going to come in handy!
Thanks.
It would be nice to test SignalGenerator on FEZHydra.
Just add a line to tinyclr.proj:
<Import Project="$(SPOCLIENT)\Community\Features\SignalGenerator.featureproj" />
Blinking a led should be OK as a first check.
All features are great! UserSettings is very welcome!
@ NicolasG - If I get a gap I will give it a try and let you know. I can’t promise when I will do it, but I will try as soon as possible.
@ taylorza: No hurry. I think I will have a FEZHydra to test it later.
@ Architect - And you can derive the class to expose strongly typed parameters.
@ NicolasG - I like the way you have implemented the SignalGenerator, I was wondering however what the max frequency is that you can achieve with that approach on the Cerb?
When I did the SignalGenerator implementation in the Hydra Firmware I found that the way the timer ticks are tracked in the HAL, to compensate for the timers only being 16bit, introduced too much overhead to be able to generate a clean 38kHz carrier required for IR signals for example.
I know the Cerb firmware actually cascades multiple timers to get around the timer counter limit so I expect that would work much better hence my interest in your implementation and the performance characteristics.
@ taylorza - Cerb can achieve more than 50KHz, the theorical max is about 75kHz.
This is not true if there is multiple signal generating at the same time: the limiting factor is the HAL completion queuing time that lead to a cycle of about 6.5µs on cerb.
This is the min time between two toggles on every signals and it is platform dependant.
There is also 2 cascaded timers (32bits+16bits) for sytem time on Cerb.
@ NicolasG - That sounds very good, I am very interested to see how this does on the Hydra.
I got an Hydra to test SignalGenerator.
I compiled NETMF4.3 for Hydra with SignalGenerator feature.
The cycle time is about 20µs to 25µs (not stable): this lead to 20kHz max. Not enough for IR remote.
On Cerb, the cycle time is mutch more stable at 6.6µs to 6.7µs
Digging into the native code, it’s clear that using a 16bits timer requires to process much more interrupts to compare to a 64bits completion time. There is an interrupt at each 16bits overflow until the real 64bits target is reached.
On Cerb, this is on each 32bits overflow…
@ NicolasG
Decided to try your version of the FW. Having some issue building it. Getting region overflowed issues. What is the version of your gcc tools, where did you get them and what parameters do you use with msbuild?
Nevermind.
Stupid typo in flavor parameter on my part.
You can also use the build result.
All the files are available in “Ready to use” directory.
Spoke to soon. Got MetaDataProcessor error while signing.
By the way I had to fix absolute path in one of the files. You have similar fixes in some of the files already but I guess you have missed that one.
HAL_GHI_OSHW_Hardware_LCDController.cpp
I didn’t see this error before because I got the include file in the NETMF PK V4.2!
Cool! What version of GCC are you using the last 4.6 from Launchpad?
https://launchpad.net/gcc-arm-embedded/4.6/4.6-2012-q4-update
Yes, this is the 4.6.2 from lauchpad.
Ok if anybody else will run into this.
Found my problem. When I install the PK I also install all the add-ons: Crypto, etc.
These are added to the build if installed, so I had to remove Crypto pack.