SPI display support on GHI's NETMF products

G80 has many GHI exclusive feature that we are proud of. We would like to dedicate this post to the SPI display support.

Normally, using SPI graphical displays with NETMF is extremely slow due to two reasons. First the image data has to be fetched from the internal bitmap class. What make this even slower is that the bitmap data is 16bit internally but then the returned data is 32bit! This results in a lot of memory allocation and fragmentation every time the screen is flushed. Most SPI displays are 16bit so after allocating and fragmenting memory, the data will have to be converted back to 16bit, yet another cause for more memory a location and fragmentation.

Converting the data from 32bit to 16bit will take a very long time. We are talking about few seconds. This doesn’t end here as the data may not be formatted to what the display expects. Is it RGB or BGR? Is it little endian or big endian? A few more seconds is needed to correct the format.

The second issue is covered by utilities data converter that has always been provided in the GHI libraries, but the first problem of the need of fetching the bitmap data was not resolved till the 2015 SDK added a built in feature that flush the data (internally) from the internal bitmap data directly to the SPI bus. Not only that, the data can be formatted internally to fit the display’s requirements. This feature is available only on G80 today but will be moved to all products in future releases. Note that products based on G80, like the FEZ Panda III, will automatically have this feature.

This feature gets better as it can be used to draw on large displays with systems that do not have enough memory, like G80 drawing on a 320x240 display. This should be impossible as 320x240x2= about 150KBytes. But this feature can be used to draw regions on the screen. For example, the full screen can be drawn by dividing it into 4 regions. A product, like thermostat for example, may only need to refresh one area of the screen. The Bitmap class with shapes and fonts are all available to draw on that area.

Good examples are the displays based on the ILI9341 controller. These are low cost ($6) 320x240 displays available from websites like eBay. Very few wires are needed to connect these SPI based displays and then used though the internal support. We will be providing complete code on codeshare but here is a snippet f what to expect.


// Create a bitmap like always and draw something on it, shapes, images fonts.
var bmp = new Bitmap(160, 128);
bmp.DrawEllipse(Colors.Red, 5, 5, 5, 5);

// Tell the display where to draw 
tft.SetWindow(0, 159, 0, 119);
tft.PrepareSendData();

// This call will internally convert the data and send over SPI
bmp.Flush(0, 0, 160, 120);

So make sure you have one of these displays on your desk when you receive your FEZ Panda III and if you haven’t gotten you FEZ then here is where to get one https://www.ghielectronics.com/catalog/product/474

PS: There is a bug in the current SDK and the only bitmap size allowed is 160x128 but you can use a display of any size. This will be fixed in coming SDKs.

PPS: special thanks to Brett who pointed out this great display and who also shipped us one to test.

9 Likes

Great news! I have about a dozen displays based on the ILI9341 and have never been able to get one to perform well. Goes all the way back to ,ohh, about these days:
https://www.ghielectronics.com/community/forum/topic?id=13662

And wouldnt you know, i just received a Panda III. Perfect timing.

Gus, when will the driver code be shared?

We will be posting it to code share in few days.

@ gus - that is great news, well done GHI :clap:

yay !

@ Dekes1, there’s a driver already usable for ILI9341 GitHub - veccsolutions/Vecc.Netduino.Drivers.Ili9341: Display driver for the .NET Micro Framework to drive the ILI9341 LCD screens. (ignore that it says Netduino, it works fine on any netmf device with a few changes that have been committed). This work by GHI will really bring an increased speed to these devices; can’t wait for my Panda III to arrive !

This is good stuff. I would like some capacitive touch with these small cheap displays, any recommendations. And furthermore, the list of candidates on ebay are massive, maybe a “buying guide” of some sort would be helpful…

You’re not going to get Capacitive Touch in a sub $10 display. And you won’t get it on one of these ILI9341 displays (well not that I’ve found - and I’ve looked just a lot)

I bought some 2.8" from ebay (no touch) and aliexpress (with resistive touch; untested). The first two are ones I have bought, the last is a 2.4" option.

http://www.aliexpress.com/snapshot/6634730266.html
http://www.ebay.com.au/itm/381186186810
http://www.ebay.com.au/itm/400759772993

OK, captouch option if you don’t want a PCB based solution (ie you are going to design your own) Serial SPI 2.8"TFT LCD Module Display,320x240,Optional Touch Screen in total will be about US$13 including ZIF connector and Cap Touch

@ Brett - Good find :whistle:

Well you were too scared to post the budget breaker :wink:

@ Brett - good find. Actually it looks like the touch sensor plate could be used for some really cool water proof button panel right there. And only 2$ would enable some cool and cheap modules…

Oh where oh where has the source code gone? ;D

I haven’t slept since the announcement of an SPI display library was announced!!

Cool displays, thanks for the link to the driver. Any idea if that reverse text is in portrait mode is solved ?

1 Like

not to the best of my knowledge. I haven’t dug any deeper (it actually didn’t affect me except in the test I was doing) but yes we really should try to address that… I have the driver forked so will see if I can dig around to find a way to sensibly do this.

Edit: if Skewworks or @ Taylorza see this and want to assist - you guys are the bomb on this kind of stuff and I bet would shortcut the whole fix process

@ Brett - I do not have this display, but the thing I would try is to change the following line near the top of the code


const byte lcdPortraitConfig = 8;

to the following


const byte lcdPortraitConfig = 8 | 0x40;

This sets the memory access control register MX bit to 1, which should flip the X direction when accessing memory. Looking at the pictures it looks like the problem is in portrait mode, if not try the same change for the landscape mode but possibly for the MY bit which is 0x80.

For more info, check the data sheet specifically page 127 which describes the Memory Access Control register.
[url]Redirect Notice

2 Likes

(edited for clarity :slight_smile: ) @ Taylorza, if you want one of these displays, PM me your address and I’ll post you one. Worked a treat after |0x40 :slight_smile: .

Change committed in my fork, and pull request sent.

1 Like

@ Brett - I’ll try this immediately when I back at my lab … thx for organising this fix :clap:

@ taylorza - thx for helping out :clap:

1 Like

… in the meanwhile, at the lab …

4 Likes

sweet - love that outcome !

1 Like

[quote=“Brett”]
If you want one of these displays, PM me your address and I’ll post you one. Worked a treat after |0x40 :slight_smile: .
[/Quote]
Which one of them exactly?