Creating Native Extensions for the FEZ Hydra Firmware

I looked at the RC5 protocol.
It is based on the modultation of a 36kHz carrier.
The 36kHz signal can be done by sending 4 bits ‘1000’ for each cycle (25% duty cycle) with SPI configured à 144kHz.
A data 0 is done by transmitting 32 carrier cycles and 32 empty cycles or 256 SPI bits, : 100010001000…000000000000…
A data 1 is done by transmitting 32 empty cycles and 32 carrier cycles or 256 SPI bits, : 000000000000…100010001000…
Sending a 14 data bits command is done by 14 * 256 SPI bits or 448 bytes.
Just create a buffer with 0x00 and 0x88 bytes.

This must be repeated at a 114ms period. That can easily be done by a simple timer.

Should be tested now.

@ NicolasG - Yes you can use SPI combined with a PWM for modulation. But then you can only support pre-programmed protocols. If you want to make a universal learning remote control, then all you get as input are pulse timings. The easiest way to playback recorded timings is by using something like the OutputCompare class.

@ NicolasG - the link below has an example of what WouterH is referring to. It is the last sample on the page Sending Signal to Control a TV

NB: the sample is out of date but the principal stands

@ taylorza - Thank you, now I understand what you mean with OutputCompare.
I thought it was the simple hardware timer feature.

Are there advantages or disadvantages to creating Native Extensions vs. RLP. It appears that RLP is a bit easier to implement, but besides that are there limits one way or the other?

@ skeller - I am no expert, but I can offer a view from my current albeit limited experience in this area.

RLP/RLPLite is definitely easier to get up and running. With the added advantage, in my view anyway, that it is much easier to accept loading up a managed project that uses some RLP* than to expect someone to replace the firmware just to use your software.

However, there are certain clear advantages to using interop depending on what you need to do. For one, you can leverage the hardware and platform abstraction code that helps isolate your code from the physical hardware and simplifies some of the regisiter setup that you have to do to naively utilize some of the peripherals. Essentially, you integrate into the .NETMF as a 1st class citizen with all the native infrastructure available to your code.

With RLP/RLPLite you are responsible for unpacking your arguments from argument arrays while the Interop tooling with .NETMF provides functionality to generate native stubs that match your managed code interface, there are certain limitations with regard to the types that can be handled but RLP is no better in this regard. In the case of RLPLite you have no means to raise events back to the managed code, not support for installing interrupt vectors which can make like difficult with the AICs used in MCU like the AT91 used in the Hydra. I have not tried with RLPLite, but based on my experience with interrupts on the DL40, I believe this would be less of a hindrance with the Cortex NVICs.

My view, is that if you need basic native functionality then RLP/RLPLite is the way to go which is probably 99% of the cases. If you need deep integration into the firmware and what it has to offer then Interop is the option.

Of course RLP/RLPLite is only available from GHI, so if you needed RLP on other devices you would need to implement that capability or similar in Interop. RLPLite should be quite easy to implement, full RLP on the other hand will need far more effort and expertise.

From my view the biggest negative for Interop is that others will need to replace the firmware to use the functionality that you are offering. And if like me you are using free GCC to build the firmware then your entire system is impacted because GCC does not generate code that is as efficient in terms of both performance and size as the commercial tools used by GHI for example. While with RLP it is only that single aspect of the system that is complied with GCC.

There is a lot more I could say, but I will leave it at that for now :slight_smile:

3 Likes

@ taylorza - eekk, you call that limited experience - can’t wait to see an answer when you really get stuck in!!!

Good post - very informative.

@ taylora
Thanks for the explanation. I agree with Justin, if your limited experience got you this far I am looking forward to what you will be doing with experience!

So it seems for portability reasons RLP is the way to go. For an OEM application using native extensions is probably the way to go. Along those lines I am embarking on development of an application that is going to relay heavily on RS-485 and modbus. The TX enable/disable seems to be an issue that requires at the minimum RLP. Could not that issue be addressed with minor changes to the current .NETMF serial libraries? And if a person was adventurous a native implementation of MODBUS.

One nice feature that RLP supports is scheduled task that are guaranteed to run at specific intervals, allowing deterministic applications. Can something similar be done with native extensions?

Can the same basic steps for creating a custom firmware for the Hydra be applied to the ChipworkX or G120 modules? Would that break the Premium library support?

Any thoughts or suggestions would be appreciated. I might try creating my own firmware build over the holidays.

That totally depends on what you are doing. If you are using the CPU registers then portability will be quite limited due to the memory and register map variances across processors.

I do not know what the TX enable/disable issue is, but have you looked if the Register class can help here?

RLP most likely will rely on the .NETMF infrastructure to provide this scheduling, so there is no doubt that native interop can achieve the same thing RLP would not have any access exceeding what can be achieved with native interop extensions.

I do not have ChipworksX or the G120, but if you did load a custom firmware you would need to consider the following

  1. You would need to create a new port for the target MCU, GHI does not provide the code for the ports to the Premium hardware, this would be a significant undertaking.
  2. You would loose all the premium features from GHI
  3. I suspect that you might be locked out from restoring the premium firmware without asking GHI to do that for you

Gus and his team would need to confirm if the above is even possible, I am mostly just guessing based on what I have understood so far, there might be even more limitations.

Custom firmware on our premium (non open source) products is a bad idea, just use RLP if you need ot extend it. GHI spends months/years of work and thousands of dollars to give you a sold firmware with premium features. If that is not what you need then just pick any of the open source product and customize anyway you like, you still have RLPlite.

Still not sure and this is commercial application, contact GHI sales and we will happily step you through all options :slight_smile:

Gus and taylorza - Thanks for the help. I think the best course of action is as Gus has suggested to go with RLP. In the long run I think it will be easier to support. I also think there are some Premium features that I will be using on both of those modules.
As far as the RS-485 and the TX enable it appears that both the ChipworkX and G120 can handle it in hardware and the necessary pins are exposed. It should just require setting the appropriate registers. (Someone please correct me if I am wrong.)

Happy Holidays