may surport extend spi flash? about guix

[jdeere5220]

To use extend SPI flash for glyph storage, does this require calling a custom function to read the glyph data? I will put this on our dev backlog, but I am concerned about the performance impact. I think we would need to implement some sort of glyph caching mechanism so that we are not constantly reading the glyph data from slow memory. Do you have any thoughts on that?

[yuntian365]

The function of reading and writing external memory is placed in the thread. I think it is acceptable for users. For example, touchgfx adopts this method. For users who have such needs, it can connect to a slower screen. For the refresh rate, you can consider making the read graphics and font data into a function pointer, which is implemented by the user, so that it has good applicability. Not sure what you think about this method.

[yuntian365]

Many chips have dma function, reading spi flash can also be very fast, of course, it is slower than internal flash

[jdeere5220]

Hello @yuntian365 ,

Thanks for your feedback. I want to be 100% sure we are on the same page. Depending on the hardware architecture, it might be possible to directly read external SPI flash through a pointer, or it may require invoking a hardware-specific routine to read the SPI flash data. So I want to know which situation you are requesting.

If the external flash data is directly accessible via a standard C pointer, I think that is well supported in GUIX today. You can generate binary resource file(s), and write that binary data file to your external SPI flash. You can then use APIs such as gx_binres_theme_load to dynamically build your resource table, and install this resource table using gx-display_theme_install. When you call gx_binres_theme_load, GUIX builds a table of pointers to your resource data, it doesn't copy your resource data (including your glyph data) to RAM or anything like that. So if your SPI flash is directly accessible I think this is a working solution.

If your SPI flash is not directly accessible, but requires a "ReadDataOverSPI()" type function to be invoked, that is the case that would require some work on our side (allow you to install data read callback functions) and probably also do some caching of the data so that we don't have to invoke ReadDataOverSPI() every time we want to render the glyph "e" (for example). Let me know if we are on the same page and I will write up a task for our dev backlog.

[yuntian365]

hi, @jdeere5220,
Thank you for your reply, yes, this requirement is applied to those spi flash that cannot be read directly through pointers. This kind of flash is not supported by MCU to read in a mapped way, and the resource data needs to be written by the user "ReadDataOverSPI()" to read, such as read_flash_byte(dev*, uint32_t adr, uint8_t *buf, uint16_t len) to read the required bytes, this read interface reserves a function pointer interface inside guix, if this If the pointer = null, it will be read by direct mapping, which is the current processing method of guix. If the user sets this pointer, then this function pointer will be used to read resource data from spi flash.
Similar applications such as: stm32f401rct, its internal flash has 256k, but the resource data of the application program will exceed 256k, and the space required by the code does not need to use up 256k, so the resource data must be put into the external spi flash, but unfortunately The thing is, this chip does not support the direct reading of the mapping mode by pointer, it requires the user to write a function to read the spi flash data, and currently guix does not support this method, similar chips such as some low-cost chips Such as stm32g0xx and the like, also do not have the mapping function, also need the user to write the spi flash function, as a product series, we certainly do not want to switch to other ui, if guix can provide this function, it is very worth looking forward to.
The user implements spi flash reading by himself, of course, it will be slower than the mapping method using pointer to read, but this application is originally used in projects with low requirements, and it is placed in the thread, the user will not feel too strong , the screen refresh rate is not high.