STM32F7 internal memory size and ugfx

[manoj]

Hi guys was able to compile and ugfx library and started to play with some of it's API

I randomly tried the gwinImageCreate and yes it works very well but I am little curious my Image "<my_image>.h" file is around 3MB but my stm32 flash is only 1MB but how could it fit into my board and flashed successfully.. 

 

There might only 2 possibilities occurred either you have done some compression (which likely no !) or your uGFX very well implemented already using my external memory on my STM32f7 board.. Can anyone clarify this part !

[inmarket]

Remember that .h files are c source code. The object created by a 3MB .h file is likely to be much smaller than 1MB.

The size in ROM will be the same size (plus a few bytes) as the original image file - not its .h representation.

[Joel Bodenmann]

@inmarket already mentioned one of the important things: The header file generated by the file2c tool contains a C-Array of the binary raw data of the file that you fed into it. The actual size of the object in ROM will be a lot smaller as it won't be a textual representation of binary data anymore (eg. think of all the commas in the array to separate the individual bytes. All of those will be omitted). Also, very large files usually get split up into multiple C-Arrays which leads to even more textual overhead that won't add any size to the object itself once compiled into a binary.

The GFILE module allows you to load data (and therefore images) from pretty much any source. One of those is the microcontrollers ROM through the ROMFS that we wrote ourselves. However, GFILE can easily interface other file systems such as FatFS that allows you loading images from an SD-Card. Everything is already in place to do that. The STM32F7-Discovery board you're working with also has a mass-storage memory connected via QSPI. It's also possible to interface that through GFILE. Once you managed to get your image through the GFILE API the rest of the library doesn't bother anymore so you really have a vast variety of possibilities where to load your image(s) from.
If things really get bad you can always implement your own file system using the USERFS interface of GFILE.

[manoj]

13 hours ago, Joel Bodenmann said:

@inmarket already mentioned one of the important things: The header file generated by the file2c tool contains a C-Array of the binary raw data of the file that you fed into it. The actual size of the object in ROM will be a lot smaller as it won't be a textual representation of binary data anymore (eg. think of all the commas in the array to separate the individual bytes. All of those will be omitted). Also, very large files usually get split up into multiple C-Arrays which leads to even more textual overhead that won't add any size to the object itself once compiled into a binary.

The GFILE module allows you to load data (and therefore images) from pretty much any source. One of those is the microcontrollers ROM through the ROMFS that we wrote ourselves. However, GFILE can easily interface other file systems such as FatFS that allows you loading images from an SD-Card. Everything is already in place to do that. The STM32F7-Discovery board you're working with also has a mass-storage memory connected via QSPI. It's also possible to interface that through GFILE. Once you managed to get your image through the GFILE API the rest of the library doesn't bother anymore so you really have a vast variety of possibilities where to load your image(s) from.
If things really get bad you can always implement your own file system using the USERFS interface of GFILE.

Alright, will try to get my sd card or internal flash working to load images. Thanks 

[manoj]

Can anyone tell where should I start to use GFILE and interface with FATFS on stm32 sd card ?, more on how to set up the diskio stuff

Edited August 5, 2017 by manoj

[Joel Bodenmann]

The diskio stuff from FatFS has nothing to do with µGFX. That's not something we can help you with. Usually the underlying system you're using provides a suitable implementation. All major RTOSs do that and I'm pretty sure that the CubeHAL provides one too. In any case this is completely outside of the scope of µGFX. GFILE just uses the high-level API from FatFS. The diskio stuff is on the other end of FatFS.

The best way to get this working is by creating a new basic hello-world project for your platform that doesn't use any other dependency (not even µGFX!). Then add FatFS to it and make it work. Once you have a working FatFS environment you can just put µGFX on top of it and enable FatFS in the configuration file.

[manoj]

Thanks Joel.. Yes cubemx provide one. doing my hello world interface with sd card