The first thing I ran into was that the .NET Threading timer is limited to 1ms. Even an empty Main() loop is only trucking at surprisingly slow 36kHz or so.
Example:
I need a 10kHz interrupt that is guaranteed atomic.
In C/ASM based systems you access registers directly and construct an atomic interrupt service routine. How is that done with .NET micro?
I didn’t see any API examples showing how to configure ARM interrupt handlers in C#, but I confess I have not dug very deep yet. Maybe its in the docs if someone can point out a link?
@ Jockey4her - What you are describing does not fall into the domain of .NETMF. Keep in mind that .NETMF runs a virtual machine which interprets each of the IL instructions one by one.
The benefits of .NETMF are clear, easy quick development, great for building systems that orchestrate various components of a solution etc. But what it is not built for is anything that requires high performance interaction with the outside world. That is better left to a daughter board. Of course somethings you can achieved using RLPLite, but high speed interrupt handling is probably not one of them especially if you do not want to interfere with the actual functioning of .NETMF.
My favorite solution to the problem is to use something like the DL40 for the “realtime”/high performance type stuff. I would use a .NETMF mainboard to drive the UI, accept user input etc. and then delegate the high-speed work to the DL40, let it count pulses, generate pulses, read sensors and aggregate the data and pass that back to the mainboard etc.
The primary reason to use a uC is for high speed hardware interactions. If you want to blame .NETMF you can try, but it sounds like the GHI tinyclr is real culprit.
One of the two already configures and services hardware interrupts for: SPI, UART, CAN, cameras, you name it. Timers are a basic feature of the device.
I’m looking at the sell sheet for the STM32F4x and it boasts 17 Timers, up to 168MHz. And .NETMF give 1kHz? And you suggest a daughter board. Come on.
If the OS can configure and service the other interrupts, it can certainly service and configure the timers.
A and you can add all that to the firmware or by using RLP.
NETMF, like everything else, has its advantages and disadvantages. It is perfect for high level not real time needs. But a $1 little micro can do a better job at real time, simple things.
Well that sounds at least encouraging that there may be some way out…if a bit frustrating also. Yet another installation and learning curve.
Gus, in quick searches, I didn’t spot any Cerb40 RLP setup or configuration docs. If there is such a thing… point me at them please.
The novelty of using .netmf is not lost on me. I expected it to wrap timers the way it does every other hardware feature. And why not? That’s all this RLP is going to do.
The concept of interrupt handler doesn’t exist in C# and NETMF.
Native interrupts can fire a C# callback event but these events are queued in a FIFO and are not real time. However such events are timestamped (with about 10µs jitter) before queuing.
When using NETMF, configure the hardware to do real time task and use the software to supervise the result and doing non real time tasks.
tinyclr = netmf. GHI only “own” the port of netmf onto a hardware platform, that takes the “porting kit” and makes the core functionality work on a particular chip.
Sure, the STM32F4 port of NETMF is open, and if you need more timers and want to delve into it, you can - whether the code is extensible in that way however might be something you would struggle with. However I’d still reiterate what a few others talk about here - NETMF is really targeted as the way to provide the detailed high level functions, and if your needs dictate more than the framework offers then you might need to “supplement” the processing by using cheap-as micros for simple tasks. The DL40 and the OpenDaisyLink project is intended to be a way to do this in a Gadgeteer way, but you could use a 30c ATTiny if it has the grunt to run your actions. And not trying to do anything more than show an alternate view here, but if you’ve ever opened up any complex electronic device lately you’ll typically see a plethora of chips tasked with doing very small subsets of the overall device’s function, so using a secondary processor is not an unusual action - heck, you only need to think about how a car dash works, the CAN bus allows each gauge or light on the dash to be it’s own stand-alone processor just doing it’s task.
I am going to start a new thread then. GHI documentation does not illustrate how to write an interrupt handler for the Cerb40 in RLP light or otherwise.
The RLP demo shows only generic c code. No hardware handling. Clearly we will need some includes (which are not covered) for accessing the various peripheral registers by name. That’s not shown either.
I have the feeling it will be a lengthy development process, since I have no native coding experience on this device, and no resources other than this forum.
@ Jockey4her - RLP is a way to load native code. Beyond that, the user needs to know the full details on how to handle their hardware. This is considered advanced but this community is never short when it comes to providing help.