Is posible to share a portion of memory betwen managed side and native side ? If so there is no need to pass arguments and everything could go on this shared buffer.
You can’t since in managed world the location of a resource in memory changes. The pointers in native side would get obsolete.
Somehow, GHI manage to get BBRam blocks fixed in some region, so I think it has to be some way to do that. There is also a way to allocate memory from the native side from the managed pool.
Not possible since objects on managed side can be moved by GC. There maybe a way on larger devices like EMX where there is a thing called “CustomHeap”.
[quote]Could you try the same test, but wrap the function calls in an unsafe {} block? You will need to go into the project preferences to allow unsafe code to compile and run it.
[/quote]
I don’t think it will change. unsafe is not supported by NETMF anyways.
I was thinking about the same thing but didn’t have time to try it.
You can write to the RLP memory region directly. But you have to change the linker script so you don’t use the same memory for your native code. For example, reserve the last 10KB in RLP region for your data.
You can do this to write. It should take less than 500 microseconds.
GHIElectronics.NETMF.Hardware.LowLevel.AddressSpace.Write(rlp memory on EMX)
Oh yes, I forgot about this one! Nice job GHI 
Mike-
It’s undocumented, but it is supported. It probably won’t make a difference anyway as you say, but I was just curious.
@ Mike: with…
you mean, change the following length?
MEMORY
{
SDRAM (wx) : ORIGIN = 0xA0F00000, LENGTH = 0x000FFFFC
}
So the compiler will not use it?
BTW: I asume that the length is specified in bytes?
Yes or you can dynamically allocate it from managed heap too.
[quote]Invoke() in 339 micro seconds
Invoke(int) in 4709 micro seconds
InvokeEx(int[]) in 2202 micro seconds
InvokeEx(int[], byte[]) in 3405 micro seconds
Invoke(byte[], byte[]) in 4113 micro seconds
So passing no arguments is fast.
general array is the next best option.
We can optimize RLP in future but this requires major changes on invoking and passing arguments…[/quote]
This is a major problem to me.
My app needs to send multiple ASCII commands to 6 stepper motor controllers over UART every 20ms. These involve converting many int (or float) parameters to ASCII.
A simple int.ToString() + UTF8Encoding.UTF8.GetBytes() in managed code takes more than one millisec on USBizi, so I’ve looked into RLP the last 2 days. I thought RLP might help me to build the ASCII byte array pretty fast (eg itoa() in c).
Sure RLP can do that much faster, but at around 2-3 millisec for a function call with parameters I’m at an dead end.
The options I see:
- switch to ChipworkX and do it all in managed code. If ChipworkX is 6x faster, that could work.
- use RLP, but instead of designing small functions, I would need to do the whole serial communication in RLP so it pays off (since my app does pretty little besides adjusting those motors, this is like coding the major part of the app in RLP
) - hope GHI can really optimize RLP for the next release
)
@ GHI: do you think you can greatly speed up RLP? When?
Personally, the 339 micro seconds for Invoke without parameters also seems quite high to me.
I just found this thread on the Netduino forum. Also sounds interesting.
[url]A different approach to speeding up managed code - General Discussion - Netduino Forums
Regards
Mark
[quote]@ GHI: do you think you can greatly speed up RLP? When?
[/quote]
In future, not soon. RLP has to change a lot to optimize this.
[quote]Personally, the 339 micro seconds for Invoke without parameters also seems quite high to me.
[/quote]
Calling native code form managed requires a lot of work. It is not a simple straight call.
RLP is good for processing more data than one time calculation. I mean if something takes 100 ms to do in managed code. Then it can maybe done in 10 ms or less in native code. So the overhead is not that significant anymore.
I agree - I see many places where RLP is extremely useful as it is.
Still, RLP seems to be a lot slower than calling a simple .NET method, which in the end, probably is just native code. So it seems RLP is a lot slower than .NET Interop.
Is there any way to compile an assembly for .NET Interop on the FEZ?
That’s probably what you do for those GHI assemblies right?
No, it should be the same. RLP uses interops internally…
In my test the bitmap.line was also faster then the rlp line algo written in assembly.