Migrating to uGFX for LPC3250 uP and HiMax display

[Joel Bodenmann]

Just add as regular attachments. Works like a charm: 

[Joe Stepien]

(Logged out, back in, reposted.  Screenshots via Greenshot software, copy to Clipboard.)

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?

[Joel Bodenmann]

2 minutes ago, Joe Stepien said:

(Logged out, back in, reposted.  Screenshots via Greenshot software, copy to Clipboard.)

As I said: If you keep having troubles just add them as drag'n'drop attachments as shown in my screenshot.

[Joe Stepien]

Attached a file.  What browser are you using?  I'm using FireFox.

 

uGFX_ForumPostWithImages.docx

[Joel Bodenmann]

3 hours ago, Joe Stepien said:

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.

MEMFS is fully implemented. RAMFS is just a playful thought. Nobody had ever any use for that. Why are you asking about that?

JPG images are a really bad choice for small embedded systems. BMP, GIF and PNG offer way better alternatives for almost all cases (again: on those platforms). I did write a µGFX wrapper for an existing JPG decoder once (a really good one!) and the performance is horrible and unusable for any embedded system that doesn't offer vasts amounts RAM and a very fast CPU. Unless somebody is really in need for a JPG decoder we don't plan to add it in the next couple of months. We can of course do that within just a week or two as a paid feature implementation. Alternatively you can always write your own implementation or take an existing one and just wrap it inside the µGFX image decoder wrapper.

Is converting the images of your existing GUI to a different format (not to say better suited in this case even) posing a problem to you? If it's due to the fact that you have lots of them: Nothing that a very simple shell script can't handle.

 

4 hours ago, Joe Stepien said:

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?

You can use any font that you have as a *.ttf or a *.bdf format in µGFX. There's a font encoder/converter that allows converting any font to be used efficiently with the µGFX library. That converter is available both as an online and as an offline too. You can find the online version here: https://ugfx.io/font-converter

 

I'm gonna let @cpu20 handle the IAR stuff.

[Joe Stepien]

Not familiar with what the intentions were with GFILE_NEED_RAMFS and how it might differ from GFILE_NEED_MEMFS.  Without diving into your code with a larger investment of time, was expecting MEMFS or RAMFS (seems more appropriately named for my expectations of what it might do) to be a file system that need not access external devices such as NAND.  Thought it might be a more straightforward approach to renderings from RAM rather than the somewhat convoluted example I attempted earlier (which didn't compile for other reasons).  Like I wrote earlier, we have an existing application that is migrating to a larger resolution display.  File system already intact.  Don't want to have to reinvent the wheel or use some other vehicle when what we have is more than sufficient.  All images imported to SDRAM from NAND whether they be .jpg, .bmp or .gif.  We currently don't have .png support in our GUI.

"JPG images are a really bad choice for small embedded systems."

Perhaps, but you are otherwise asking your user to convert their .jpgs, (a popular and ubiquitous format, arguably better compression) some of which are already deployed in the field to not-so-technical personnel.  We've found .jpg to be usable.  (User can customize the look of their control system to whatever images they have available.  Typically, .jpg.)  Way too much trouble to have them convert and then you're spending time on tech support.  We've used .jpg from the outset and yes, initially without the MMU enabled the rendering was slightly more than 1 second per 320x240 image.  Pretty slow and a user would surely complain about the system responsiveness.  uP is running at 208 MHz - already pretty much obsolete, but still fast enough.  This improved to about 8 frames per second with MMU enabled.  This alone was sufficient to appear responsive when having to re-render the display with another background/desktop but we kept our original video cache implementation of multiple double-buffered desktops anyway (our solution to the original slow .jpg renderings with MMU disabled), which kept desktop/screen switches fast with an occasional wait for the user for a video-cache miss.  Works well.  Migration to a larger 800x480 display, ie 5 times the size of 320x240, would pose responsiveness problems again with a large .jpg, even with MMU enabled, but we have sufficient SDRAM available to pre-render all such images to SDRAM (DDR rather than SDR of existing product) at start-up and thereafter just do a straight memory copy from SDRAM to LCD video memory in SDRAM.  Very fast (tens of milliseconds at most) and more than adequate, so .jpg does not necessarily pose a problem for a small embedded system.  We currently have only 256 kB of RAM and 8 MByte of SDRAM which I think pretty much qualifies it as a (contemporary) small embedded system.  (We keep our resources, RAM, NAND, power budget pretty tight here.)  New platform will be 512K of RAM and at least 64 MByte of DDR SDRAM, which is more than enough for our AV control system.

[Joel Bodenmann]

10 minutes ago, Joe Stepien said:

Not familiar with what the intentions were with GFILE_NEED_RAMFS and how it might differ from GFILE_NEED_MEMFS.

They are described in the documentation: https://wiki.ugfx.io/index.php/GFILE#File_systems

 

11 minutes ago, Joe Stepien said:

Without diving into your code with a larger investment of time, was expecting MEMFS or RAMFS (seems more appropriately named for my expectations of what it might do) to be a file system that need not access external devices such as NAND.

The RAM part in RAMFS really just means RAM. It has nothing to do whether the RAM would be internal or external.

For read-only access there's ROMFS. That's widely used and very well tested. It allows you to load files from the FLASH and due to how it's implemented you don't need to spend time fiddling around with the linker script. It outputs a simple C array that gets included in your binary by simply including the C array in your source code.
If you want to load something from an external memory then using FatFS will most likely be the most simple solution unless the memory is fully addressable. For FatFS we have a GFILE wrapper named FATFS that works both with a built-in version of FatFS that comes with µGFX or with your own external/existing distribution of FatFS. For everything else we offer USERFS where you can implement whatever you want. There are quite a couple of people using that interface and there are no known issues with that. If you have an existing way of reading and/or writing data to/from an external memory then you can just wrap the USERFS wrapper around that and you're ready to go. This way you can use your existing stuff and still use the high-level GFILE API and there's almost no overhead at all (everything is done with function pointers).

 

Regarding the JPG discussion: If your users supply the JPG files then that is obviously a very valid reason not to move to anything different. In that case you have still the remaining three options:

• You implement the entire JPG decoder in µGFX yourself
• We implement the entire JPG decoder in µGFX ourselves (we can get that done within one to two weeks, depending on how fast you need it)
• You take your existing JPG decoder and wrap it around the µGFX image decoder interface. That interface is well documented and as there are already four decoders available you have enough reference material. If there are questions you can always ask here on the forum or get a paid support plan. In either case we're happy to help wherever we can.

[cpu20]

In your provided screenshots you did everything correctly to include µGFX into your project. The conflicts you are seeing with the colors Red, Green and Blue are probably due to a redefinition in your application. Can this be resolved by renaming them in your application?
Are those the only problems you are still having when compiling with IAR? Because you should be really close now to get a successful build.

[Joe Stepien]

cpu20, will probably rename either the conflicting uGFX macros for Red, Green and Blue (RED, GREEN, BLUE) or the structure in existing GUI which uses them.  Thks.

Joel, RAMFS is not implemented yet and MEMFS alone still produces the compilation errors previously described, ie empty array error.  No documentation on MEMFS either.  Links to it but nothing there.  Will consider how to get around it with maybe USERFS.  Thanks for the help.

 

[Joe Stepien]

A bit further but errors on my attempt at implementation of altering video RAM address in our double-buffered video RAM scheme using uGFX functionality.  File with images attached.

uGFX_ForumPostWithImagesErrors.docx

[Joe Stepien]

Previously reported compilation errors due to gdisp_driver.h missing (gfx.h wasn't sufficient for the use below). 

Having got past that, had rendering errors of .gif files apparently due to typedef of uint16_t defined as unsigned int, a 32-bit in my IDE.  Changed to unsigned short, also changing int16_t to signed short rather than signed int.  (Had used gos_freertos.h as template for my gos_ucosii.h file.)  Now have some nearly successful drawing of GIF files with previously described method rendering images from RAM as below and altering the uGFX RAM draw address via the construct below that.

#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  

 

    ((fbPriv *)gDisplay->priv)->fbi.pixels = (void *)_VRAMAddr;        // Change video draw address.

However, the GIF images rendered are not the correct color.  What assumptions is uGFX making to have rendered in wrong color, an apparent composite of actual color and background?  I tried changing bgcolor from default of White to Black with same results.  Transparency issue somewhere?  Clicking on the .gif file in Windows renders the image in correct color.  How to correct?

[Joe Stepien]

Endianness of color palette?

[Joe Stepien]

Aha!

Changed below.

#ifndef GDISP_LLD_PIXELFORMAT
    #define GDISP_LLD_PIXELFORMAT        GDISP_PIXELFORMAT_BGR565 /*GDISP_PIXELFORMAT_RGB565*/    /*GDISP_PIXELFORMAT_BGR888*/
#endif

Renders correctly now.

[Joel Bodenmann]

Glad to hear that you managed to make some progress. Huge Thank-You! towards @cpu20 for providing the IAR configuration screenshots.