inmarket

Yes it was a free block merging problem when freeing out of order. This has now been fixed in the repository. Please try it and let me know how it works for you as I have done only minimal testing. The new code reduces the memory allocation overhead which should make it more efficient with RAM for small systems. On the other hand the new code is slightly slower when freeing memory. It also no longer maintains tracking of allocated blocks of memory.

This is looking more and more like a merging problem with out of order gfxFree operations when using the ugfx raw32 heap. The memory is probably not being leaked just not always being remerged when it is freed. In other words memory is getting fragmented. We will write those test programs and find out what is going on.

Check the ugfx directory /demos/modules/gwin/widgets. This demo contains a full demo of the windowing system and widgets.

Any of the ugfx demos will run under raw32 (or any other ugfx supported operating system). Thats the point of ugfx. It provides a portable environment for embedded displays.

Touch polling occurs using a gtimer. Gtimer uses a second thread so the touch polling is reliant on the gtimer thread getting cpu time. Raw32 is a non-preemptive scheduler. That means it will only change threads when gfxYield() gets called. gfxYield is called within any gfx sleeping or waiting routine eg geventEventWait and gfxSleepMillseconds. So the behaviour you are seeing is expected. If you want it to touch poll while you are doing other cpu intensive things you will need to add gfxYield calls periodically in your code so that the gtimer thread has an opportunity to run. Yes GDISP_NEED_MULTITHREAD needs to be set to TRUE because you are running more than one thread. If you haven't explicitly set it in your gfxconf.h you will probably be getting a compile warning telling you that it is automatically turning itself on. There is a wiki article on implementing raw32. There are only two routines that need to be defined - it is very simple.

Yes that is correct. In fact gfxThreadCreate is already being used internally by a gtimer thread so it must be working with the init you are currently using. When writing the FreeRTOS port we just had not had enough experience in FreeRTOS to be sure we were writing an adaquate init routine for all cases so we left it to the user. The warning message is also just what we gleaned from the docs so it may not be 100% accurate. As you are obviously much more familiar with FreeRTOS than us perhaps you would like to write the proper init routine so we can add it to ugfx? You can see what is required by looking at the ChibiOS code for example.

You havent updated all the source files from the master. i can see that your editor window is displaying the old version of gos_x_threads.c Please properly update your ugfx from the master repository.

The reason is that making something not visible must always be processed before making new things visible. Also the current window manager does not handle overlapping windows except as a parent child relationship. So in scenerio 1 when page 1 becomes invisible the screen is background filled. Creating page 2 then draws page 2. In scenerio 2 the pages are both visible, and both overlap but are not in a parent child relationship. This breaks the current display rules for the standard window manager. When page 1 is made not visible it is set to the background color and then anything visible in the original area is asked to redraw thereby redrawing page 2. This limitation is to keep code small and prevent unbounded memory use (as would be required for a full overlapping window window manager). Think of the situation where page 2 is smaller than page 1. In this situation without full region clipping support the way we do the redrawing is the only way to guarantee a valid screen. As your pages are 100% equivalent in size you may be able to fool the window manager into not clearing the area of page 1 and therefore preventing the issue you are seeing. To do that you need to fool the window manager that page 1 is no longer visible even though it is. The easiest way to do this would be to manually clear the visible and sysvisible flags in the window structure before destroying the page. That may be sufficient although technically it leaves invalid flags on the page 1 children. If that method is not sufficient you may need to also cycle through page 1 children and clear the sysvisible flag (but not the visible flag) before destroying the object.

We are working on testing programs for the heap. such programs are useful elsewhere too but we are very busy as you saw from the delay in getting to your original post. Can you please write a test that just allocates and deallocates the pixmap and doesnt make any access to it at all and let us know if you are still getting a memory leak.

I have done a full debug on this and found that it is allocating and freeing memory correctly. The memory leak that you found can therefore come from only one of two sources... 1. There is a bug in the allocator that is causing not all of the memory to be freed. For RAW32 this would be surprising but I will write a test program to make sure. I presume you are using the uGFX fixed size heap not the malloc based heap? 2. Of the two required allocations the first (and larger) allocation contains the display surface. The 2nd allocation contains the GDISP driver structure. It is possible that if the display surface is being written beyond the end that the allocation headers for the associated GDISP driver structure are being corrupted and therefore ignored when you try to free them. This would give a memory leak of somewhere around that 96 byte size. This however would be an application error not a uGFX error.

You are still not following Joels instructions to put the command and its arguments all on the one command line. I am not sure how we could possibly explain it more clearly. Perhaps someone else in the community would like to try explaining it?

Terminal = command line. This is not a gui application. It runs from the command line (or in unix speak - from a shell). Google will provide more specific answers on what a comnand line/terminal/shell is.

To contribute your driver just attach the driver source files in a zip file to this forum thread. Well done on getting it working

Whilst the framebuffer driver supports 32bit color pixels, uGFX itself currently has no support for alpha. Alpha is complicated and is outside the design spec for uGFX v2.x. Whilst we are considering adding support from the ground up for v3 or v4 that is not going to help you now. There are two possible solutions currently... 1. Nominate a color as your transparent color eg HTML2COLOR (0x000001) and then hack the driver so that whenever you see that color in the driver replace it with the real transparent color code eg 0xff000000; or, 2. If you use GDISP_PIXELFORMAT_RGB888 in both the driver and user color space you may be able to directly pass the alpha colors with the alpha bits set as uGFX won't mask the unneeded bits if there is no color space conversion required. You just won't be able to use the uGFX color macros to generate those alpha values. As the framebuffer driver stores 32 bits per rgb888 value anyway you shouldn't need to change the framebuffer driver.

gwinGetText ()

When you have your driver working please contribute it to the community as that will save the next person having to redevelop it. Also, from time to time we buy reference hardware so that we can maintain the drivers so if you would like to send us details (model #'s etc) on your display device (or even better an actual display), we can ensure that the driver is maintained into the future.

No. Framebuffers can be packed however your driver wants to do it. The generic uGFX framebuffer driver however only supports 8, 16 and 32 bit pixels. As an example, many of the monochrome drivers implement their own 1bpp framebuffer. In your case (assuming a fully packed framebuffer) 8 pixels will get packed into 3 bytes. So... #define BYTES_PER_LINE 42 ncolor = gdispColor2Native(color); pos = y * BYTES_PER_LINE + ((x / 8) * 3); switch(x & 0x07) { case 0: buf[pos+0] = (buf[pos+0] & ~0xE0) | (ncolor << 5); break; case 1: buf[pos+0] = (buf[pos+0] & ~0x1C) | (ncolor << 2); break; case 2: buf[pos+0] = (buf[pos+0] & ~0x03) | (ncolor >> 1); buf[pos+1] = (buf[pos+1] & ~0x80) | ((ncolor & 0x01) << 7) break; .... case 7: buf[pos+3] = (buf[pos+3] & ~0x07) | ncolor; break; } I am sure you can work out the rest of the switch statement or what happens if your display controller only partially packs the framebuffer.

With RGB111 the colors fed to your driver will be 0x00 to 0x07 regardless of its position. I would imagine that you will need to shift that value in your driver depending on its position in the resultant packed framebuffer byte. ie for (0, 0) packed MSB into the frame buffer that will turn into buf[0] = (buf[0] & 0xE0) | (color << 5) For (1, 0) it would be buf[0] = (buf[0] & 0x1C) | (color << 2) etc A lot also depends on if your framebuffer packs across byte boundaries or if it always byte aligns ie 2 pixels per byte and 2 unused bits.

There are a couple of ways to do this... 1. Set up uGFX so that it supports your color format directly, or 2. Translate the color format in your driver. To get uGFX to support your color format directly you need to look at src/gdisp/gdisp_colors.h You will see that a color format is composed from a color system eg GDISP_COLORSYSTEM_RGB or GDISP_COLORSYSTEM_BGR and a mask of the necessary info. eg. RGB565 is made from GDISP_COLORSYSTEM_RGB or'd with 0x565 indicating the number of bits in each color channel. So, a definition for GDISP_PIXELFORMAT_RGB111 would be (GDISP_COLORSYSTEM_RGB | 0x0111). Adding that one define would enable uGFX to fully support that pixel format. That define could even just be in your gfxconf.h file. Unfortunately only Grayscale and True color RGB and BGR color systems are supported. RBG is not a supported color system. Adding it would be possible - look around line 258 and make sure your new color system does not conflict with the existing color system values. The same change will also need to be reflected into gdisp_driver.h at around line 846. The 2nd option relies on using an existing supported pixel format and translating in your driver. This is not unusual or difficult and occurs naturally in a dual display system where the displays have different internal pixel formats. If you look at just about any existing driver you will see that the driver makes use of a function gdispColor2Native(). This translates the user pixel format (as defined by GDISP_PIXELFORMAT) into the driver pixel format (as defined by GDISP_LLD_PIXELFORMAT). Whilst for single display systems these values are equal therefore making gdispColor2Native() effectively an empty function, there is no system requirement for this to be the case. For example, your user code may set GDISP_PIXELFORMAT to RGB888 but the display itself might actually run RGB565. So putting this together, you could use a supported pixel format at the user level and then manually translate that pixel format in your driver to the format your display actually needs. Because framebuffer bit packing occurs at the driver level you don't need to worry about any of the uGFX packing functions (in fact those functions have never been used and will probably disappear in the future). Pixels are always fed to the driver "unpacked" in user pixel format. I hope that helps.

There are two likely reasons... 1. When you output the 16 bit word you are outputting the bytes in wrong order. This is the most likely issue. 2. Your color format is really bgr565 instead of rgb565.

Wow - that one was tricky to find! A nasty little multi-threading issue. The problem came down to the event buffer management and a small window of opportunity created by the code to detect multiple threads trying to call geventEventWait() on the one listener object. The bug was most obvious when calling gventEventWait() with TIME_IMMEDIATE because that polled that code the fasted. I took out that checking code for multiple threads on the one listener, simplified, simplified, simplified etc. The new code is now much simpler and doesn't have the same problem. There is one tiny downside compared to the old code, it doesn't error check for multiple calls to geventEventWait() on the one listener object by different threads. In practice, it is now safe to do so provided the implicit geventEventComplete() call in geventEventWait() doesn't cause problems for the application by releasing of the event buffer while the other thread is still using it. Thanks for bringing it to our attention and sorry it took so long to get to it. The updated code is in the repo.

Thank you for finding that out. As you might have gathered I have been very busy at work (14 hr days) so i have not had time to look yet. Fortunately the current deadline is nearly there Can I please ask you to put together a small sample Win32 program that demonstrates the problem? It makes it much easier to find in a short space of time.

You are exactly right. They are toggles! As you saw they are turned on automatically if you turn on the toggle sub-system. You don't need to update any board file. I think from memory 4 emulate on-off switches and 4 emulate momentary on buttons. That arrangement can probably be changed in the Win32 toggle driver (which is part of the Win32 gdisp driver for obvious reasons). From memory they are just assigned as toggle 0 through 7. If you need more detail let me know and I will refresh my memory

Where are you loading the image from and what type of image is it? As ugfx decodes inline as it displays, a slow storage can mean slow image displaying. There are three sutions to the problem... 1. Put your image in fast storage eg using ROMFS. 2. Use gdispImageCache() to cache your image decode in memory (if you have enough RAM) 3. Create a pixmap, draw the image to the pixmap and then bitblit the pixmap to the screen whenever you want to draw the image (again this requires you have enough RAM to store the de oded image in RAM)

Based on that output please run the demos/modules/gos/threads demo and verify that threading is working correctly. I suspect that although it has compiled that basic threading is not working due to bugs in the Keil C library and this would certainly cause a blank display.