Is there anyway to find out how much space your current code is taking up?
Or does “[Status] Downloading new code; 0.68% program storage used” tell you it’s using 0.68% of the 64KB available on the spiflash, or is that something entirely different.
imp.getmemoryfree() will give you the free RAM size in bytes, but you need to know how much there is in total.
Memo for the impOS team: add imp.getmemorytotal() to yield the running imp’s total RAM, or imp.getmemoryused(). Either would do.
There’s two different things.
As Tony says, imp.getmemoryfree() returns the free RAM size in bytes. This is where all your Squirrel variables (and dynamic data, e.g. tables and non-literal strings) live. The total RAM size on imp001-002 is 128K; on imp003 it’s 192K. You don’t quite get all that in Squirrel, of course, as a certain amount of overhead is used by the imp itself for TCP buffers and so on.
The percentage reported as “program storage used” is the percentage of the allocated flash storage that your program code (and static data, e.g. constant strings) takes up. On imp001-imp003, the flash sector allocated for Squirrel is 128Kbytes in size.
There’s no need to implement an imp.getmemorytotal() field for the RAM size, because Squirrel can work it out itself (by first working out what type of imp it’s running on).
Peter
Yeah, I really need to get the old ‘load code from hard drive into RAM’ metaphor when thinking about the imp.
Well, don’t ditch that idea completely – imp005 will work like that. On imp005, the Squirrel code is stored in external SPI flash, encrypted, so it does have to be loaded (not even demand-paged) from external flash into internal RAM before execution. Same goes for the improm itself, for that matter.
So these are the breaks on imp005: the Squirrel code storage area is 256Kbytes, and the total RAM size is 2Mbytes, but the whole improm and the Squirrel code have to be loaded into RAM, so a “mere” 1,400Kbytes or so are available for Squirrel data.
Peter
Okay great in terms of the flash storage on the imp003 then.
“With the imp003, you must fit at least 512KB (4Mbit) of SPI flash. impOS takes seven-eighths of that (448KB), and the rest (64KB) is available to Squirrel as hardware.spiflash.”
So say you have 4Mbit of SPI flash, is the 128KB part of the reserved 448KB that impOS takes?
On imp003 the Squirrel bytecode is kept in internal flash memory, not on the external SPI flash.
Peter
Understood. Thanks
I note that my imp005 reports 33% of code space used now. I could have sworn it said 4% for the same code a few days ago. 33% fits with my expectation is total Squirrel is 256K. Is there a possibility that it could have been higher, or was that a mistake?
I suspect that was an incorrect calculation on the server side for imp005 devices. Any ideas when you’ll be bumping up against 100%? 
(note that imp003, on release 34, also has 256kB of code space, which will help with deploying common applications… we don’t have the ability to enable that for 001/002 though)
I suspect that was an incorrect calculation on the server side for imp005 devices.
It was. We were incorrectly using the RAM size, rather than the flash size, for the calculation.
Thanks for answer. @Hugo I have bumped up close to 100% , but I’ve taken to moving functionality from the device to the agent to conserve space and RAM. This is a tradeoff though. The extra 128K of code space will certainly come in handy for supporting some advanced functions.
This leads me to my next query.
We have migrated our development products from the imp002 to the imp003. I have been running them on the same model as the 2 imp types are ostensibly the same as far as our application is concerned. However, it wouldn’t make sense for me to have them on the same Production Model if the imp003 were to suddenly have all that extra code space. I currently don’t have any imp003 production devices (but shortly will). Would we be trapped if we were to put them onto the same model as the imp002s? As a matter of good practice, I guess we should look to create a different production model for each product with a different imp type. Thus, it’s good to know early that the imp002 and imp003 will diverge. I assume that there is no (API exposed) way to change production model once a device is in the field?
You really ought to bless them to a different model for this reason, yeah, even though this year there will be a way of assigning different code to subsets of each model.
We didn’t plan 003 to diverge on code space, but customers have been writing bigger and bigger applications over time, and we’d kept a little of the SPI space reserved for just that eventuality. The new map in release 34 also gives us more space for impOS features