With this commit fb_alloc now takes hints to better decide which ram to
give (internal or sdram).
Only fb_alloc_all calls are given any hints right now as some of the
calls need as much ram as possible and will cause failures to happen if
a small amount of fast internal sram is returned.
Anyway, hints can be used to tune where things are placed by fb_alloc.
I also tested the firmware for about an hour to make sure there was no
stack leak.
Note that I prefer for fb_free() to still be called versus
fb_free_till_mark() doing that for you in the code.
For functions without this fix they will just free the entire fb_alloc
stack when an exception happens. For functions with this fix they will
only free up to and including the mark. Since there are no places in the
firmware where you could start building a second fb_alloc stack when one
is already in place this point is moot currently. But, if we do
something like that in the future the problem will have already been
solved.
Any new code or re-worked code should use the mark function.
File reading is runing ultra fast now. We're getting that SD card speed
the STM32 promised now. The file buffer commands have been updated to
alloc as much available memory to read as much of a file in as possible
now to speed up things. This works really great.
Note however, while the file buffer is active you have to use the file
buffer versions of tell and size. Spent a few hours on tracking down an
error related to not using the buffered versions.
Now you can just grab all the free ram in the frame buffer in one go.
This fixes problems figuring out how many lines to alloc. Will update line
op code with this new info later.