Main Site Documentation

Emx-rlp


#1

Hello,

RLP is still in the “Planned features” in this beta. Do you have any clue about the achievment date of this feature ?


#2

We are about a month away from adding RLP


#3

Thank you !

Would you please confirm that I did understand its purpose : will it allow me to include for example C dll’s whose functions can be called via classical DllImport ?


#4

AFAIK you can use C or Assembly, but these are not the “regular” DLLs that you may have on the desktop computer. You will need to create a binary or ELF with the C or Assembler functions that you need.

You will select a toolchain (GNU ARM, Keil, Crossworks etc.) that supports the NXP micro (LPC2478) and the linker options set to use the correct RLP region of the memory map.

HTH

-Rajesh


#5

The main purpose of RLP is to allow you to run high performance filters and things on the hardware. For example, if you have a Cobra powered autopilot for an airplane, you would need to run your control loop in RLP. It’s not really a matter of using the code in a reference.

Gus, how will RLP applications be loaded on the Cobra, since there are no JTAG headers? (or maybe there is, my board has been inside the enclose for a while now ;))


#6

Why JTAG? RLP is loaded just like a a DLL, through code and at runtime.

See the video playback project
(link removed)
or CAN driver project
(link removed)


#7

Oh, I thought someone said that RLP applications were loaded with JTAG a while back.


#8

I’m a real newbie in the embedded world :frowning:

Thank you for your answers. They do help, even if they are not what I was expecting :confused:


#9

What did you want to use it for, just out of curiosity?


#10

I would like to know too, may be the thought was that an existing DLL (a control or utility) used on the PC could be imported to the NETMF app ??


#11

You can import stuff from the PC even without it being in C or asm, but C#.

In fact, my desktop uses a serial LCD driver coded in C# that was originally developed on the Domino. There was a grand total of one modification needed for it to work on the desktop.


#12

C# code yes, but C/Assembler code needs to be compiled and linked for the EMX micro.

For. example a VC++ (unmanaged) DLL can not be used with RLP. The C code (or assembler) has to be written, compiled and linked for the LPC2478.

However if you have C code that is generic in nature eg. checksum calculation, matrix multiplication, encoders, decoders etc. you can include the source into the project (on GNU, Keil, Crossworks etc.)

So some one with a lot of high performance code libraries for these kind of tasks can continue to use them on the FEZ platform using RLP.


#13

Only FEZ Cobra is capable of RLP (because based on EMX)

The RLP uses 2Mb RAM for the native compiled code.

RLP is described here with examples:

http://tinyclr.blogspot.com/


#14

I wanted to use the Phidgets C library directly on the EMX so that I don’t have to re-code an USB C# driver but only wrap the dll calls.
For me, it seems like reinventing the wheel :confused:


#15

A developer should stay away as much as possible from RLP. Debugging C# code is easier and future expansion is also easier.

RLP should be used to handle very specific routines that will never change. For example, calculating CRC should be done in RLP. You will never need to debug it more than once and you will probably never change the way it works anytime soon.


#16

I understand your arguments, but in this specific case, C libs are working perfectly and so my job would consist only in writing a wrapper. But it’s not the way RLP is meant to run, so I give up with this idea :wink:


#17

Is it possible?

You have to compile the sources for the ARM platform. So you can’t use it directly.

As Gus said easier to debug(for native code you must hasve JTAG access , which is normally locked)

And easier to maintain(only C# and not mixed up with C and toolchain like GCC)

I would use RLP only for time critical issues.


#18

I have the source code, written for an ARM920T with Linux. But that will be too much work in a domain almost completely unknown to me (apart from Linux). So I won’t bother that much with this. It will be simpler to decode the USB stream and act accordingly in a C# driver.