Ok, here’s the new library for Miosix: Mxgui. As the name suggests, it’a a GUI library for microcontrollers, designed to work with the Miosix kernel.

Source code is here, while documentation here.

What can it be used for? 3D rendering on a microcontroller, for example.

Mxgui examples from fede.tft on Vimeo.


Tags: , , , ,

4 Responses to “Mxgui”

  1. kuchura Says:

    Hi there!
    I’ve ported mxgui to IL9325-based TFT LCD connected to my Strive Mini board, except touch screen controller (will do this soon). Here are the benchmark results. What do all these figures mean?

    Miosix v1.59
    Starting Kernel… Ok
    Starting Filesystem… Ok
    Available heap 53248 out of 63124 Bytes
    Monospace text 0.028250 35.39
    Variable width text 0.027000 37.03
    Antialiased text 0.027500 36.36
    Horizontal lines 0.014500 68.96
    Vertical lines 0.014000 71.42
    Oblique lines 0.098000 10.20
    Screen clear 0.013000 76.92
    Draw image 0.014750 67.79
    ScanLine 0.014000 71.42
    ClippedDraw 0.024000 41.66
    Clipped text 0.025000 40.00
    ResourceImage 0.000000 999.99

    And, by the way, I don’t like how the final screen looks like. It seems that it should use antialiased font (white on black) but many pixels in the corners go black. Does it mean that I should finetune the gamma settings?

    Regards and thank you for your excellent work!

  2. fedetft Says:

    Well, this is seriously good news 😉
    First, an explanation of the benchmark:
    Given that the time needed to execute a graphical primitive such as drawing a line is very low, the benchmark measures the time needed to fill an entire screen using that primitive. For example, the text benchmark measures the time needed to fill the screen with text, the image benchmark does the same with images, etc.
    The time is printed in the second column and, as it is often used to get an idea of graphics performance, the FPS (frames per second) is also computed as 1/time in the third column.
    This gives a hint of how fast will a “real world” application be, as it will use a mix of such drawing primitives.

    For the issues with the final screen, my guess is a gamma issue. First, notice that the quality of the antialiasing IS lower than the one used in desktop PCs, since text is printed using a 2bit grayscale. For white on black the resulting colors are black, 33% white, 66% white, white. This has been done to reduce the size of font lookup tables.
    To give you an idea of how it should look like, here are two pics of the benchmark final screen running on my stm3210e-eval that has an LCD screen (using an OLED would be unfair, ofcourse)

    The numbers of the benchmark you see here are much lower than yours as I’ve run the benchmark code in the external RAM through the fsmc. The second picture is a closeup with a microscope, my personal way of verifying pixel perfect-ness on an embedded device.
    As you see, from a distance the glyphs should be “full” without black spots in the lines that composes them (even though the camera blurs everything even more). From a closeup the intensity mismatch becomes visible, but should remain “pleasing”.

    By the way, would you mind contributing the display code?
    I can give my help adding the StriveMini as an officially supported board, with the proper configuration in settings/ and a folder in arch/cortexM3_stm32, while you could provide the display and touchscreen code for mxgui.
    For license issues, your code should be released under the same modified GPL license used in Miosix, just copy-paste it in your sources and replace the line
    “Copyright (C) 2011 by Terraneo Federico”
    “Copyright (C) 2011 by <your name>”
    Let me know if you’re interested.

  3. kuchura Says:

    Oh, yes, your final screen looks much better. I’ll play with gamma tonight and I beleive I’ll find a way to fix the problem.
    BTW, will this simple antialiasing work with black-on-white text? And with black-on-gray?

    Of course, I’ll contribute the arch directory for the board and the LCD driver. But I need to finish with touch screen driver first. There is a SPI-driven touch controller so it will be easy to do, I hope. Probably it will not need calibration tricks at all.

  4. fedetft Says:

    Sure, the antialiasing works with any background and foreground color. The two bits per pixel are just an index in a palette that is computed by blending the foreground and background colors.
    The code is in Font::generatePalette() (

    Great news again. Feel free to drop me a mail or contact me through this blog once the code is ready.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: