Francesco

Most recent activity

• strange behavior with RLE compression of flash new code

  @Francesco started

  • 27 comments
  • 6,758 views

  @Moray replied
• strange behavior with RLE compression of flash new code

  in General • 8 years, 6 months

  

  I'll explain, my question is: how do you calculate/estimate the amount of free space to use for variables? How changes this space when I choose what modules include/exclude from a build?

• strange behavior with RLE compression of flash new code

  in General • 8 years, 6 months

  

  @Sacha a little Off Topic:
  Now I'm curious, how have you reached 5100 available variables?
  I know that some modules (like graphics, hashlib, tv) can be excluded from a build, but how to assign this extra space to increase the available variables?

• strange behavior with RLE compression of flash new code

  in General • 8 years, 6 months

  

  As a company, we will publish all improvements made on your original source code, because we believe in open source philosophy and would work in compliance with it

  I'm happy that this problem isn't related to the compression features, unfortunately I'm using the Web IDE from chrome store.
  I will wait that the new version is published on the store

• strange behavior with RLE compression of flash new code

  in General • 8 years, 6 months

  

  I have tryed this
  http://www.espruino.com/binaries/git/com­mits/a5688ca49ad5b0512fc513b4a7919b3b627­486ec/espruino_1v81.149_espruino_1r3.bin­
  the software has been flashed without problems or warnings, but during his normal usage (when the script isn't at his maximum load) the free memory returned by process.memor().free is about 160 vars

  before 1v80 in this situation my script provide me about 236 vars as free memory

  this is very strange
  please, can you provide me more details about your compression mechanism?.

  compression of the source code, in a binary blob, is done after calling save() function, right?
  after a reboot a function is called to decompress the source code, when the espruino has decompressed the entire source code it keeps in memory the blob?

  I'm not able now to perform a complete test but I think is a proportional trend and this solution render useless my effort done to optimize the memory usage on my script

  build my own firmware it's a good idea (and my secret target :-) ) but for now I should to find more time for analyze and understand your software
  For now our devices are working well with standard firmware, but in the future I'd like to build a version with some functionality to manage regular expression

• strange behavior with RLE compression of flash new code

  in General • 8 years, 6 months

  

  If you are looking for a non GPLed algorithm you can also consider LZ4 as a candidate (more fast but using few memory during process)

  My perception about source code compression is that, on particular and huge scripts, this process renders more complex the search for a compromise between performance and memory management.

  I take as example a big script that I have completed recently that works without problems on an ARM STM32F103RCT6 and old firmware, but shows this warning (ERROR: Too big to save to flash) on latest version.
  Maybe my example can be a borderline case but I think is good to let to the developer a chance to optimize by hand his code.

• strange behavior with RLE compression of flash new code

  in General • 8 years, 6 months

  

  Currently the compression of the source code is done on ARM or with the IDE ?

  I think the compression of the source code during the flash operation should be optionally enabled/disabled (with a special instruction like echo/save)

  If you are looking for a good compromise between compression ratio and low memory usage you can consider the standard algorithm LZO which requires no memory buffer during the decompression process.

• strange behavior with RLE compression of flash new code

  in General • 8 years, 6 months

  

  I see some strange behavior with a feature recently introduced: RLE compression

  A complex and big (weight of js file: 19.6 KB) software that has been loaded and executed more times without problem on version 1v79, it returns an error with latest firmware (1v81):

  ERROR: Too big to save to flash (32796 vs 30716 bytes)

  however, after the flash, the script seems to be complete

• Memory optimization in the code

  in JavaScript • 8 years, 6 months

  

  thanks both for the reply, I have solved in other way that I'll explain:

  For my partcular case the core of the software is a function called at regular intervals, and I choose at boot time what function run (I have defined N function, one for each "mode").
  Considering that other N-1 functions will be never called I can safely delete it with

  delete MyOBJ.prototytpe.myfuncion
  

  before the chosen function is called

• Memory optimization in the code

  @Francesco started

  • 4 comments
  • 2,009 views

  @Francesco replied