My Road test is to test out the development tools and features of the board in building out a version of the HMI I created for my power supply (and then extend the functionality using other board features.)

TL;DR;

I’m aiming these posts at those who are not familiar with MCU development to give them a feel of what they will go through.  I know not everyone will be interested in reading this in detail so I’ll provide a brief summary of the points:

• Building the emWin HMI with GUI Builder is straightforward and intuitive - the documentation provided is comprehensive and informative.

• Graphical images can be embedded as C-files in the application.  emWin provides features to aid performance of image writing to the screen which will be useful for complex/detailed images (e.g. photographs.)
• The tools work exactly the way you expect GUI builders to do so.  This makes it familiar to anyone who has used these types of tools before.

The Goal

This is what I am aiming for:

emWin Tools

This first outline will just be static, to use emWin’s GUI Builder, Bitmap Converter and Font Converter.  There are two sets of graphics and one font; the digits that are displayed on this are actually graphical elements drawn to look like LEDs - I shall probably just use a second font for this.  I will be starting with a copy of the base emWin project (that I created in Part 4C), renamed.  I don’t want this to be a review or tutorial on using emWin, but I’ll cover some basics to show how easy/difficult it is to actually use with the board.

GUI Builder

This is a tool provided by Segger as part of the emWin package that allows screens to be created without writing source code - a common approach to building interfaces.  Each screen to be built has to be defined in its own GUI Builder project file but the tool does generate the source code to create them.  As is usual, the application itself then configures/changes them as required at run time.

GUI Builder will generate files into a project location specified in GUIBuilder.ini which must be manually changed (for each project):

(The trailing \ is important: without it, the tool will place the file in directory src and append Application to the name)

This process will be very familiar to anyone who has used these types of tools before. In the tool, I need a window in which to place widgets, give it a name and set size:

So I’ve given it a name to identify in code and set the size to the Envision board LCD size.  I will add a black background, then when the project is saved, it will generate a source file, wndMainInterfaceDLG.c:

And thus it precedes as one would expect.  Add the widgets required and on save, the source file is generated (re-generated) with updated information.  Some notes on the GUI Builder tool:

• The interface is a little clunky but it works and is stable.
• There is a reasonable set of default widgets.  I believe, but haven’t investigated, that it is possible to create custom widgets in emWin, derived from these defaults.
• There is no copy & paste.  So every widget has to be created from scratch: if you have 100 labels on the window that are Light Grey Helvetica 20pt right aligned, then for each label you must select the font, then select the colour, then select to set the text, then set the text, then select the alignment.  It’s a little slow and tedious.
• It is possible to give multiple widgets the same name!  I expect that it would get picked up at generation time but I didn’t take it that far.
• Each widget and its API is documented in the emWin manual so anything that cannot be adjusted through the tool at build time, can be adjusted at runtime with code - assuming there is an API for what you need to do but they seem pretty comprehensive.

Here’s the first cut running on the board itself:

No graphics yet and the fonts aren’t quite right for what I want (including no ‘degree’ symbol) but those elements will be set up later, as described below.  The only code I have had to add to the base project to get this displayed is the following:

in main():

  …
  extern WM_HWIN CreatewndMainInterface(void);
  …
  CreatewndMainInterface();
  …

There is no separator widget, so the lines have to be drawn as part of the window initialisation.  Due to the way emWin works, the ‘window’ is actually a dialog placed on top of a base window, so in order to draw on it, use of a callback is required.  This is added into the user editing space in wndMainInterfaceDLG:

  …
  // USER START (Optionally insert additional message handling)
  case WM_PAINT:
    // Handle the default drawing by the default callback
    WM_DefaultProc(pMsg);
    // Draw the lines
    GUI_SetColor(GUI_MAKE_COLOR(0x00DBDBDB));
    GUI_DrawLine(2,100,478,100);
    GUI_DrawLine(2,132,478,132);
    break;
  // USER END
  …

Bitmap Converter

This tool converts image formats, not just BMP but also GIF, PNG etc into an emWin bitmap format and then generates a C-source file of the bitmap to be embedded in the code.  I will be putting the generated code into the Application folder.  It’s a pretty simple process.  Install, then launch Bitmap Converter, open the image file, select the colour palette then generate the C-file.  This file is then used in the application to draw the bitmap.  Bitmap Converter can do some image manipulation, such as rotate, flip and size, but anything more complex needs a graphic manipulation program (Photoshop and its ilk.)

It’s worth pointing out that GUI_Builder has an Image widget that can be used directly.  My images are in PNG format which requires an additional library and I have chosen to just convert them to avoid installing this and to try out this tool.  Additionally, I can compress the images and save memory.  emWin provides a facility to create what it calls a Memory Device: this is, essentially, an area of memory that can be used to store the processed image data so that it only needs to be done once: this is then a trade-off between performance and available memory.  My images are tiny, and compressed, so performance isn’t an issue.

(Apologies the colour is a bit washed out, and completely gone in the thermometer, but it is the same as the first image, honest!)

The tool created two files: Meters.c and Thermometer.c.  I had to add the following code to wndMainInterfaceDLG:

// USER START (Optionally insert additional defines)
extern GUI_CONST_STORAGE GUI_BITMAP bmThermometer;
extern GUI_CONST_STORAGE GUI_BITMAP bmMeters;
// USER END
...
    // Draw the graphics
    GUI_DrawBitmap(&bmMeters, 185, 2);
    GUI_DrawBitmap(&bmThermometer, 10, 160);
...

Font Converter

This tool converts any installed MS Windows font into an emWin bitmap font, again as a C-file to be embedded in the code.  The tool does come with the emWin product for Renesas but is normally a separately purchased item.  emWin supports system independent fonts, true type fonts, bitmap fonts, anti-aliasing, Ascii + ISO8859, Unicode 16-bit and Japanese Industry Standard.

Having got this far, I realise that I have a choice to make: either build the GUI up with widgets in code and make use of any fonts created by Font Converter, or use GUI Builder which specifies emWin standard fonts.  The issue is that the Font defined in GUI Builder is set during initialisation and cannot be edited in the code because it is outside the User editable code regions.  Once the widgets are initialised of course, they can be changed but it's a bit of a duplication of effort and it's clear that it's not the expected approach: thus, to use non-standard emWin fonts, I would need to create the widgets myself.  That doesn’t appear to be a complex activity as the API for each widget is documented in the emWin user manual (and I have the code that GUI Builder generated), but I’m just going to use the standard fonts.

Final result

After playing with the fonts and layout, this is the final result - still a static display, obviously.  Note that on the first image (what I am aiming for) the digits are not a font - they are graphically drawn - but in this version, a font is used.  I haven’t yet worked out how to get the degree symbol: the font supports it, emWin supports it, I can ‘enter’ it into GUI Builder (via Character Map or the keyboard code), but the app won’t display it.  The font used conforms to ISO8859 so there’s something specific I need to do and I will update it when I’ve worked it out.

Just as I got the layout looking right, GUI Builder crashed and I lost my work.  As I re-did it, I was saving regularly but I did notice that it was prompting the ‘overwrite existing file twice’ - i.e. it was actually saving twice for each single request.  The upshot was, that when I rebuilt and ran it, there were no changes!  Re-launching GUI Builder, none of the changes were there so I have no idea where, or if, it actually was saving.  Re-did for a third time: so I’m adjusting my point above from “Stable” to “Fairly Stable”.  The point to bear in mind with saving is that it overwrites any existing file you have, so make sure you have a backup if you are experimenting with alternatives and don’t want to lose your original starting point.

(note how the degree symbol comes out as a '@' character.)

EDIT:  Resolving the degree symbol

I've had more time to think about this and realise what is happening.  I wasn't actually expecting that embedding a degree symbol would work but it did allow me to layout the correct size.  The font itself allows for the decimal symbol which is actually character 176 or hex B0.  Using a string value such as "\xB0C" won't work because C interprets a hex escape sequence as all valid hex characters following the \x - in this case, B0C are valid hex characters so won't work.  The compiler warns about values out of range and nothing is displayed.  "\xB0 C" would work, but there would be a space character between the symbol and the letter C.  We can switch to Octal as that is fixed at up to 3 octal characters: it stops at the first non-octal character or 3 characters whichever occurs first.  176 in octal is 260 so a string value of "\260C" will actually display what I want.  That looks weird in GUI Builder but there appears to be no way around it if I actually want to use a degree symbol.  The answer would seem to get the widget size right, then not worry about the actual text used:

In the above case of course, the widget could be sized as large as needed to display the full text as nothing is to the right of it and it is left-aligned.  So that leaves the final result looking like:

Summary Thoughts

Actually creating an emWin GUI with the tools provided is very straightforward and for the most part, intuitive.  I’ve had no particular difficulties determining how it works as the manual is comprehensive and informative.  I didn’t use the Font Converter in the end as I didn’t think it necessary - I’m testing the Envision Kit, rather than emWin specifically - but it would be useful if there was a need for a specific font (e.g. corporate branding.)  My original intention was to pull the images off the SD card to test that aspect of the board but it’s not possible so the fallback is to use facilities in emWin to do this.  Converting images into a C-file representation was, again, very straightforward as the manual explains the process very well.

Now I have the basic structure in place, I need to solder on some headers so that I can start taking actual readings with the I2C interface and Analog to Digital conversions.  I’m still waiting for them to arrive, but once they do the LCD will need to come off and I will see how that goes.

Further Entries

I will update this entry to provide links to further instalments as I create them:

Part One: Introduction

Part Two: Getting Going

Part Three: Development Software

Part Four: Brief notes, first part

Part Five: Static Setup of the GUI

Part Six: Getting the Display Working

Part Seven: USB/Serial Interface

Roadtest review

Also, worth reading Jan Crump's road test as he's taking a more technical approach.