Rlp & t35

Archive
1

I might be trying to bite off more than I can chew …

I’ve got my managed code working on my Spider/T35 with a Bitmap and SimpleGraphics. The app is setting digital pins high/low, reading some analog values, processing the results and displaying a graphical representation in on the screen.

I’m fairly confident (other than doing it for the first time) in being able to the do gathering and processing in RLP. But the T35 seems a bit daunting. I tried to search Codeshare for this, but didn’t find any info

Any samples/examples/tutorials/direction on this?

If interfacing with the T35 is too much for me (at this point), how about generating the Bitmap object? If netmf Bitmaps don’t exist in RLP, could I just return a byte[]?

Thanks for the info and help!

2

This is a good one!

http://www.tinyclr.com/codeshare/entry/234

3 Likes
3

While I don’t disagree it’s a good one …

But I have no clue what the “asm volatile” code is doing, as I’ve never done assembly before.

Additionally seems like this project is about taking an existing bitmap and displaying it as quickly as possible.

4

No magic in there :slight_smile:

F.e.: You have a screen of 320x240 pixels, knowing that each pixel takes 2 bytes (16 bpp) and is encoded as 5:6:5 (5 bits red, 6 bits green, 5 bits blue).

You read out the LCD base address from the LCD_UPBASE register:


 #define LCD_BASE_ADDR		0xFFE10000
 #define LCD_UPBASE   		(*(volatile unsigned long *)(LCD_BASE_ADDR + 0x0010)) // this define reads out the value from the LCD_UPBASE address

And you start drawing pixels:


unsigned short * pixelMap = (unsigned short *)LCD_UPBASE;
int x = 15;
int y = 25;
unsigned short color = 0xFFFF;
pixelMap[x + y * 320] = color;
5

Thanks for the info. For me it’s magic :wink:

Answer one question, and more pop-up :smiley:

To make sure I have some type of understanding:

  • Is the pixelMap a built in array (buffer) in the chip, and this code is just getting a pointer to that array?

  • Once you change a color setting in that buffer, will the screen automatically refresh that pixel? If not, do you need to flush it?

  • How did you determine the LCD_BASE_ADDR? Is that something built into EMX? Is that value different for a Hydra based system?

I appreciate the info!!

6

You’ll find all those register addresses in the NXP LPC24XX datasheet: http://www.nxp.com/documents/user_manual/UM10237.pdf

So LCD_UPBASE is a register of the EMX LCD controller, which contains the address of the pixelmap in SDRAM. So you need to read out that address and map an array on it for easy pixel access. In fact if you would copy 320 x 240 x 2 bytes from the address contained in LCD_UPBASE, you have taken a screenshot :slight_smile:

The LCD controller of the EMX is constantly refreshing the TFT screen with data it reads from that starting address in SDRAM, updates in that RAM area will directly show up on the screen.

It is also possible to hook up to the vertical refresh interrupt and do double buffering etc… But that’s advanced stuff for later.

7

Very cool. Thanks again for the information! I’m a programmer who is new to the hardware aspect - so this is all new to me, and I am trying to be a sponge, though not all of it is retained and quite a bit goes over my head.

I was reading through the DL40 info the other night, and the docs talked about the register there as well. You would set a value in the register, and DaisyLink module would automagically get the setting. So is this the same type of mechanism?

Also, that 320 x 240 x 2 array – could that be passed back into Managed world and then used in the Bitmap constructor?

Again thanks

8

I see that the Bitmap class has a constructor that takes a byte array, you could try to call it like this:


byte[] arr = new byte[320 * 240 * 2];
rlpGetBitmap.InvokeEx(arr);
new Bitmap(arr, Bitmap.BitmapImageType.TinyCLRBitmap);

Don’t know if it will work as it will not have a bitmap header… In fact I’m almost sure it will not work, as the Bitmap class has no clue of the size of your bitmap. So you’ll have to figure out what header you need to pass in case of the TinyCLRBitmap type, maybe someone else has done this before?

9

Question regarding this: pixelMap[x + y * 320] = color;

Should that be 240 instead? (as in y * # pixels tall)

edit:
Tested it with 240 and it didn’t have my desired effect - my diagonal line was broken up into sections. When changed to 320, it worked just right.

So why does 320 work and not 240?

10

Because the memory is addressed by rows. Each row has 320 pixels on it not 240 (which is columns)

So your multiplying the row by 320 and adding the column.

1 Like
11

Pixels on the first line are from X=0 to X=319, so second line starts at 320, etc

12

That much I understand, as the coordinate system seems to be the same in SimpleGraphics, Glide and Wpf.

Since all my life I’ve been used to X,Y being 2D and not a flat array, seeing Y and the number of horiz. pixels being multiplied just didn’t look right. I just now sketched it out:

0,0…319,0 0,1…319,1 0,2…319,2 etc

and it makes more sense now.

Surely this rudimentary for you low level guys, but for me this is all new. I’m 95% of the time in C# and the rest in HTML/js (though I’ve got to maintain vb.net application). Before that it was 95% VB and the rest between Php, HTML and C++. All this on the desktop and with no formal development education. This brief recap of my life is just to show how much fish out of water I am in FEZ world (never heard of SPI, I2C, etc before), esp in RLP.

So I really appreciate the help (and patience!)

13

you’re welcome!