SmittyHalibut/EleksTubeHAX

idea for optimization of images preload

falkenhawk opened this issue · 5 comments

falkenhawk commented

hi,
pardon me I am esp32/arduino noob and I have no idea how much ram is available there for use,
but I have an idea how to optimize images buffering, if only we can fit that in the memory.
Basically - always keep number "0" in the one buffer and swap other numbers in another buffer. (so we need to buffer 2 numbers, where 0 is always in-memory)
That way we might almost completely eliminate the lag when numbers switch on every second, because if I am not mistaken, only one digit changes every full minute to a non-zero number, the rest to the right is going to be filled with 0.

SmittyHalibut commented

Interesting idea. However, we don't even load the one digit into memory all at once. We load it from SD card one line at a time, write that one line to the TFTP, then load the next.

I haven't done the math to see how much memory this would consume, but my gut tells me that a 24 bit image wouldn't fit in RAM, never mind two at a time.

You MIGHT be able to make this work with smaller bit depth images, support for which has just been merged.

I personally don't see the load time as a problem, so I'm unlikely to attempt to implement this myself. If someone else would like to take a crack at it cough @falkenhawk cough I'm happy to review a pull request. ;-)

aly-fly commented

Hi @SmittyHalibut I was the one that added image preload function into the firmware. Note - it is not loaded from SD card, but from FW Flash. Simultaneous access for FW and data is slow, so I moved image loading from Flash to RAM into time segment when processor has extra time and can slowly load the next image. I like the idea of one more buffer just for Zero character, but I am clumsy with pointers, so haven't got the courage to do it yet :) Maybe will do it some day.

  • 👍1
SmittyHalibut commented

Note - it is not loaded from SD card, but from FW Flash.

Sorry, another project I'm working on uses SD Cards and I got confused. You are, of course, right. It's the SPIFFS filesystem.

aly-fly commented

There are a few other things that noticeably contribute to the lag and visibly jumping numbers.

  • MQTT transmissions in a single block.
  • Temperature sensor readout in a single block.

Those must be split into separate short actions, maybe by using a state machine. On the To-Do list. :)

aly-fly commented

Tested the idea of double buffers:

Linking everything together...
EleksTubeHAX.ino.elf section `.dram0.bss' will not fit in region `dram0_0_seg'
DRAM segment data does not fit.
region `dram0_0_seg' overflowed by 51736 bytes

Unfortunately, here is not enough RAM to implement this.

Alternatively It would be maybe possible by buffering "compressed" image from the SPIFFS as an intermediate step, to skip the lengtly process of fetching data from the seral Flash. And in runtime just unpack it into the buffer. However that would need to dynamically assign buffer size and in some cases (big 24-bit images) it would also run out of RAM.

Therefore I conclude it is not worth the significant extra effort that would require.