MicroPython Forum (Archive)

"Graphical application" will consume more RAM than other software.
Indeed, code should be tuned and optimized to consume as less RAM as possible.
However, what can we do if we are reaching the limit of available RAM on a PyBoard?

Is there a way to extend the RAM? (I do already seen some amazing stuff with the PyBoard, I would not be surprised to see it possible).
Should we switch to another board? (and which board?)

Thanks

Some of the Discovery boards (typically the ones with LCDs) have an external SDRAM.

Its probably possible to modify MicroPython to use some of that SDRAM, although I don't believe that anybody has done this yet. So you'd be making new trails.

Instead of having "real" additional RAM, which is as dhylands said rather tricky to add to micropython, one could add RAM as sort of "video-ram". That is you can save all kind of bitmaps, text, etc. in this external RAM. This for sure creates some limitation for the usage. But its kind of an often used practise.
Basically, it comes down to the point that you could also use "smart" displays which come with there own controller, RAM and ROM and hence remove the GPU-workload from micropython. If you do not like that... two micropython-based uC (one does the CPU stuff the other act as GPU with the display) are always better then one This even gives you the chance to work asynchronous.

@MCHobby If you have a choice of graphics device RAM usage need not be heavy. It depends on whether the driver needs to maintain a frame buffer. Some graphics controllers provide fast access to RAM on the display, see https://github.com/robert-hh/SSD1963-TF ... yBoard.git for an example.

@MCHobby: In addition to what pythoncoder mentioned. I did not test that yet for the SSD1963 controller. But it might be possible to use the part of the frame buffer, which is not needed for the actually displayed data, for other data. Other TFT controllers like the MD070 have several pages of frame buffers, which can be displayed alternatively. Then you can use the frame not actually displayed for data. The total memory on the SD070 is 8 MByte, on the SSD1964 it's 1.3 MByte. Still not a lot, and they use many I/O lines, if you do not want to connect a display. You could consider Serial RAM, but that works more or less like an external mass storage.
Regards, Robert

Roberthh wrote:@MCHobby:... You could consider Serial RAM, but that works more or less like an external mass storage.
Regards, Robert

This driver https://github.com/peterhinch/micropython-fram.git for ferroelectric RAM enables the device to appear as a mass storage device or as a byte oriented device. But this only goes a little way towards solving the problem.

As I see it there are two basic problems with expanding the RAM on the Pyboard, both of which stem from the fact that the processor bus is not available for use. Consequently connections must be either by a serial or parallel interface. So the first issue is bandwidth: serial interfaces are slow (2.5MB/s at best). Parallel interfaces are faster, but still very much slower than the processor bus.

The second problem is that whatever means you use to connect the RAM, there is no way (as far as I know) to incorporate it into the processor's address space so that it appears contiguous to system RAM. This is probably just as well, because having the system arbitrarily allocate fast or slow memory might have unexpected consequences.

My conclusion is that for graphics purposes the best solution is to use a controller which supports its own graphics RAM via a fast parallel interface. Where this option is unavailable (for example with e-paper displays) you are forced to create frame buffers in RAM: this limits the size of display which it's feasible to drive.