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.