Could this also be an issue for the configuration load & save as well.If I recall correctly conf.c uses read & write on the conf data which will be in cached memory.(Don't have the source with me now so I can't check it.)Phil.
A thought - would a reasonable fix for this be to simply or the 'uncached' memory bit into the addresses passed into the 'read' and 'write' wrappers (inside the wrappers themselves)?This way read and write work on uncached memory regardless of what the calling code is using.Phil.
read(fd,&foo,sizeof(foo));if(foo == 1)...
foo = 1write(fd,&foo,sizeof(foo));
Isn't the difference between the malloc and umalloc addresses just the uncached bit (as far as the calling program is concerned)?
This also raises the question of whether we need a version of umalloc/ufree for exmem (otherwise all the umalloc memory will be in the Canon heap instead of the exmem heap).
If you use umalloc for the entire loading process, and then use the cached address later, that would probably be OK, just because a lot stuff happens between loading the font and actually trying to render characters.
We don't use a whole lot of umalloc, and we tend not to hold onto it very long. I wouldn't worry at this point.
It seems to work today for most people (with malloc) so I'd say the time between loading the font data and using it is long enough to avoid any issue.
The current rbf_font code only does one malloc and one read so changing this to umalloc; but using the cached address for access to the font data can't make it any worse
The font data is kept while CHDK is running - perhaps if exmem is enabled we can use umalloc and read then get another buffer using malloc (in exmem) and copy the data. The umalloc buffer can then be released.
Started by bob c General Help and Assistance on using CHDK stable releases
Started by pkasperskyi AllBest's Builds
Started by lemongrass Feature Requests
Started by philmoz General Discussion and Assistance
Started by srsa_4c « 1 2 » General Discussion and Assistance