inmarket

Yes you can use that call to cheaply do scaled fonts. Note it just uses integer scaling so you get the normal pixel doubling artifacts. My experience is that doubling horizontally looks much better than doubling vertically. Note the UI1 and 2 fonts already have wide versions automatically included using this font scaling capability. The reason we don't directly embed true type fonts are multiple.. true type fonts require special curve drawing routines that are complex (large amounts of code) true type fonts are slow to draw they require large amounts of ram (for an embedded platform) they are generally bigger than our optimized fonts there may be IP and patent issues with the true type format Their only advantage is that they scale to multiple sizes easily. For these reasons we currently don't support true type fonts directly. We may add support in future but they will always be secondary and optional because they just don't perform as well in an embedded project.

Have you just tried using gwinMove? You should not need to call gwinRedraw. If that is not working the way you want it, the problem has to do with clip area generation. A normal desktop gui calculates an expose clip area and a new draw clip area. The expose area is redrawn by the parent container and then the draw area is redrawn by the widget. These areas may overlap. A desktop gui will perform clip intersection and then optimally draw the two regions. Unfortunately for an embedded gui (such as ugfx), the clip area intersecting can lead to complex shapes which requires dynamic memory allocation of the shape tables. This is expensive in cpu and ram usage and therefore not suitable for an embedded platform. As a shortcut to avoid these issues ugfx calculates the simplest posdible clip area which results in the parent being completely redrawn and then the children being redrawn. This causes in the flashing you mention. In general, for an embedded project it is uncommon for widgets to need to be moved so this simpler drawing algorithm is normally fine. One way you may be able to trick it to draw better is to mark the widget invisible, move it and then make it visible again. This may tesult in less redrawing.

Looking at the ILI9325 driver, I suspect that your initialisation sequence is not totally correct as the driver is commonly used and usually works without flaw. As you needed to alter the initialisation sequence, other than for bus width or scan rate and those sorts of issues, perhaps your device is not really a ILI9325 but a "compatible" chip. Once of the other ILI93XX drivers may then be a better fit for your hardware. This sort of problem is not uncommon. Another thing to try is - In the gdisp_lld_config.h file in the driver directory try commenting out the following settings... GDISP_HARDWARE_STREAM_POS and GDISP_HARDWARE_CONTROL If it works with those settings turned off then it is definitely a chip compatibility issue. If it doesn't work with those settings turned off then it highly likely to be an initialisation problem. In particular look at the scan direction registers as the difference between a circle and a filled circle has to do with setting a single point versus setting a stream of points to form a line. I suspect that your scan direction is reversed.

There is something broken with the ChibiOS V3 support for the STM32F7. As yet we have not been able to identify what is wrong. Compiling with ChibiOS V2 as a STM32F4 target works. Compiling with RAW32 as a STM32F4 or F7 target works. It is only ChibiOS V3 with an F7 target that doesn't. I spent nearly a week trying to find the problem but couldn't so I gave it up until I have more time (there is never enough of that! ) If you would like to try and find the problem we would be very appreciative. It has something to do with either the port initialisation sequence or the clock initialisation sequence in ChibiOS V3 as it obviously works perfectly with RAW32.

If you are after oscilloscope type functionality have a look at the GADC demo and the gaudio record demo. They both have a custom oscilloscope type widget that you might be able to adapt to your needs. The demo's even support multiple forms of trigger level. These custom widgets are not a "standard" widget because the implementation is very specific to the demo applications (and slightly different between the two applications). To generalise the oscilloscope widget for general use was considered too hard at the time so they have remained as code hidden away in those demos rather than receiving the glory of being part of the main widget set.

The standard uGFX window manager does not support overlapping windows as you have already seen. It does support containers but not overlapping child windows. To implement overlapping windows is very complex and adds significant RAM and speed requirements which is why it has not been done yet. Perhaps someone might want to take it on as a side project as the window manager is replaceable with a single API call. There is a work-around however. In your application when you get the event that says the button has been pressed you can manually call gwinUpdate (or is it gwinRefresh) on the slider widget that overlays the button. That will cause the slider to be redrawn. Assuming the redrawing issues can be worked around - the only way to give your slider "pass-through" focus to the button might be to mark the slider as disabled. That should make it not interact with the mouse/touch. The style can be changed for the slider so that the disabled state looks the same as a normal enabled slider. Whether disabling the slider is sufficient for the event to pass-through to the underlying button is untested. Normally you wouldn't want that to happen in a normal window manager but because in this case the window manager does not support overlapping windows it might just pass the event through. You would need to test that.

The refresh of the display is handled by the display controller and is therefore totally incapsulated within the driver. Altering the display refresh rate is done by changing the initialization sequence for the controller. There is nothing required in ugfx itself to refresh the display. That is actually the whole point in having a display controller - it handles all the refresh for you once you have initialised it.

Try other strategies first before trying to sync drawing to the frame as it slows down the amout of drawing that can happen.. If you do need to implement it then the simplest method is to change the driver drawing routines so that they poll the controller register that indicates when the refresh is in the vertical blanking period before they actually start drawing. As this is driver specific there is no api support needed in ugfx. It is just part of the driver implementation.

Fonts are typically stored in program space (they compile as static const structures) and are thus normally stored with the program in the flash. Because of this unless you have extremely small amouts of flash or are using lots of large fonts there is generally no need to relocate them into RAM. Note that fonts are already a compressed format (they are not stored as pixel images) so additional compression may not make as much a difference as you expect.

If you have placed the bmp into a ROMFS then you can use the normal image file open calls. ROMFS creates a virtual file system specifically designed for FLASH without any of the FAT file system overheads. Look at the demos/gdisp/image directory for an example. Alternatively you can use the memory image open call with a suitable pointer address however that is not the preferred method. Image caching uses allocated memory to hold an in memory copy of the image. This is very expensive in RAM usage and is generally not needed when retrieving from FLASH as these device as often just as fast (or nearly as fast) as RAM for reading operations. Image caching is really only useful when holding images on really slow devices like SD-CARD.

If I understand correctly what is going on it sounds like you are having bus contention issues with your framebuffer. It sounds from the text above that you are using the sym32ltdc driver or the framebuffer driver. Both of these rely on a section of RAM being dual accessed by the cpu and the display refresh controller. The symptoms you describe indicate that all the RAM bandwidth is being used by the refresh controller leaving little available bamdwidth for the cpu. The hint to thinking this is the problem is the line by line drawing behaviour when simply clearing the screen. This indicates a very slow drawing speed as even simple SPI controllers can draw without this sort of vertical line behaviour. If so there are only three things you can do to fix the problem: Increase the bandwidth available by changing the RAM and/or the FMSC settings to access it. Reduce the bandwidth of the refresh controller by reducing the screen size or lowering the refresh rate of the screen. Most refresh mechanisms replicate a TV like scan pattern. If so you can put a test for being in the vertical blanking interval before you do any drawing. Whilst this actually slows the cpu access it makes drawing happen between frames so it is less noticeable. Using pixmap that uses the same overstressed RAM will actually make things worse as you have already seen.

The code is actually correct. It sounds like you don't have the GFXLIB make variable defined properly.

Ahh, just noticed the new piece of information you provided... If you are using a Linux kernel framebuffer driver eg fbtft rather than driving the hardware directly then you should be using the Linux-Framebuffer code found in board/base/Linux-Framebuffer instead of the Raspberry Pi specific code which is all about drivng the Pi HDMI port. The Linux-Framebuffer code internally uses the ugfx generic framebuffer driver. In the board_framebuffer.h at the top you will see you need to define your pixel format and the fb device name. The pixel format defaults to RGB888 if you don't specify a value. This value must exactly match the mode of your Linux kernel level driver. If the Adafruit hardware and the Linux kernel driver run at RGB565 then you need to put something like: #define GDISP_LLD_PIXELFORMAT GDISP_PIXELFORMAT_RGB565 into your gfxconf.h file or in the top of your board_framebuffer.h If this is your situation, you probably don't need to worry about the SPI bus contention at all as the SPI bus is only used by the adafruit lcd to initialise the controller chip. Thereafter everything is done through memory mapping. In that situation the display is already initialised long before the touch starts running.

With regard to the contention and slow drawing during calibration - this is because calibration polls the touch screen as fast as it can and this is causing there to be no time left for the lcd display. Note this is only an issue during calibration as everything is timer based thereafter. The solution is to put a gfxSleepMilliseconds(1) just before the gfxMutexEnter() in the acquire routine in the touch board file. This will allow the LCD an opportunity to respond without affecting the performance of the touch very much at all as the touch really only needs to be polled once every 50ms or so even for really great responsiveness. There is also a timer associated with the poll whose period is set by the GINPUT_MOUSE_POLL_PERIOD gfxconf setting. This defaults to 25ms. Try increasing that period. Settings as high as 250ms should still give good touch responsiveness. Note that interrupt handling for all the touch controllers implemented so far is turned off in each driver (if implemented at all) as every controller we have tried to date has had serious bugs in the controller relating to the interrupt.

I am familiar with the particular board you are using as I have one myself. I haven't yet tried to drive the raspberry pi and the ardafruit display/touch together yet. The uGFX framebuffer does support RGB565 - in fact it is the most commonly used format pixel format for the framebuffer. The framebuffer is capable of supporting any non-palletised pixel format with 8 to 32 bits per pixel. The framebuffer driver is actually used by the raspberry pi HDMI display by default in RGB565 format! See boards/base/RaspberryPi/board_framebuffer.h Note that when running multiple displays there is no problem with the multiple displays having different pixel formats. In a multiple display situation the system pixel format is chosen separately from the hardware display formats and the hardware drivers convert the pixel format as needed. For efficiency it is however best to use a system pixel format common to at least one of the displays. For single display systems the system pixel format always matches the display pixel format. There are two problems that you appear to currently have... 1. The usage of the same SPI port by the lcd and the touch panel. This is solved using the aquirebus/releasebus mechanism described in the previous post. 2. The compile errors you are getting. This is caused by using the single file build mechanism along with multiple display functionality. The ONLY way to solve this if you want to drive both the pi HDMI display and the Ardafruit display is to use the makefile build method. Of course if you turn off the pi HDMI display you could continue to use the single file build mechanism. In conclusion, the problems you are seeing with "RGB565" and the pixmap errors are all related to #2 above. The problems to do with a single SPI port being used by the lcd and touch are related to #1 above. Pixmaps are really nothing to do with what you are trying to achieve here. They are only confusing the real issues. Please turn them off until you have the displays working properly and then only turn them on if you really want the functionality pixmaps provide. If you are still confused attach your project as a zip file and I will have a look but please make sure you have addressed the issues above first.

With regard to the bus conflict across the two device types (LCD vs TOUCH), the correct place to fix this is in the aquirebus/releasebus calls. The trick is not to really acquire access to the SPI which on some operating systems can be very slow, but to instead create your own mutex and use that to arbitrate access. In most situations that should be a lot faster as it is not having to reinitialise the hardware and mutexes generally have little performance hit unless a busy mutex is hit. eg.. Note the below is pseudo code. In your display driver board file: board_init() { .... gfxMutexInit(&myMutex); ... } aquirebus() { gfxMutexEnter(&myMutex); set your CS pin for display } releasebus() { gfxMutexExit(&myMutex); } In your touch driver board file: aquirebus() { gfxMutexEnter(&myMutex); set your CS pin for touch } releasebus() { gfxMutexExit(&myMutex); } Of course, if you are using a non-preemptive operating system (like RAW32) there is no need to have the mutex (unless you are using GDISP streaming API). It will all just work with just setting the CS pin appropriately.

The single file build doesn't support multiple displays yet or some of the other 3rd party library thunks (such as TinyGL). The pixmap code internally uses the multiple display handling and therefore doesn't compile with the single file build. To get this to work you will need to include all the appropriate individual ugfx files instead of just gfx_make.c. An easy way to do this is to use our makefile system. While this would be nice to fix it is currently not high on our development agenda as: there are alternative build methods that do work, it is actually quite complex to fix and, our development has a big backlog of other work.

Each display page is already a container.

The missing _sbrk symbol is an indication that malloc has been called by something. For example using the C runtime library rand () call will use malloc when using the gcc library. As these routines actually require malloc to work setting a stub symbol for _sbrk is not enough. If you have performed the checks above as per Tectu's post and the problem remains, you can define the symbol GFX_EMULATE_MALLOC as TRUE in your gfxconf.h (I think that is what it is called). This will cause stub replacement routines to be added for malloc and free using the gfx allocator.

The binaries in the repository have now been updated. Tectu will update the online converter in the next few days.

Sorry for the long delay, we have been very busy. The mcufont encoder is now fixed in the ugfx repository but for the source code only. We have not rebuilt the binaries yet or updated the online version. We will do that over the next few days.

It worries me that you needed to add those include files - it should not be necessary if everything is set up correctly. It could well be that they are a symptom of the problem. With regard to the hang when using the generic CPU code - that indicates that your compiler is not using the correct C runtime libraries for your processor. It VERY important when using the generic code that you use the correct library for the CPU eg. You can't use the C runtime library for the M4 if you are compiling for an M7. Even the type of floating point support in the library is important. Setting the CPU specific flag however replaces our reliance on the C library implementation with our own implementation. This CPU specific code has been written using GNU inline assembler syntax. The compile error you are getting could mean one of two things, either your compiler is not GCC compatible for inline assembler or, the compiler is set to compile for the wrong CPU as a compiler can't compile M7 code if its flags are set to use an M4 instruction set (as an example). Let me suggest that you remove the extra include definitions and try and sort that problem out first, then carefully check the CPU compile options for your project. A few other things to check: The STM32 library often changes in incompatible ways. The version we used was current about 3 months ago so make sure you are using a version at least that new. Make sure you are using the "Single File Make" method of including ugfx. In your project only add the gfx_mk.c file - it will include automatically everything else that is needed. There is a wiki article on creating a Keil project for the M7 - please check that article carefully for any differences As a last resort I think there is an example M7 ugfx project for Keil somewhere. If not Tectu can upload something if you ask him nicely. We definitely have the STM32F746-Discovery board running even the full widgets demo using RAW32 in a Keil project.

This is a bug caused by a misinterpretation of the standard with respect to the C constants or alternatively a bug caused by incorrect preprocessor mathematics. Which is happenning is not clear as the expression (1 << 32) could be being evaluated by the compiler or the preprocessor - the standard doesnt specify which. There are simple tests to find out which but that is not important for this discussion. Possibility 1 - Compiler evaluation... The compiler is supposed to do all rhs (right hand side) mathematics in the type that matches the lhs expression except where promoted to a different type by a sub expression on the rhs. For this expression the mathematics should be occuring in the same type as the srcflags as there is no explicit sub expression type conversion. In this compiler it is not doing that. Instead it is doing the constant mathematics (1 << 32) in the signed version of that type and then complaining about a sign bit overflow. This is clearly a bug. Possibility 2 - Preprocessor evaluation The preprocessor is supposed to evaluate in the "largest available numeric space". For a compiler that has any 64 bit support (and all do these days) that should be in atleast 64 bit mathematics. As such to generate the warning/error is obviously incorrect. Also, even for a compiler/preprocessor with only 32 bit support, the larhest available numeric space for non negative expression is a 32 bit unsigned integer so again the warning/error is a preprocessor bug. I suspect in this case the expression is being evaluated by the compiler. The solution is not to typecast the assignment but to typecast the macro definition ie #define GKEYSTATE_MISSED_EVENT (((uint32_t)1)<<32). The other way to work around this is to use the hex representation of the same value. For some reason this seems to trick some of these faulty compilers into treating it as an unsigned value (but not always). Note this compiler bug workaround is only required for the top bit definition.

The stm32f4-discovery was working with chibios 3. That however was a while ago. A few things have changed since then... 1. We have changed the driver used by the f429 ftom a specialist driver to a generic ltdc driver. 2. Chibios v3 api has changed (it is not yet a stable api product unlike v2) 3. The current version of the stm32 library has changed. 4. We have changed the make system for chibios3 but the f429 example probably still uses the old settings. Consequently it is not surprising that it does not currently work slthough i am sure the problems are small as it has worked in the past. The f7 board however has more serious issues and we have not yet got it working with chibios3 although it does work using raw32 and keil cmsis. That problem I think it is something to do with io init sequencing. That however is not the problem with the f4 board. We would love it if someone was to take the initiative and find any problems. Unfortunately as maintainers we have a lot on our plates currently as we are working on new often requested features (plus our normal day jobs) so leaving it to us vould take a while. We will help wherever we can.

The Mikromedia STM32 M4 board uses the ILI9341 in SPI mode (I think). If not the STM32F429iDiscovery uses that chip (but initialised in a strange way) in SPI mode. For the discovery board you can find that code in the board_STM32LTDC.h file as it is only used to initialise the display before the LTDC controller takes over. Although the code might be different at least the way it uses the bus should be the same.