RLP in Panda

Quick question.

I am reading about RLP:

http://www.ghielectronics.com/downloads/NETMF/Library%20Documentation/html/e278fda9-c252-bf00-103f-6081fc8992c7.htm

So there is no support for RLP in Panda. Is that correct?

Thanks,
Valentin

FORUM BUG. %20 in the URL above breaks the link.

RLP is only on the EMX/ChipworksX

Thank you

Architect,

May I have an idea about your application the requires RLP. We might have a solution for you. 8)

Josef,

I am trying to optimize the library for LCD:

http://www.tinyclr.com/forum/8/1396/

I really would like to use that LCD as user interface for two projects

  1. Drink mixing machine controlled by Panda. (you will be able to select what kind of drink you want to mix)
  2. RepRap Mendel based on Panda, again UI for selecting what you want to print. GC code is stored on SD card.

That’s where FEZ Open could be useful

Yes FEZ open would be very good for that…I am also thinking about something that I want to bring up to the GHI team. Maybe we can work something out.

I have just looked at your code…man this is written to run extremely slow on NETMF. Too many calls to do very simple task but on NETMF there is no other way around it, except if we add a parallel write function.

All you need is

Parallel.Write(byte);
and
Parallel.Write(byte[], int size);

Right?

Then for constructor
Parallel d = new Parallel(WR, D0, D1, D2…D7);

You can still control the register select pin directly that is not needed for performance.

Is this all you needed?

Replied in the other thread:

http://www.tinyclr.com/forum/8/1396/#/2/

And yes ParallelPort would be a great addition

Once you get into graphical stuff, unsafe code or RPL or writing native is pretty essential. I did some graphics work in C# long ago and unsafe code was the only easy way to get sufficient blit speed.

Parallel.Write would be nice !

Parallel.Write(byte[], int startIndex, int length);

And read method:


public class ParallelPort
{
    ...
    // Reads 8 bits from the parallel port
    public byte Read();
    ...
}

Where do you see read being used?

In the case of that LCD, I would like to be able to read pixel values so I can do effects, partial transparency, antialiasing, etc. ILI9325 supports reading through the same pins that are used for writing. While we at it I think Read(int nBytes) will be helpful as well, since ILI9325 has internal counter that is increased after each read, that way I can read the whole image or part of it.
But that is lower priority.


public class ParallelPort
{
    ...
    // Reads 8 bits from the parallel port
    public byte Read();

    // Performs "count" reads from the port 
    public byte[] Read(int count);
    ...
}

Each pixel is 2 bytes right?

Did you look in specification if you can make it 1 byte?

Can you remind me of the resolution?

Your read routine is actually bad for byte array since it will create a new object every-time it is called…but let us not worry about that for now. The GHI guys will make it done right…assuming I can convince them to add it :smiley:

The problem internally is that you can make it really fast but then you have to use specific pins and probably pins on the same port. Then you can even make it faster by skipping the GPIO drivers and write directly to the registers. So, if we keep it all dynamic and configurable, will it be fast enough to give us good performance? We wouldn’t know till we try! This is why I ordered one of those displays to try it for you :slight_smile:

Have you tried this on Arduino and you know how fast it works? I am only curious.

It even supports movies.

I have tried it on Arduino and it is significantly faster, but not up to the best what ILI9325 can do. But again it is 16mhz Arduino. It should be much faster on FEZ if it is done right.

Full screen one color:
Arduino - 2-4 seconds (I will time it later to provide exact time).
Panda - 1 minute 20 seconds.

This is all I need to know. If you can time it and let me know then I will be very happy.

What test are you trying? Fill whole LCD with color? Render full?

The lack of a byte wide output port is one thing that has really surprised me as being missing from the base NETMF. There are so many things in the embedded world that use parallel data access that being forced to bit bang byte wide ports seems silly. I’m am really stocked that the great GHI team is working on this (yet another GHI exclusive feature a.k.a. YAGHIEF.)