RLP via emBlocks

Finally, I’m ready to start optimize my project by using RLP.

I’ve downloaded Simon’s ‘RLP in depth’ tutorial as well as emBlocks template, and I’ve found it’s great entry point!

And rigth after I’ve played with simply hello-world function there is a lot of question appears.

  1. Where to find and how to include in my project some standard libs, for example for math operations, trigonometry and so on?

  2. If I understand correct there is a 23 MB of RAM used for RLP on Raptor board. So can I allocate some of them as a persistent storage to store some data between RLP procedure calls? I assume that I just need to know adress of the free RAM space and use pointer to write-read?

  3. What really happens providing an managed array to RLP procedure? Is this array is copyed to RLP RAM and then back to managed memory, or is just a pointer to managed memory is used in native code?

  4. Is it possible to access managed ram from RLP at all? And if yes - is it possible to lock some object to prevent its moving while CG performs RAM defragmentation?

Include in linker settings under project options. Check the picture.

I think so, yes.

I thinks it’s a pointer, otherwise two-way changes wouldn’t work…

First part — yes, but you must have a pointer, which NETMF doesn’t provide :slight_smile: . Second part — probably no :slight_smile:

1 Like

A while back I had the idea of using LargeArray (used by Bitmap) as a shared memory block.
Since LargeArray is not subject to Garbage collection, it should never move.

My 2nd idea was to start a thread, get a managed pointer to the array (unsafe code). Make a lock on the pointer, call a RPL method to hand over the pointer to RPL, and then do a Thread.Sleep(-1).
By this the array should be locked in memory position into infinity (and beyond).
But since managed pointers are not officially supported by NETMF (even if they work), the lock statement might have no effect, and the array might still be moved by GC.

1 Like

In the documentation you can read:

Means: any int, bool, float, … is passed by value, means it is acopy in RLP.
Array are passed by reference, like a pointer.
Modifying the array in RLP also modifies it on managed side.

Thanks,

Simon, could you please elaborate #1 a bit?
I see a lot of .h files on different folders inside EmBlocks\share folder.
After I’ve included “tgmath.h” header in my source file and trying to calculate sin(1) I’ve got following warning:
warning: implicit declaration of function ‘csinl’ [-Wimplicit-function-declaration]
Suppose this is because I should link some library using project settings. But how can I know where is this files?

And also have a question:
5. How the board reboots? Is there a power interrupt happens or this is just a CPU feature? When the board reboots by watchdog is there a chance that RAM will preserve its data?

I’m not sure, but it looks like some standard libraries. They can be added from project options, too. Check the picture.

Have no idea, but I wouldn’t rely on it anyway…

@ Sergey Bokhantsev - Simon and Reinhard are right, I just have a few things to add.

For allocating memory, you can also look into the malloc and free functions we provide inside RLP.h.

For the managed array passing, we currently pass you a pointer to the underlying array the NETMF uses. I would not rely on this fact though as we may change the implementation in the future. All that we guarantee is that you get an array that will be reflected back on the managed side.

Since you are running in native code and have exclusive control of the board in RLP, you can theoretically do anything that we can. But that is not documented or supported so it can be very easy to break something in a very subtle way. If changing how NETMF behaviors is your goal, you might be better served by looking into compiling your own firmware.

Thanks John,
so malloc function takes care about right location for the requested data. And I believe it is works with respect with other RLP infrastructure. For example if I will load first .elf then call to malloc, then load second .elf then everything will be ok?

The question about array passing is just related to performance. I need to parse a 20kb array and if this managed array will be copied to unmanaged memory and then copied back then I should design my function to use only unmanaged array. If there is no any copying (at least current 4.3.x version) then I may use managed array without significant performance weak.

@ Sergey Bokhantsev - The malloc in RLP.h will take memory from the NETMF heap. If you want to use the ~23MB we set aside from RLP, that is up to you to manage. We do not provide any malloc for that as it is usually used to hold globals and functions. If you do work with that memory you’ll need to be careful not to overwrite any data. When you load a second ELF file you have to specify in the linker settings for that file exactly where you want it to go since the first file already used the default location.

When passing an array, there is no copying of data. You get access to the underlying pointer NETMF uses. https://www.ghielectronics.com/docs/50/rlp can help you as well. There is a small cost involved in marshaling the parameters from C# to the native side, though.

@ Simon from Vilnius - this issue is gone now.
I’ve installed latest emBlocks version 2.3 and also have noticed that tgmath.h file includes complex.h file. And all the functions declared in complex.h file are works.
I.e. I should use ccos() and csin() instead of cos() and sin().

@ John - understand, this is my mistake. I thought that NETMF is responsible for native code allocation. But this is my task to set right place while linking.

What behavior is for the static variables in RLP?

;

void Foo(void **args)
{
    arr[0] = 1;
}

As the arr is static, will its values remain the same between calls to Foo() from managed side?

And where this static array will be located - on unmanaged or managed memory?

It will be located in unmanaged, RLP, memory. Not sure about retaining variable content, but I think it should work.

Ok, other interesting thing is where this array will be located.

If they will be located just after the .elf code, then we must take into account such static variable sizes. To prevent overlapping when loading second .elf.

If they will be located somewhere in dedicated for such variables area, then we may be restricted in their maximal size…

Check your .map file. It shows where your variables go.