Main Site Documentation

FEZ Domino with MI0283QT-2 touch LCD


Refering to this blog: , I would like to get this working, however I do not know how to connect the LCD to the domino.
Equipment: FEZ Domino and MI0283QT-2 touch LCD :-[ :-[

Help would be welcome.


Selected those because you already have these boards?

You can very easily use FEZ Panda II with FEZ Touch…plug and play and it will work in seconds :slight_smile:


Yes Gus, I have these borads.
But if I cannot get this combination to work propperly, I will indeed go to:
FEZ Panda II:
FEZ Touch:

Is there room left to use a
FEZ connect shield:

Only Touch and Connect shield start shipping at 29th of april.
Is there a representative in Europe that will off these items too?
My normal supplier is Watterott in germany but I do not see these items in their webshop yet.


@ WimC,

Those products are new and not shipping yet. I am waiting for them in my local store too :wink:

About the room, see below pictures from the online catalog : panda II, connect and touch used together !


They are good partners of ours. You only need to call them and ask them for what you need.

By the way, we have FEZ Touch in stock but very few so if you order it quickly then your will probably get one in few days.

I will let you in on a secret…stay tuned for a new kit announcement on Monday :slight_smile:


@ WimC
both the S65 and the MI0283QT-2 boards suffer from SPI mode in managed code. Your face will fall asleep waiting for action - even in 8-bit mode. The FEZ variant would have the advantage that it uses an 8-bit parallel interface - much faster, even in managed code.
Both the S65 and MI0283QT code be run at an adequate speed using the RLP method. There’s not much code for the standard methods and widgets.
But I liked Gus’s suggestion (especially since the shipping to Europe is so expensive) to talk to Stefan Watterott about stocking these parts, as well as a few of the other new boards.


I can say… I use the Mi0283QT-2 with my netduino and Panda II Board and the Speed is fine. I will send the example Code for both boards to Andreas Watterott and he will serve it on his website.



Why not share the code with us here too? :slight_smile:


@ Andreas
be easier for others if the code was posted on the link Gus gave.
Speed is of course relative. I’ve tried the S65 Shield on Panda and with a PIC32 - like night and day. I’ve only used the MI0283QT-2 on PIC32 and can’t image the Panda being anywhere near it - without RLP.
Be nice to see your version.


You are right :slight_smile:
I will share the code here tomorow. Now it’s time to sleep 8)



Thanks. I have several of those MI0283QT boards and would like to salvage them for something.
Looking forward though to GHI’s new board at the end of April.


@ Andreas
Thanks for posting. Looks very promising. Had a few problems until I changed to running on external power. The GC is unusually busy. In any case, looks very promising. I’ll play with it some more. I like the way the SPI is set up - nice to see code from someone who understands the language :slight_smile:

Looked like a power problem, but seems to be random out-of memory problem while drawing. I think I'll try a global byte buffer for some things to ease the GC running constantly.
Failed allocation for 2002 blocks, 24024 bytes

    #### Exception System.OutOfMemoryException - CLR_E_OUT_OF_MEMORY (1) ####
    #### Message: 
    #### Falmer.SPOT.Hardware.MI0283QT_2.MI0283QT_2::DrawBox [IP: 0015] ####
    #### FEZ_Display.CDisplay::Test_Routines [IP: 0178] ####
    #### FEZ_Display.CDisplay::Test [IP: 00f0] ####
    #### FEZ_Display.Program::Main [IP: 001a] ####


@ Lurch
Thanks :slight_smile: the reason seems to be, that i carry the code from the c code.

The out-of-memory problem seems to me a FEZ problem. When i run the code without vs2010 debugging, the code runs without memory issues. This is what you also said. First i used the code on a netduino board, no memory problems in any way. Now using the Panda II it throws exception. Funny, i never used the GC before, but now what i’ve read, it is strongly the main function :slight_smile: But i like the Panda and the SDK’s from GHI !

What about the speed for you ?



I’ve ordered the stuff as mentioned before and hope the customer gives me the extra time.

But I’m still interested in the code and the connections.
See there is code already in the designed area, evan a complete project.
Going to study on that.

Tanks guys.


@ Andreas
Sorry for the delay. It was 23°C and sunny on the Rhein, so I went biking all day.
The speed seems to be exceptionally good. I’m afraid I was negatively influenced by the S65-Shield code posted on FEZZER. I wrongly attributed the speed to managed code. I have too little experience with it. I want to backtrack on the S65 as well and compare it to your code to see where it (or I) goes wrong.

Your project has definitely made my day. Not sure how exactly GHI controls the GC. There are probably ways to cut down the allocations by using a fixed byte array for some stuff.
Thanks again for sharing your code. Very nicely done.
I also think I’ll spend some time looking through the NetDuino website. Looks like the libs and tips there may help me.
Have a nice day!

Speed is fine. Colors OK. Fonts nice. All in all very nicely done.
I only changed the calibration to wait for tp.GetPressure < 8 between points because it occasionally skipped / jumped. May have been a jittery hand. Lots of space left for programs / widgets. Cool :slight_smile: Rated it 5 stars.


@ Lurch
Thank you, good to know that you can use it.

Meanwhile, i added routines to store the calibration data on a sd, so calibration is only done once.
In addition i also added bmp loading and showing. images with a size of 50 x 50 are done without memory complication.
I will pack this together and update the code here in the code section the next days.



@ Andreas
Thanks. I tried an SDCard method for images and calibration data. A little bit large in deployed code, but a good exercise in C#. I was thinking of using SPI flash, but the SDCard would be better for images.

Outside of debugger mode all works very well. The debugger problems may be the same as turned up in an http project (NetConfig) being discussed in the forum. Maybe they’ll find an answer.
Happy Easter.


@ Andreas
Got sick of Easter eggs and played with the code again. Noticed that the DrawBox (and DrawCircle) consume a lot of memory for x*y ushort. Played with somewhat more complicated but smaller memory versions that were fast enough. Box doesn’t necessarily fill - so framing stuff already on the screen can be done. Unfortunately, my C background my “color” the code.

      public void LCD_Box(ushort x0, ushort y0, ushort x1, ushort y1, ushort color, bool fill, ushort fillcolor)
         int i;
         int hx = x1 - x0 + 1;			// how many pixels on each axis
         int hy = y1 - y0 + 1;
         byte[] start = { LCD_DATA };

         // Draw upper and lower horizontal lines of Box
         ushort[] buffer = new ushort[hx];
         for (i = 0; i < hx; i++)
            buffer[i] = color;
         SetArea(x0, y0, x1, y0);
         SetArea(x0, y1, x1, y1);

         if (fill)
            for (i = 0; i < hx; i++)
               buffer[i] = fillcolor;
            buffer[0] = color;
            buffer[hx-1] = color;
            SetArea(x0, (ushort)(y0+1), x1, (ushort)(y1-1));
            for (i = 0; i < hy - 2; i++)
            buffer = null;

            // Draw left and right vertical lines of Box
            ushort[] buff = new ushort[hy];
            for (i = 0; i < hy; i++)
               buff[i] = color;
            SetArea(x0, y0, x0, y1);
            SetArea(x1, y0, x1, y1);
            buff = null;

My Panda’s (I & II) can breathe better with this. Circle is still too slow. Need better math for that.


@ Lurch
Sit here late at night, silence, best time to optimate the code and i see your reply :slight_smile:
cool, i will check this…



@ Lurch
You are right, the Code is Perfect. I always thought spi writing is the bottleneck.
I will transfer this in my code and will optimize all a little bit more.