MikroBUS.NET work on native display(s)

Bec_a_Fuel · July 15, 2015, 8:59am

Hello,

the recent demo about MBN having fun was of course a teaser for more serious work…

The result of this work can now be seen on the MBN forum (no registration needed, do not worry).

Regards,

Christophe

Bec_a_Fuel · July 15, 2015, 12:58pm

I have had comments about publishing my post here as well… I did not do that because I did not want to look like I was advertising too much

So, here is at least the video. And for the more complete informations about what is happening, the link above is still valid.

Gus_Issa · July 15, 2015, 1:14pm

Feel free to post code and videos as you wish. It is still NETMF. External links may confuse readers anyway, not recommended.

Bec_a_Fuel · July 15, 2015, 1:22pm

Thank you, Gus !

So, here is the original post :
[line]
We are currently working on implementing native drivers in the Quail firmware. This allows the use of standard NETMF graphics (bitmaps) on various LCD.

So far, we have preliminary support for the following displays/chips : ST7565, ST7735 (GHI N18, for example) and SEPS114A (MikroE OLED-C). As you can see in the demo video (link below), we can achieve very high framerates using only full screen flushes !

But this was not enough for us Then we have added a nice feature : simultaneous multi-displays support. Yes.
You can use as many displays as you like, all at the same time, each one having its own bitmap (so no trick, here) for really individual control.

Since it was not enough, each one can have its backlight (if available) controlled by the standard Utility.Backlight() method.

The video is demonstrating the following :

each display alone runs a small demo, at full speed
then the three displays are running the same demo again, trying to get the maximum FPS
then they all synchronize on the slower one (the ST7735) to all have the same FPS
and finally the same code running with the N18 on the GHI G80 dev board. (Sorry, but we had to have a reference)

And, as usual at MBN, usage is pretty simple. Here is a sample code :

private static void Sample()
        {
            _bmOLED = new Bitmap(96, 96);
            _bmN18 = new Bitmap(128, 160);

            MBNDisplay.Populate(1, MBNDisplay.MBNDisplayTypes.SEPS114A);                    // Socket #1 on the Quail board, no backlight on this display
            MBNDisplay.Populate(2, MBNDisplay.MBNDisplayTypes.ST7735, BacklightPin: 65);    // Socket #2 on the Quail board, backlight on pin PE1

            MBNDisplay.Select(2);           // Not mandatory here since it is the last populated display
            Utility.Backlight(true);
            _bmN18.Clear();
            _bmN18.DrawText("MikroBUS.NET rocks", _font, Color.White, 1, 1);
            _bmN18.Flush();

            MBNDisplay.Select(1);
            _bmOLED.Clear();
            _bmOLED.DrawText("MikroBUS.NET rocks", _font, ColorUtility.ColorFromRGB(255, 200, 0), 1, 1);
            _bmOLED.DrawText("on a second display", _font, ColorUtility.ColorFromRGB(255, 200, 0), 1, 21);
            _bmOLED.Flush();

            MBNDisplay.Select(2);
            _bmN18.Clear();
            _bmN18.DrawText("Back on the N18 display", _font, Color.White, 1, 1);
            _bmN18.DrawText("MikroBUS.NET still rocks", _font, Color.White, 1, 21);
            _bmN18.Flush();
        }

You will also notice the use of a MBN “Type S” G-Adapter to connect the N18 display from GHI (it comes with a Gadgeteer socket)

The seconds-hand on the ST7565 clock demo is not visible due to the high framerate requested and the slow refresh rate of the display. But it is displayed !

We are currently adding support for a 128x128 display and the support of the Orientation property. Support for clipping area/windowed flush will be added later since the actual frame rate for a full flush() is not a show-stopper.

njbuch · July 15, 2015, 4:45pm

Dudes, that is an amazing performance improvement!

Brett · July 16, 2015, 2:40am

Santa, ILI9341 support please ! .

Bec_a_Fuel · July 16, 2015, 1:36pm

Brett,

although a firmware support for the ILI9341 is possible (and not that hard), the problem lies in the NETMF Bitmap system
As Gus stated a few days (weeks) ago, our little MCUs cannot handle such bitmap sizes with their limited memory.

And even if they could, there would be not much free space for user programs anyway. If any.

[line]
[em]Disclaimer !!![/em]
What is following is not advertisement or a proof that we have a bigger one. It is only serving as an example for my comment. So please, no rants.

See the two attached screenshots. One is done on a Quail with our latest firmware and the other one was done on the G80 dev board (latest firmware as well).
Both programs were using the strict minimal needed code to create a 320x240 bitmap. Nothing more, no extra assembly or whatsoever.

As you can see, the Quail seems to be able to handle such a bitmap whereas the G80 does not want to please us. This is a logical result for many reasons : G80 firmware has more features and Quail has more memory on chip. So there is no comparison to be done.

But… on the Quail, once you begin to add real code and the needed assemblies, like SerialPort and PWM, for example, then it behaves like the G80 : out of memory.

The solution of splitting the bitmap in chunks may work in terms of used memory but would be more complicated to handle as well : what if you want to draw a rectangle or a text that spans across the chunks boundaries ?

Except by using a F429 with external memory ( :whistle: ), I do not see much solution here. At least when using standard graphics calls.

This is why Santa does exist, I think…

Gus_Issa · July 16, 2015, 1:44pm

You do not have to wait. I have a solution for you, use G120 :whistle: I am not even bringing the G400 into the battle here

iamin · July 16, 2015, 2:20pm

@ Gus - Well, if speed is important, then G120 is not a good replacement for G80, G400 would be the only option ([url]https://www.ghielectronics.com/community/forum/topic?id=19520&page=1#msg192902[/url]).

Bec_a_Fuel · July 16, 2015, 2:52pm

Price is not the same either
But the F429 would not perform better anyway.

Brett · July 16, 2015, 5:36pm

So the example you show, with a clock, is a good example where you need a full bitmap. I have many examples where I don’t, and only need a sub-bitmap that has a text rendered onto it. Memory is less of an issue in this case - I have maybe a dozen areas that fit into my 320x240 image so I use a single appropriately smaller bitmap to render text into, output it, render next text into, etc.

Bec_a_Fuel · July 17, 2015, 1:31am

As I said before, I do not see any problem coding the native driver itself, so it will be coded as soon as I receive mine.

But how will you tell the standard NETMF Bitmap methods that you want to refresh/flush the bitmap at specific display’s coordinates ? Both the Flush() and the SetClippingRectangle() are using the bitmap’s coordinates, not the display’s ones. Unless I am missing something, of course.

So if you create a 80x80 bitmap, for example, then it would be displayed starting at (0,0) on the display, not at (80,80) or (200,100).

That said, a Flush() overload or a custom FlushAt() are both possible. But those will not be “standard” Bitmap methods.

_Peter · July 17, 2015, 2:08am

@ All - There is the idea to ask for an extension on the bitmap functionality in the netmf … it has become a community open source project on github. This won’t be in the 4.4 release, but with good arguments/motivation this could be for 4.5. Expecially when one of the specialists on the matter is offering his services to the netmf github group and implementing the functionality be himself.

Bec_a_Fuel · August 8, 2015, 3:21am

We are close to release a new firmware for the Quail board (and Dalmatian/Tuatara as well) that will natively support the following displays :

ILI9163 - 128 x 128 TFT LCD
ILI9341 - 240 x 320 TFT LCD
SEPS114A - 96 x 96 OLEd (a.k.a. OLED-C Click)
ST7565 - 128 x 64 Graphic Monochrome LCD
ST7735 - 128 x 160 TFT LCD (a.k.a. GHI N18 or generic)
ST7735R - 128 x160 TFT LCD (a.k.a. GHI N18 or generic with Blue/Red Color Space swapped)

You can find more info here.

And some tests we are doing on the F429 Disco and the ILI9341 SPI driver :

Additional tests and comments on this thread.

Brett · August 8, 2015, 7:32am

That’s an awesome set of vids, great progress!!

Bec_a_Fuel · August 9, 2015, 8:52am

@ Brett : here is another demo using three bitmaps.

One 240x160 to display the text on the top of the screen at (0,0), one 96x96 to display the clock at (144, 224) and one 120x40 to display available memory at (4,200).

I am using the F429 Disco because I do not have a separate ILI9341 display, but to be consistent with the Quail memory layout, I have set it up so that it is not using the external SDRAM. So it is starting with about 175KB free.
The overall memory used by the bitmap is : 240x160x2 + 96x96x2 + 120x40x2 = 104 832 bytes.

Of course, I could have chosen a smaller bitmap for the big text to save even more memory, but the purpose here was to show that you can use simultaneously different “small” bitmaps to be displayed at different coordinates on the display, without loosing much memory.

Justin · August 9, 2015, 5:43pm

Excellent work Mr Benzine - now if there as just a Gadgeteer version

Bec_a_Fuel · August 9, 2015, 6:13pm

Thank you !

I am really sorry about the lack of Gadgeteer integration or Win10 IoT integration.

scardinale · August 12, 2015, 10:00am

Did you say that you wanted Touch capability for the ILI9341?

Well now you have it for any ILI9341 with either the ADS7843 or XPT2046 Touch Screen Controller IC.

Here is a little demo of the ILI9341 LCD hosted on a MBN Quail mainboard using MBN Native graphics methods.

ianlee74 · August 12, 2015, 10:04am

@ scardinale - Good job!