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!