steved

The nature of the png data format means that it's quite RAM-hungry (32K minimum, IIRC) and slow - something like a third or a quarter of the speed of decoding a gif. (And RLL-encoded BMP is the fastest I've found). You can add a memory on the FSMC bus; however it could potentially slow things up a bit during display updates. If Flash is OK to store your images, consider the 32F7 series - they can run about 30% faster than the F4, and have a QUAD-spi interface which speeds up access of flash memory. (And they have newer peripherals than the F4 - the I2C, for example, is the Mk 2 which is a lot better)

I think you'll struggle to get acceptable performance out of the 32F051 with that size of display - typically 800 x 480 pixels or thereabouts. Especially if you're wanting to write images to the display - decoding image files can also add a very significant overhead. As an example, I'm using a 32F407 at 168MHz, with SSD1963 connected onto the FSMC bus, and writing a 640 x 480 pixel .gif image takes nearly a second. Decoding a .png file takes substantially longer.

More likely, you are using code intended for ChibiOS 17.1.x - this is the latest, and is generally recommended over ChibiOS 3.x (IIRC, 3.x is now unsupported).

The previous advice may be correct for ChibiOS V2, but for V3 and later there's a different way to set stack sizes (and one of the names has changed), assuming your make file is based on the ChibiOS standard. At the top of the project makefile, simply add any options you want to override; for example I have: USE_LTO = no USE_FPU = no USE_PROCESS_STACKSIZE = 0x600 (Using SSD1963, I didn't find any need to increase USE_EXCEPTIONS_STACKSIZE - it defaults to 0x400

Your FSMC initialisation doesn't look quite right; for the SSD1963 I had the following as your lines 77, 78: /* FSMC is an alternate function 12 (AF12) */ palSetBusMode(&busD, PAL_MODE_ALTERNATE(12)); palSetBusMode(&busE, PAL_MODE_ALTERNATE(12));

I've got uGfx and Chibios running on the 32F767 - but with an SSD1963 on the FMC interface, rather than using the inbuilt controller. I'd got existing code running on the 32F407, and IIRC the main thing I had to do was resolve some memory caching issues. You should be able to prove whether caching is the problem by inserting the following line in main(), just after completion of halinit(): SCB_DisableDCache(); // Disable data cache for testing This disables the caching completely, and Chibios doesn't usually modify this at present. I also had to use the version of Chibios from trunk (rather than a specific release) to get processor support, and maybe one or two relevant bug fixes.

Depends on the underlying code, but it may be possible to define these macros as being functions rather than constants. (Has worked for me on other code). Then they can return appropriate values on demand.

GCC: (GNU Tools for ARM Embedded Processors) 4.9.3 20150529 (release) [ARM/embedded-4_9-br (It's the one included with Chibistudio 17)

GCC4.9 works fine. I'm not using the Discovery, but am using Chibios with uGfx on a STM32F767 Nucleo - there was some reason why I had to use the 'trunk' version of Chibi rather than the latest release. Can't remember for sure, but I think it was to do with F7 support. Certainly didn't have to do anything special.

If you only want one or two, ST do some Discovery boards which include a small TFT. An FSMC interface is certainly helpful on speed; to give you an idea, decoding and displaying a .GIF file on an 800x480 display using F4, 16-bit FSMC, SSD1963 takes of order half a second. Its also worth considering the F7; I saw 25-30% speed improvement. The ST Nucleo series are well worth looking at as a convenient way of getting a CPU on a usable board; and there are often pin-compatible boards with different processors on them (some F4s, and F7, for example)

To give you some idea of relative performance, I've just benchmarked display of a 640 x 480 image from .gif, .bmp (RLL-encoded) and .png. On a STM32F4 with 168MHz CPU clock speeds (in clock cycles) are: .gif - 114945392 .png - 298198420 .bmp - 59564728

Sounds as if the controller is never getting initialised

I'm using a display (displaytech INT070ATFT.pdf) where the backlight is controlled by PWM from the SSD1963, and that's well behaved and fully controllable. So maybe its a hardware issue.

I've used a makefile based on the Chibi-supplied one successfully, with all relative paths. (IIRC, I have had problems with absolute paths, though). Relevant section: CHIBIOS = ../../chibios VARIOUS = $(CHIBIOS)/os/various GFXLIB = ../../ugfx include $(CHIBIOS)/os/hal/hal.mk include $(CHIBIOS)/os/hal/ports/STM32/STM32F4xx/platform.mk include $(CHIBIOS)/os/hal/osal/rt/osal.mk include $(CHIBIOS)/os/rt/rt.mk include $(CHIBIOS)/os/rt/ports/ARMCMx/compilers/GCC/mk/port_stm32f4xx.mk include $(GFXLIB)/gfx.mk include $(GFXLIB)/boards/base/DDS1414/board.mk # your board (My board file is in a uGfx directory, but don't think I had any problem when it was in a Chibi directory)

If you use PE3 (as is the case in my example), you don't use PD11 for the display - you can use it for something else. There should be GFX_NO_DISPLAY_INIT TRUE in the board_SSD1963.h file - its needed with the Displaytech. I suggest you read its data sheet carefully - it automatically initialises itself with the correct parameters if you give it enough time after power up or reset. (My understanding is that timings can vary significantly even with different displays of the same size). Bear in mind that the files I have posted are ones I am actually using!

PE3 (which is FSMC_A19) is what I have connected to the 'Command/Data' line of the display. That's a bit important! (It is possible to use other lines, but then you have to modify the driver a little). The Displaytech units don't actually need you to set up the SSD1963 registers - you make sure you don't enable any of the signals to the display for about a second after power up or reset, and the display initialises itself. If you set GFX_NO_DISPLAY_INIT to TRUE (which it was in the original board_SSD1963.h) it disables the relevant bits of initialisation. The driver should then also handle the reset line correctly (although possibly that bit's not tested). Older versions of the displays had a hardware fault which meant it was best not to drive reset at all - to implement this, set GFX_NO_RESET_DRIVE to TRUE in board_SSD1963.h

If you do something with this, can I suggest calling it 'Special Redraw Mode' or similar, rather than 'partial redraw', to avoid giving the wrong impression? That perhaps makes it clearer that its up to the widget to do something other than a simple full redraw.

At least some of the compile errors were due to use of files intended for the Olimex E407 in a Discovery environment - notable the clock-related ones.

Two things. Firstly, I'm using Chibios 3.x (which is, strictly speaking, still in development, although very stable). There have been some changes in configuration files and core functions which may well not be accounted for in my board files, although uGfx has the necessary conditional compilation in its core routines. Secondly, the 'DDS1414' board directory is based on the Olimex STM32-E407. It includes the Chibios board definitions, assuming they are selected in your make file. There are some differences between this board and the Discovery; certainly some of the clock configuration values. I did actually start by using a Discovery, and I think the attached file contains the code I used. If nothing else, it should highlight some of the differences to you. Whichever configuration you use, you may need to adjust it to select the correct SPI port and/or a few of the FSMC signals (e.g. command/data select) DD_Special.zip

Mostly because the code which detects the change is in a relatively time-critical zone; also concerns about stack space.

Exactly what prompted this thread. Yes, its a very specific situation, where basically the redraw routine for the widget just needs to know whether to do a full or a partial redraw - it doesn't need any coordinate information or anything. I am displaying a value surrounded by supplementary information; when the value changes I need to update the value part of the displayed area. (The value change is detected within the widget). I could do this with several label widgets, so that the value field is independent, but that would take up a fair amount of RAM, since I could be using a fair number of these value display widgets. If I handle this within the widget, there's at least a theoretical possibility of doing a partial redraw when a full redraw is required.

Fair comment - maybe I have too long a memory - I can remember when every CPU cycle was precious!

Looks as if I never updated the ginput_lld_mouse_board_st_stm32f4_discovery.h file with the final code; I think it should be the same as the board-specific ginput_lld_mouse_board.h in the DDS1414 board directory. Incidentally, I'm using ChibiOS 3, but doesn't look as if that's a problem. Edit: Think the file for the Discovery used a different SPI port; have done an update as attached (but not tested it) ginput_lld_mouse_board_st_stm32f4_discovery.zip

Think I've found a way to achieve what I wanted, which might fit fairly well into ugfx: 1. I have a routine which detects whether a partial redraw is required (due to a value change). It triggers an update, thus: _gwinUpdate(gw); ((GHandle)gw)->flags |= GWIN_LAST_CONTROL_FLAG; // Have to do this after calling _gwinUpdate() 2. I added a line to the _gWinUpdate() routine: void _gwinUpdate(GHandle gh) { // Only redraw if visible if (!(gh->flags & GWIN_FLG_SYSVISIBLE)) return; // Mark for redraw gh->flags |= GWIN_FLG_NEEDREDRAW; gh->flags &= ~GWIN_LAST_CONTROL_FLAG; // Cancel any partial redraws RedrawPending |= DOREDRAW_VISIBLES; // Asynchronous redraw TriggerRedraw(); } 3. The widget redraw routine can then test the flags to see whether a full or partial redraw is needed: uint8_t fullRedraw = (((GHandle)gw)->flags & GWIN_LAST_CONTROL_FLAG) == 0; ((GHandle)gw)->flags &= ~GWIN_LAST_CONTROL_FLAG; I think there might be small potential for a timing race somewhere - unlikely to be a problem for me. One suggestion for integrating this better is to add a parameter to _gWinUpdate(): void _gwinUpdate(GHandle gh, uint8_t partial) { // Only redraw if visible if (!(gh->flags & GWIN_FLG_SYSVISIBLE)) return; // Mark for redraw gh->flags |= GWIN_FLG_NEEDREDRAW; if (partial) gh->flags |= GWIN_LAST_CONTROL_FLAG; // Cancel any partial redraws else gh->flags &= ~GWIN_LAST_CONTROL_FLAG; // Cancel any partial redraws RedrawPending |= DOREDRAW_VISIBLES; // Asynchronous redraw TriggerRedraw(); } ...then the update is a single call

Thanks for the reply. I was hoping there was a way to make uGfx handle a partial redraw in the same way as it handles a full redraw (partly to avoid delays/stack demands on the thread which identifies the need for a partial redraw) - as I understand it, that's not possible. I'll have a look at the graph handling.