TheBackShed.com

Forum Index : Microcontroller and PC projects : ARMmite F4 - Memory Usage

Author

Message

erbp
Senior Member

Joined: 03/05/2016
Location: Australia
Posts: 195

Posted: 08:01am 10 Sep 2019

Copy link to clipboard

Print this post

I guess this is a question for Peter.

On the ARMmite F4 after a NEW command, MEMORY reports:

Flash:
0K ( 0%) Program (0 lines)
144K (100%) Free

RAM:
0K ( 0%) 0 Variables
0K ( 0%) General
114K (100%) Free

My question is - does using the LOAD file$ command use the RAM to buffer the program code before it can be saved into the Flash memory space?

Today I tried to load a program file and it reported a "Not enough memory" error. When I check in Windows the file reports reports either 112K or 113K (depending where you look) and the File Properties report an actual size of 115406 bytes.

Now the 144K available in Flash shouldn't have been an issue, so I assume the limitation came from the buffering in RAM. If this is the case, is there any way to utilize the additional 30K of Flash? If I had this problem on a Pic32 based Mite, I could shift some code to the Library, effectively splitting the program load process into 2 separate steps, but the ARMmites don't support the Library. Is there a sneaky way to get to use the full 144K of Flash?

Thanks,
Phil.

lizby
Guru

Joined: 17/05/2016
Location: United States
Posts: 3470

Posted: 12:05pm 10 Sep 2019

Copy link to clipboard

Print this post

erbp said does using the LOAD file$ command use the RAM to buffer the program code before it can be saved into the Flash memory space?

Are you using the latest version? I don't specifically remember the details, but a similar problem that I was having was fixed by a later release.

PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed

erbp
Senior Member

Joined: 03/05/2016
Location: Australia
Posts: 195

Posted: 07:43am 11 Sep 2019

Copy link to clipboard

Print this post

lizby said Are you using the latest version? I don't specifically remember the details, but a similar problem that I was having was fixed by a later release.

Yes, 13-Aug-2019 version. I have a solution to my load issue - I simply used one of the Standalone Crunch functions (there's one in TassyJim's MMEDIt and another in my MMConsole+ program & maybe more I don't know about) to reduce the file size. I was more asking the question from a future perspective - what if the code file ends up a bit over 113K AFTER it has been crunched. On current indications it looks like it can't be loaded, which also means that there is 30K of Flash memory that can't be used. What I was really asking is - is this the case or is there a way around this limitation? Maybe using a different load method like XModem upload via the console, or AUTOSAVE or something. Just looking for clarification.

As I mentioned in my original post, if this were a Pic32 chip where the Library is available, that provides a workaround to a limited degree at least, and probably not in a way that the Library was intended to be used. But hey, if you need another 5 - 10K to get your code to load you use whatever method is available.

Phil.

matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 10573

Posted: 08:21am 11 Sep 2019

Copy link to clipboard

Print this post

Quote which also means that there is 30K of Flash memory that can't be used.

16K of that is space for save variables and not relevant. I haven't implemented library commands because without CFunctions they give no advantage in space. i.e. a Basic routine in the library takes the same space as a Basic routine in the main code. Sorry but you are stuck with the 113K limit.

NB shorter variable names result in a smaller program at the expense of readability

erbp
Senior Member

Joined: 03/05/2016
Location: Australia
Posts: 195

Posted: 10:07am 11 Sep 2019

Copy link to clipboard

Print this post

OK, Thanks for confirming that, it's good to know these things.

Cheers,
Phil.

Print this page

To reply to this topic, you need to log in.