Hello [color=var(--color-user-mention-fg)][backcolor=var(--color-user-mention-bg)]@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.
hi, [color=var(--color-fg-default)]@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.
|
发表于 2022-1-19 09:48:13
发表于 2022-1-20 09:33:17
