Migrating to uGFX for LPC3250 uP and HiMax display

[Joe Stepien]

(Posted the same subject late yesterday, 5/1/17, 5:47pm EST, but haven't seen it in forum.  Not sure if it's under review for forum or it's gone missing.)

Hoping to migrate to uGFX for our existing platform which is currently using GUI by another vendor.  Existing platform is LPC3250 uP with a HiMax 8238A display.  Pretty much just using the display bitmap, display text, set clipping rectangle, set/get context primitives for the existing GUI.  Driver is initializing the LPC3250 controller on uP.  Working with IAR Tools EWARM IDE.  Started to import the entire uGFX folder even though we'd probably only initially be using a fraction of it.  Is there a link or document somewhere that would smooth this transition?  Could we limit, for the purpose of getting something initially working, the code inclusion to just a few folders, eg src/gdisp?  Or is something more necessary?  What configurations do we need to be careful to include or set accordingly?  Would think that just writing a .png, .gif or .bmp to SDRAM (what we're currently doing) ought to be straightforward with uGFX, no?

Thanks for any help.

[Joel Bodenmann]

Hello @Joe Stepien and welcome to the µGFX community!

 

1 hour ago, Joe Stepien said:

Posted the same subject late yesterday, 5/1/17, 5:47pm EST, but haven't seen it in forum.  Not sure if it's under review for forum or it's gone missing.

We haven't found a previous post from you in our logs. There's also nothing to review. Not sure what happened there. We haven't heard of any other issue like that before. Let's assume that it was just a glitch or miss-click at some point. Please don't hesitate to let us know if you keep experiencing issues with this forum.

 

1 hour ago, Joe Stepien said:

Started to import the entire uGFX folder even though we'd probably only initially be using a fraction of it.  Is there a link or document somewhere that would smooth this transition?

The simplest way to add µGFX to an existing project is by using the single file inclusion mechanism. That allows you to add just one single file to your project instead of the entire directory which can become difficult and cumbersome to manage. This is documented here: https://wiki.ugfx.io/index.php/Getting_Started#Single_File_Inclusion
We don't have a step-by-step guide for IAR but we have one for Keil µVision which uses the same technique. You can find it here: https://wiki.ugfx.io/index.php/Using_Keil_µVision_5_MDK-ARM
That should definitely help you to get started.

 

1 hour ago, Joe Stepien said:

Would think that just writing a .png, .gif or .bmp to SDRAM (what we're currently doing) ought to be straightforward with uGFX, no?

Yes, it is    --> https://wiki.ugfx.io/index.php/Images#Examples
Follow the guide above to add the µGFX library to your existing project and you should be ready to go. Of course you have to read a bit of documentation. The µGFX library is very easy to use but very complex inside to achieve that (and other features such as complete portability). Unless you can use one of our ready-to-run projects you'll have to spend a couple of minutes to read through the various articles & guides that you can find in the wiki, some of which are linked above.

[Joe Stepien]

Thanks Joel for the response.  I'll be looking at doing this today.  However, I have a question.  I'm a bit confused at the contents of the gfx_mk.c file.  It references other .c files by use of a #include.  The last time I saw this was 30+ years ago when I initially migrated from (Turbo) Pascal (a God-send by Borland at the time, instead of the torturously slow mainframe with card input) to C and I used the #include as gfx_mk.c does.  Kind of raised an eyebrow when I ran it by some experienced C programmers.  Haven't seen such use since.  Apparently it works, but it stretches conventional wisdom a bit, no?  Presumably, this is a way around the lack of makefile capability for some IDEs.

 

Also, the contents of gfx_mk.c list a number of folders, some of which we don't plan on using.  The wiki doesn't specifically mention amending the gfx_mk.c to exclude folders/functionality that aren't of interest, but is this actually the case?  That is, we are primarily initially interested in gdisp functionality.  Exclude all other folder references in the #include of gfx_mk.c?  Or is the gfx_mk.c assuming that all the other folders and source should be included as well or are necessary to compile without errors?  (Trying would answer my question, but don't won't to have to backtrack and would like to get right up front.)

[Joel Bodenmann]

Hello Joe,

All that #include does is literally copying the contents of the included file into the file at the location of the #include directory. There's nothing that tells you that you can only include header files. In fact, you can include anything. If you want, you can include a word document, an MP3 file or some Java code. It's copy-pasting that the pre-processor handles for you prior to compilation.
However, I agree that it is somewhat unusual. Includes are indeed usually just used for header files due to how the software is usually structured on the source code level.
The reason for including the C files is exactly what you mentioned: This way we can provide a very easy way to pull in all the source code while automatically resolving all dependencies through the pre-processor by just giving the user one single file to include.
To summarize: It's uncommon, but it's completely fine.

You must not touch any parts of the µGFX library or the library source code structure. Copy the entire directory to your project and include the gfx_mk.c file. Everything you don't use (like some of the "modules" that you mentioned) will not be included in the compiled binary at all because the pre-processor throws them  out. You specify in your configuration file (gfxconf.h, there's an example/template named gfxconfig.example.h in the root directory of the library) what you want to use. Everything that is turned off will be thrown out by the pre-processor. For example: Let's assume you only want to draw raw strings, you don't need the window manager and widgets: Simply set GFX_NEED_GWIN to FALSE (which is actually the default) and the compiler will never even see this code.
You can find more information about all this and a complete list of all configuration options with explanations and documentation reference in the wiki.

Do not attempt to only include some files and directories yourself. You'll run into a lot of pain. Internally everything is structured to be optimized at pre-processor and compile time. You will not use a single byte of memory or a single CPU instruction if you don't explicitly enable the stuff in the configurations file. No matter whether the directories & files are in your project tree or not.

[Joe Stepien]

Hmm..this port/migration appears to be a bit more involved than we had anticipated.  This is primarily due to there being no RTOS support by uGFX for either our current RTOS, uC/OS-ii, or our projected RTOS for our new uP and platform which is anticipated, at this moment anyway, to be MQX.  We were hoping to just due a 'quick' proof-of-concept of migration to uGFX by using current project and appropriate GUI substitution (eg, replace GUI_BMP_Draw() of current GUI library with uGFX comparable) using our existing uC/OS-ii RTOS.  Having proved this, we would move on to MQX with uGFX.

From having looked at the compiler errors, which I assumed wouldn't be coupled to an OS, we'd have to provide appropriate gos_uCOSii.h and gos_uCOSii.c files for the port to uGFX GUI, correct?  Likewise, gos_MQX.h and gos_MQX.c for MQX RTOS.  We've only enabled GFX_USE_GDISP and GFX_USE_OS_RAWRTOS in gxfconf.h, the latter in an attempt to circumvent the compiler errors, but getting another.  Is there no facility to have GFX_USE_OS_NONE?   Is there a means to remove this OS dependency for the GDISP library or might we be inviting trouble in the future with updates?  Why is there such a dependency?  Any bitmap writing isn't cooperatively yielding execution, or is it?  If not, then it should just be a matter of RTOS, if it exists, possibly preempting the execution of bitmap rendering, but bitmap rendering is none the wiser should that occur.  A write of a bitmap to RAM doesn't necessarily require an RTOS after all.   At any rate, anyone have ports of uGFX to uC/OS-ii?  MQX?  Without wading into the code too deeply (I'm maybe ankle to knee deep at this point), can anyone provide a synopsis of the contents necessary in the .c and .h files with respect to the GDISP bitmap rendering functions?

[inmarket]

You always need some support functions. RAW32 is exactly that - support functions designed for use when there is no operating system.

In your case you need to turn off GFX_USE_OS_RAW32, GFX_USE_OS_RAWRTOS or any other GFX_USE_OS_xxx symbol and then add your own GFX_USE_OS_MQX. The required routines in your gos_MQX.h etc are well defined in gos.h and the api documentation and there are plenty of other operating system examples to copy from.

[Joe Stepien]

Ok, I seemed to have been able to jump through the RTOS port for uC/OSii by creating and modifying the respective files, which I've named gos_ucosii.c and gos_ucosii.h, in accordance with some of the other supported OSes.  Was able to apparently compile without errors w.r.t. OS(at least thus far) but I'm confronted with another compiler error with respect to the graphics/gdisp requirements.  Error reported is gdisp_lld_config.h can't be found as referenced in gdisp.h.  The content of this missing file is rather sparse and I'm assuming more errors will be generated as I incorporate and proceed.  However, I'm not sure I have a complete understanding as to what is required to make the gdisp port as painless as possible while being able to maintain compatibility with possible future upgrades of uGFX.

Our existing project for an LPC3250 processor has an LCD controller that is initialized on start-up.  Let's say, for the time being, that we keep that initialization (but please advise how we might need to change to incorporate into uGFX design).  Our current GUI thereafter uses essentially a frame buffer by pointing a _VRAMAddr to an appropriate RAM location.  All subsequent drawing operations are with respect to currently defined _VRAMAddr.  We then change the h/w scan address (on a vertical sync interrupt) to one of the two buffer locations to output to the display.  We change this as we see fit for double-buffered screen writes while also keeping a number of possible desktops/displays in a video cache in the same manner (had to add multiple desktops to video cache initially to circumvent slow .jpg rendering of 320x240 images by GUI when MMU was disabled).  Haven't been able to find the equivalent of this video ram address scheme for uGFX.  Is this done through the GDisplay structure?  Are there any other considerations other than GDisplay?  What modules of uGFX are necessary to effectively continue this scheme?  Which ones can be eliminated/ignored?

Thanks for your help.

[Joel Bodenmann]

Glad to hear that you are proceeding with this

Once you have a GOS port the best way is to disable all the modules in the configuration file (including the GDISP module). So make sure that all GFX_NEED_XXX such as GFX_NEED_GDISP are either set to FALSE or commented out (as FALSE is the default value for those). Try to compile a hello-world program (basically a main() where you call gfxInit() and nothing else). This way you can ensure that your build setup is working correctly. You can also run one of the GOS demos that you can find in /demos/modules/gos to ensure that your GOS port is working as expected.

Once everything builds and your GOS port works you can enable the GDISP module by setting GFX_NEED_GDISP to TRUE in the configuration file. The GDISP module is one of the modules that requires a driver to compile. The drivers can be found in the /drivers/gdisp directory. The best thing is to use the so called TestStub driver first. This is a driver that implements all the interface required to compile but has no implementations (so it doesn't actually to talk to hardware) but it allows to ensure that everything is building correctly.

Once you're this far it's time to either use an existing GDISP driver or writing your own. When using an existing GDISP driver you have to include the driver's source file in your compilation and the driver directory in the compilation/linking path. The various guides in the wiki explain how to do this.
GDISP drivers require a board file. Each driver has a file named board_xxx_template.h in the driver directory. Copy that file to your project and rename it to board_xxx.h where xxx is the given name of the driver. The board file is the place where you actually tell the driver how to talk to the display. It usually contains the SPI, I2C or parallel peripheral HAL function calls.

When I understand you correctly you're working with a setup that already has a working framebuffer. Therefore, you can use the existing generic framebuffer driver that you can find in /drivers/gdisp/framebuffer. You'll see that the board file for this driver is especially easy to implement as all you have to do is passing the pointer to the framebuffer in the board_init() function. However, don't forget to also set the proper olor/pixel format with the given #define at the very top of that board file.

An additional side note which you might just ignore in case of you don't know what I'm talking about: If your framebuffer is using a packed RGB888 or BGR888 format (24bpp) you have to use the latest repository master branch instead of the latest stable release as there's now an additional dedicated framebuffer driver for that. You can find more info about that in our latest blog post.

I hope that helps. Don't hesitate to ask when you have any questions.

[Joe Stepien]

I've now gotten as far as nearly linking the OS without failures.  The errors below are the two remaining, which I guess are not too surprising.  Hopefully, these are the last.

Not sure how to prevent this error since the apparent objection is that gfx.c is included in my project structure as is gfx_mk.c.  The two offending functions below are defined in gfx.c but then included, via the somewhat unconventional #include "gfx.c", in the file serving as a pseudo-make, gfx_mk.c, hence the errors.  Don't see a way around this other than perhaps excluding gfx.c from gfx_mk.c, but that was frowned upon in an earlier response, as it defeats the whole purpose of the xxx_mk.c facility. 

Presumably, the second #include in gfx_mk.c, #include gos\gos_mk.c, would introduce similar duplicate definition errors if I had modified gos_mk.c (I apparently missed this point - but it should be there, yes?) to include the reference to my newly created gos_ucosii.c file, which of course exists separately in my project, as does gfx.c.  Also true for any of the other xxx_mk.c files in gfx_mk.c, no?  What am I missing here?

Error[Li006]: duplicate definitions for "gfxDeinit"; in "C:\IAR Embedded Workbench\Flex-LT Project\XRAM\Obj\
gfx.o", and "C:\IAR Embedded Workbench\Flex-LT Project\XRAM\Obj\gfx_mk.o"
Error[Li006]: duplicate definitions for "gfxInit"; in "C:\IAR Embedded Workbench\Flex-LT Project\XRAM\Obj\
gfx.o", and "C:\IAR Embedded Workbench\Flex-LT Project\XRAM\Obj\gfx_mk.o"
Error while running Linker

 

[Joe Stepien]

Looks like only means to circumvent the errors above while maintaining the xxx_mk.c facility is to include the files in the project IDE but exclude all but the gfx_mk.c from the build.

Is this what is expected?  Makes compilation of individual files somewhat cumbersome without a complete rebuild.  If one wanted to compile just a single file excluded from the build (for whatever reason) then you'd have to un-exclude temporarily, at least in IAR EWARM IDE anyway.

[inmarket]

There are two ways of building uGFX. Including every source file in uGFX into an IDE is not one of them. uGFX is far more complex than that.

The first involves using the makefile which selectively builds the components/source it needs. This can be emulated in an IDE by picking the same files to build and including the same include path that the makefile does. Note however that is a difficult way to do things.

The second method involves adding just the gfx_mk.c file to your project (and nothing else) and the uGFX directory to your include path. We call this "single file make" and is ideal for IDE build systems. You will still need to add any driver source files and the driver directory to your include path. Single file make is also currently incompatible with some uGFX features eg pixmap. We plan to fix those incompatibilities in the next major release of uGFX ie V3.

[Joel Bodenmann]

Before we keep writing huge texts that are largely unnecessary and probably partially ignored: Could you please clearly state how you added the µGFX library to your existing project? As mentioned there are different ways to do that. The recommended one is to use the single file inclusion mechanism. The documentation to that has already been linked above. Are you using that?

[Joe Stepien]

Using single-file inclusion as you suggested earlier (as indicated by the Error reported above with gfx_mk.c) . 

Unfortunately, maybe your intimate knowledge of your system leads you to conclude that your wiki is clear and complete.  It isn't, as there is room for interpretation and details not quite complete.  But getting there slowly anyway.  If you have phone support then that might be easier than providing details in huge text exchanges or short, possibly numerous, text exchanges extending over days.  But phone support is apparently archaic nowadays, although we still do it.

Problems arose due to the unconventional use of .c references in #include.  (Have never seen a function(s) defined in a .h file either as with board_xxx.h, elsewhere?)  It may accomplish its objective but it causes other problems.  Excluding the source files from the project, as suggested apparently by the wiki, and just using gfx_mk.c then makes it impossible with the capabilities of an IDE to examine/peruse the code for an understanding of functions, structures, variables, etc, while also examining commenting (rather sparse), variable naming conventions (very cryptic), clarity of function naming and descriptions, use of Hungarian notation (none), etc, etc  The availability of source within project also facilitates later debugging should something go wrong or have the appearance of having gone wrong.  Not sure how the IDE might later falter, if at all, with this #include methodology.  IDE has had bugs before when overwhelmed with files.  Hard to say.  All of this would be paramount in a decision to migrate to uGFX, even after completing the port successfully.  (Remedied the lack of src files in project by importing the src but excluding it from the build, as I stated above.)

Will revisit the wiki and your earlier responses to see if we can read between the lines some more.  Progress has been incremental.  If we can't, then that will be it and we'll probably retain our current GUI which may turn out to be more cost effective than migrating to uGFX.

(Latest compilation errors occur on apparent lack of GFX_USE_GFILE definition, which was turned on by subsequent #error compiler directive, followed thereafter by lack of GFILE_NEED_RAMFS implementation yet.  Still some work away from what we thought to be a fairly straightforward port to draw an image imported into RAM as we do with our present GUI, eg GUI_BMP_Draw(pOffset, iDevX, iDevY), GUI_GIF_Draw(pOffset, uiFileSize, iDevX, iDevY), etc, where pOffset is offset in RAM.  Also lacking JPG support which would require conversion to .png for all our existing .jpg images.  A bit of coupling to unnecessary components.  Jumping through too many hoops and haven't even gotten to performance and reliability evaluation.  Abandoning the effort in favor of existing GUI.  Thanks for your help.)

[inmarket]

This is actually a very simple job. Look at the demos/gdisp/images directory. In particular pay attention to its gfxconf.h file.

[Joel Bodenmann]

Hello Joe,

Thank you for your feedback, we appreciate it.

I fully agree that being a developer of the library will definitely lead to a lot of bypassing when it comes to writing, reading and interpreting the documentation. I've updated my schedule to spent some time next week to improve the documentation. Setting up a µGFX project is definitely by far the hardest part of working with µGFX, mainly due to the fact that it has been designed to work with any system and any IDE.

We do offer both e-mail and phone support as part of a paid support plan. That's something that is simply unfesiable to do for free. We would have to hire 10 people and the phones would still be ringing non-stop.
Keep in mind that with this sort of stuff the person providing the support actually needs deep knowledge of the system itself, so we can't just get a couple of undergraduate students to do that for us during their semester breaks  

The last paragraph of your post mentions issues with the configuration file. Those are pretty simple to solve as they are simple that: Issues with the configuration. I'd recommend you to have a look at the various demos that you can find in the /demos directory. A good way to start is by running /demos/modules/gdisp/basics. Each demo comes with the appropriate configuration file. Additionally, there's the documentation for each option in the configuration file in this wiki article: https://wiki.ugfx.io/index.php/Configuration. The #errors that you're getting are actually good as they explain well (in our opinion, again: Probably room for improvement) what the problem with the mismatching configurations is.
The upcoming µGFX-Studio should help a lot here as it generates the matching configuration file automatically.

If you still have any questions, don't hesitate to ask. If you're interested in a paid support plan, please drop us an e-mail. So far we have definitely never encountered a case where the µGFX library couldn't be used in an existing project, no matter what system, platform, IDE or system in general. After all, that is the overall goal of the µGFX library.

[inmarket]

This discussion may also help...

 

 

[Joe Stepien]

Made one last attempt.  Below are some snippets of code attempting to replace existing image writes with that of uGFX.  Led to a number of compilation errors which also ended up producing errors on previously existing project files, perhaps due to some conflict with similar names in uGFX and subsequently required complete exclusion of all uGFX source to remedy.  We gave it our best effort, but alas...  In the end, our current GUI platform is perhaps just too different to allow a smooth migration to uGFX anyway.

#if TESTING_UGFX_LIBRARY    
#include "gdisp_image.h"
#include "gdisp_driver.h"
#endif


...

void CGL_SetVRAMAddr(unsigned int p_uiAddr)
{
  // This fn sets the parameter _VRAMAddr which is the low-level
  // drawing address of all subsequent GUI rendering.
  _VRAMAddr = p_uiAddr;
#if TESTING_UGFX_LIBRARY
GDisplay* gDisplay;

// ********* Kind of kludgy below to just get to compile as the structures below were in a .c file rather than a .h. 

// The changes to this fn are done in order to replicate our double-buffered, multiple video page/desktop cache/framebuffer which switches the

// RAM address for our existing GUI via a variable defined as _VRAMAddr.  Looked like only similar construction in uGFX

// (that we could find anyway) is to alter the RAM write address  via the gDisplay and pixels variable.  uGFX probably abstracts this capability

// into some type of additional display construction but that's much too difficult  to attempt to implement for just a feasibility study of uGFX.


typedef struct fbInfo {
    void *            pixels;            // The pixel buffer
    coord_t            linelen;        // The number of bytes per display line
    } fbInfo;
typedef struct fbPriv {
    fbInfo            fbi;            // Display information
    } fbPriv;

  gDisplay = gdispGetDisplay(0);
      // Was a graphics display returned?
  if (gDisplay == NULL)
  {
    // No.  Oops!  What now?
  } else
  {
    // Switch the uGFX RAM write address of the graphics display (really convoluted, no?).
    ((fbPriv *)gDisplay->priv)->fbi.pixels = _VRAMAddr;
  }
#endif  
}



...

void CGL_DisplayBitmap(unsigned int p_uiBitmapIndex, int p_iX, int p_iY)
{
  unsigned short *pOffset;
  unsigned int uiFileSize;
  unsigned char ucFileType;
  int iDevX;
  int iDevY;
  unsigned int uiWidth;
  unsigned int uiHeight;

  // This function displays the bitmap specified by the index at the specified
  // coordinates.
        // Is it a valid index?
  if (p_uiBitmapIndex != INVALID_BITMAP_LOOKUP_INDEX)
  {
    // Yes.
    // Fetch the image from look-up table.
          // Is this a pre-rendered image, ie drawn already in RAM elsewhere to
          // facilitate fast rendering?
    if (LIB_IsBitmapPreRendered(p_uiBitmapIndex) == TRUE)
    {
      // Yes.  Fetch the offset, width and height of the already rendered image.
      pOffset = LIB_GetBFTPreRenderOffset(p_uiBitmapIndex);
      LIB_GetBFTImageWidthAndHeight(p_uiBitmapIndex, &uiWidth, &uiHeight);
      ucFileType = BITMAP_FILE_TYPE_RAW;
    } else
    {
      // No, not yet pre-rendered.
      pOffset    = (unsigned short *)LIB_GetBFTOffset(p_uiBitmapIndex);/*BitmapLookupTbl[indx].pOffset;*/
      uiFileSize = LIB_GetBFTFileSize(p_uiBitmapIndex);/*BitmapLookupTbl[indx].uiFileSize;*/
      ucFileType = LIB_GetBFTFileType(p_uiBitmapIndex);/*BitmapLookupTbl[indx].ucFileType*/
    }

    iDevX = MAP_X(p_iX);   // Map to device coordinates.
    iDevY = MAP_Y(p_iY);
  switch (ucFileType)
    {
      case BITMAP_FILE_TYPE_BMP:
      {
#if !TESTING_UGFX_LIBRARY        
        GUI_BMP_Draw(pOffset, iDevX, iDevY);
#else        
  gdispImage myImage;
    gdispImageOpenMemory(&myImage, pOffset);
    gdispImageDraw(&myImage, iDevX, iDevY, 320, 240, 0, 0);
    gdispImageClose(&myImage);
#endif  
      }
      break;
      case BITMAP_FILE_TYPE_GIF:
      {
#if !TESTING_UGFX_LIBRARY        
        GUI_GIF_Draw(pOffset, uiFileSize, iDevX, iDevY);
#else        
  gdispImage myImage;
    gdispImageOpenMemory(&myImage, pOffset);
    gdispImageDraw(&myImage, iDevX, iDevY, 320, 240, 0, 0);
    gdispImageClose(&myImage);
#endif  
      }
      break;
      case BITMAP_FILE_TYPE_JPG:
        GUI_JPEG_Draw(pOffset, uiFileSize, iDevX, iDevY);
      break;
      case BITMAP_FILE_TYPE_RAW:
        CGL_RAW_Draw(pOffset, iDevX, iDevY, uiWidth, uiHeight);
      break;
      default:
        // Oops!
      break;
    }
  } else
  {
    // Not a valid index into look-up table.  Abandon the request.
  }
  return;
}

 

Edited May 13, 2017 by Joel Bodenmann
Using code box

[inmarket]

If that is your decision we are sorry we can't help you. From our side it is very hard to help when we don't have enough source code to really see what is happenning or even a list of the errors you are getting. We know that uGFX is used in many large scale projects.  It is not the simplest library in the world but that is because of its power, flexibility and versatility. 

If you are serious about a possible switch to uGFX we do offer one on one support on a commercial basis. We will even write the code for you on a commercial basis.

[Joel Bodenmann]

In the end this really is just about what @inmarket said: We don't have enough information to help you. It's difficult for us to help with little to no information at all. If you prefer support via phone that is possible as mentioned previously, however there it would be the same: We need more information.

There are numerous customers that are using the µGFX library with the IAR IDE. There are also a couple of community members. One that I remember particularly is @king2. Maybe he could help you resolving your integration issues and eventually writing a proper official guide. I'll bump him on Skype.

 

On 5/12/2017 at 21:51, Joe Stepien said:

In the end, our current GUI platform is perhaps just too different to allow a smooth migration to uGFX anyway.

Personally I feel like that is not the case. You're experiencing issues with the integration of a library in your existing project. That doesn't mean that the two systems are too different. From the high-level point of view they will most likely be very similar - especially when it's just about drawing shapes and images.

[cpu20]

@Joe Stepien : Maybe it's a good idea to start a new project to first get µGFX compiling correctly using the single file inclusion mechanism.

Here is what I did to get µGFX working in IAR embedded workbench:

- First start with a clean project and include µGFX in the Preprocessor include directories. For this right click on your project, click on options -> C/C++ Compiler -> Preprocessor
- Do this for Assembler also

- Next you'll need a gfxconf.h file. I made a directory Inc and placed the template found in "uGFX/gfxconf.example.h" into the directory. For this example I only enabled GFX_USE_OS_RAW32 and nothing else just for basic compilation.
- Repeat above steps to include the folder where you saved your "gfxconf.h" in the C/C++ Compiler and the Assembler tab

- Now add the "gfx_mk.c" to your project. IAR automatically includes it to build.

Compilation should now be successful. Now you can edit the "gfxconf.h" to include all the modules you want.

Let us know if you have any other problems compiling! (Please attach the full compiler output so we can see what exactly is going wrong while compiling)

 

[Joe Stepien]

(Re-posted since earlier post of content below seems to have disappeared.)

You seem convinced that this should work, so we've gone further.  Here's some more info which I hope should suffice on the failures. 

Here are some snapshots of my configuration in IAR:

Added the board_framebuffer.h and gxfconf.h files as per the next closest IDE instructions, ie Keil.

Note, as per Keil instructions, gfx_mk.c, gdisp_lld_framebuffer.c appear there.  Also note that although the entire library of uGFX has been added to the project it is excluded from the build.  uGFX source files, as explained in an earlier post, allows examination of code within the IDE for purpose of evaluating clarity, comprehension, notation convention, etc, etc.

Here is a snapshot of the added include paths:

I've attached my revised gfxconf.h.  Note that I had to at least choose one of the GFILE_NEED_xxxx, eg GFILE_NEED_FATFS, even though I don't see why it necessary to couple a file system when all images reside in RAM.   If I choose none then I received the first three errors below:

The first 3 refer to the following:

 

The last errors are apparently due to some conflict with already existing definitions.  Maybe you can provide insight to remove the conflict.  (looks like uGFX has defined Red, Green and Blue as macros, which is why I've grown accustomed to capitalizing all macro definitions.  This makes it easier to quickly determine whether a reference in source is a macro or otherwise.  Would probably have to change uGFX definitions or avoid compilation of existing GUI, in whole or in part.  Not sure we want to go there.  Guess it depends on outstanding questions further below.)

 

Lastly, should the preceding errors be surmountable, when do you expect to have support for .jpg rendering, GFILE_NEED_RAMFS and/or GFILE_NEED_MEMFS?  If .jpg support is not in the very near future then this whole exercise is moot anyway for reasons previously described.

Also, we have a number of existing fonts that we use on our project.  If we migrate to uGFX, can we expect the fonts to be supported?  We currently use Arial and Times New Roman.  I've attached a sample of the Arial font.  Do you support this representative font format?  Or can it be massaged into a format compatible with uGFX with a uGFX font utility program?

 

 

gfxconf.h

Arial8pt_ASCII.c

[Joe Stepien]

Looks like my copy and pastes of screenshots, although appearing in this portion of response, did not post.

[Joel Bodenmann]

Can you please try adding your screenshots using drag'n'drop or uploading them as attachments and then using the "+" symbol on the image/attachment thumbnail to add them to the post?
In case of you can't edit your post anymore (I think there's a 15 minutes limit or something) -> Just copy the contents, create the new post and I'll delete the previous one.

Never had issues with screenshots before. Also seems like it worked out well for @cpu20 and we haven't touched the board software since his last post with the screenshots.

[Joe Stepien]

(Try again.)

You seem convinced that this should work, so we've gone further.  Here's some more info which I hope should suffice on the failures. 

Here are some snapshots of my configuration in IAR:

Added the board_framebuffer.h and gxfconf.h files as per the next closest IDE instructions, ie Keil.

Note, as per Keil instructions, gfx_mk.c, gdisp_lld_framebuffer.c appear there.  Also note that although the entire library of uGFX has been added to the project it is excluded from the build.  uGFX source files, as explained in an earlier post, allows examination of code within the IDE for purpose of evaluating clarity, comprehension, notation convention, etc, etc.

Here is a snapshot of the added include paths:

I've attached my revised gfxconf.h.  Note that I had to at least choose one of the GFILE_NEED_xxxx, eg GFILE_NEED_FATFS, even though I don't see why it necessary to couple a file system when all images reside in RAM.   If I choose none then I received the first three errors below:

The first 3 refer to the following:

 

The last errors are apparently due to some conflict with already existing definitions.  Maybe you can provide insight to remove the conflict. (looks like uGFX has defined Red, Green and Blue as macros, which is why I've grown accustomed to capitalizing all macro definitions.  This makes it easier to quickly determine whether a reference in source is a macro or otherwise.  Would probably have to change uGFX definitions or avoid compilation of existing GUI, in whole or in part.  Not sure we want to go there.  Guess it depends on outstanding questions further below.)

 

Lastly, should the preceding errors be surmountable, when do you expect to have support for .jpg rendering, GFILE_NEED_RAMFS and/or GFILE_NEED_MEMFS?  If .jpg support is not in the very near future then this whole exercise is moot anyway for reasons previously described.

Also, we have a number of existing fonts that we use on our project.  If we migrate to uGFX, can we expect the fonts to be supported?  We currently use Arial and Times New Roman.  I've attached a sample of the Arial font.  Do you support this representative font format?  Or can it be massaged into a format compatible with uGFX with a uGFX font utility program?

[Joe Stepien]

Well, the retry obviously didn't work.  Image attachment thumbnail?