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.

Endianness of color palette?

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?

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

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.

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.

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

(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?

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

(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?

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

(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

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; }

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.)

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.

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

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.

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?

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.)

(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.