Driver memory consumption - measure object memory usage on the PyBoard

[mchobby]

Hi Roman, I did dig a bit into memory consumption on the PyBoard. I identified that register.py is eating as must memory than a font (1850 bytes). There should be a way to spare RAM over there

How to mesure memory consumption

>>> import gc                                                                   
>>> gc.collect()                                                                
>>> b = gc.mem_free()                                                           
>>> from registers import regs                                                  
>>> gc.collect()                                                                
>>> print( 'Mem consumption: %i' % (b - gc.mem_free()) )                        
Mem consumption: 1856 

Second method (by looking the allocated memory

>>> import gc                                                                   
>>> gc.collect()                                                                
>>> b = gc.mem_alloc()                                                          
>>> from registers import regs                                                  
>>> gc.collect()                                                                                                             
>>> print( gc.mem_alloc() - b )    
1904

Not possible to extend the PyBoard memory

I did wonder if it would be possible to append some RAM module to the PyBoard (I would not be surprised of this, PyBoard is so powerfull).

Unfortunately, it is not possible. Anyway, the thread was really interesting.

• PyBoard: is there a way to expand physical ram on Pyboard

  Resources

• french article

[ropod7]

When using interrupts, pyboard use full stack, unreal to run a lot of processes, but we must to do it. It full of stack with interrupts, just using divides by floats.

I tryed yesterday to collect garbage manually, unfortunatelly - same result. Scales in 23 pixel fonts are useless.

[ropod7]

But this feature is added. I will upload new version soon, when I get perfect result with mem read.

[ropod7]

In theory, we may extend RAM. But we must look forward at interface connected to the pyboard. Both of SPI interfaces are used by LCD and touch screen panel (if we have not solution place both of them to the one SPI using interrupts). Than we have at least 1 I2C intetface. Than we may use low cost RAM module. http://arduino-related.livejournal.com/1414.html

[ropod7]

https://github.com/robert-hh/SSD1963-TFT-Library-for-PyBoard/tree/master/fonts

There is using interesting approach. We may try to decode them. )

[mchobby]

They are storing their font into literals.

bytes = b'...' literals = a sequence of octets (integers between 0 and 255)

Personally, I would be in favour of using font as a "ready to use binary format" stored inside a file (not in a literals in memory). And then, draw the characters by using file seek + byte reads. This would be slower because this serialize the reads of font data (8 to 24 bits each char's column) from the Flash (or SD Card)... but this would also dramatically reduce the RAM usage since we are not storing the font definition in RAM anymore. This would even allowing usage of many fonts at the same time.

Appending a RAM chip would have exactly the same effect... data stored inside the RAM would be serialized anyway. Pyboard is not able to manage the additional RAM, our code will have to manage reading and writing. So using RAM chip (in read-only) is fairly identical than using a file.

[ropod7]

It's true.

[ropod7]

I don't know, is it new firmware version or gc.collect() approach, but images rendering from cache ultra rapidly now: https://youtu.be/8ldq2wrreAE

[mchobby]

Woaw... impressive!

I guess that transferring the image data from the file certainly consume lot of memory... since the script is working heavily then the Pyboard would not collect memory frequently... which surge the memory... then slow down data transfer and operation operation (because of memory overload and allocation operations). By activating the gc.collect() you freeup allocated memory yourself... that can be reallocated immediately which finally have a positive impact on the overall software operations.

[ropod7]

Look, there in micropython change log page: lib:

• fatfs: add support for sector sizes larger than 512 bytes http://micropython.org/resources/micropython-ChangeLog.txt Before was limit of 512 bytes im my reading from SD card. Now it more than 240*80.

It near of video rendering, friend!

[ropod7]

And there is stack should be larger. Have you tried it? Which version of firmware are you using now? My version now is: v1.7-49-gdf3b174

[mchobby]

I'm still using V1.6 at the moment.

[ropod7]

And rendering coming well with this new type of renderBmp method?

[ropod7]

Or for shore with new type of _render_bmp_cache method. But there you will download full lcd.py file. There is many changes.

[mchobby]

I would update shortly.

[mchobby]

I did get the latest version of your code which is running on MicroPython v1.5.2 . I cannot do a fillMonocolor() because it want to allocate 15361 bytes. Do we really need to allocate so much memory? (in this case)

I will try to update my FirmWare

[ropod7]

there is portion sets as 10. Try to update firmware and set portion as 16. It's better value. I will pull new one version in there.

[ropod7]

There would be short strings in raising exceptions, They all take a lot of allocation. We must exclude all doc strings as well to.

[mchobby]

There would be short strings in raising exceptions, They all take a lot of allocation

I agree

We must exclude all doc strings as well to.

May I propose to move the docstrings into the github wiki? It would be a pitty to lost such valuable information.

Meurisse D. (Gérant) MC Hobby SPRL Service R&D et support

Le 18/04/16 19:15, Roman Podgaiski a écrit :

There would be short strings in raising exceptions, They all take a lot of allocation. We must exclude all doc strings as well to.

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/ropod7/pyboard_drive/issues/25#issuecomment-211481648

[ropod7]

May I propose to move the docstrings into the github wiki? It would be a pitty to lost such valuable information.

Yes, shore.