 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : It's that MM+ E100 with "Not enough memory" - again !!
| Author | Message | ||||
| Bowden_P Senior Member  Joined: 20/03/2019 Location: United KingdomPosts: 162 |
Hi everyone, This is another request for information about memory needs of the MM+ E100. My last post was about how much memory was required for the Interpreter and how to reduce program memory usage, and all posts were very helpful. Many thanks. This post however is about the SD card instructions. My program memory requirement shows :- > memory Flash: 72K (75%) Program (2947 lines) 1K ( 1%) 1 Embedded C Routine 1K ( 1%) 8 Saved Variables (210 bytes) 22K (23%) Free RAM: 37K (40%) 393 Variables 42K (45%) General 12K (15%) Free > "OPEN"ing a file for "READ" in the program works OK, and I can display text from the file, but if I try to list the SD card files at the command prompt I get :- > files Error : Not enough memory > Typing "clear" gives :- RAM: 0K ( 0%) 0 Variables 42K (45%) General 49K (55%) Free > but still no success with "files". Doing a "CPU RESTART" clears all the RAM, and then "files" is successful. I'd be grateful for any help with 2 requests :- 1. Can anyone tell me how much memory a "files" instruction requires? 2. Is it possible to see the "files" output from within my program? With best regards, Paul. Nothing so constant as change. |
||||
| lizby Guru  Joined: 17/05/2016 Location: United StatesPosts: 3011 |
Don't know if this relates to your problem, but if you have gotten a "not enough memory" error, then subsequently FILES will give the same error until you issue NEW or power cycle. (In my experience with other platforms--I don't have an E100.) PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
| Bowden_P Senior Member Joined: 20/03/2019 Location: United KingdomPosts: 162 |
Hi Lizby, Thanks for your interest. Doing some experimental listing, it seems as if "files" doesn't like to intrude on whatever has already used the "General" memory area. With a clear RAM, if I hit Ctrl-C while "files" is listing, I have seen memory show 26k or 52K usage, but if my program has just run - using 42k General memory and 12K free - then there is insufficient memory without clearing General, which "files" seems reluctant to do. "Files" does seem to require a very large amount of RAM for what appears to be a listing exercise to the screen. Perhaps a clue is in the alphabetical order presented - all files are read and sorted first before listing? With regards, Paul. Nothing so constant as change. |
||||
| Tinine Guru Joined: 30/03/2016 Location: United KingdomPosts: 1646 |
Never had this problem but I personally have a problem with wasting 64 bits on variables that require a fraction of this. Therefore I do a lot of variable packing. Flags? I use all 64 bits for 64 flags. |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 5710 |
Me too... I don't feel happy having all those empty bits lying around unused. I even miss the days when you could define byte variables that only took up 8 bits and ran *really* fast. lol Z80 Inside! Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8572 |
Variables don't take 64 bits they take between 56 and 64 bytes depending on the port. The data element is trivial compared to the variable name and array of dimensions. The only way round this is variable packing as implemented by Tinine |
||||
| lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3011 |
This is a hang-up we, uh, mature programmers experience. If you want to slow your mmbasic program down, sure, use all the bits individually in an integer. But it's rare to be so cramped for space that it's a good idea to do so--you may save some bits, but at the cost of cpu cycles and your own extra effort. I know, I felt the same way when I realized what using an integer as a flag cost (down there at the micron level in the silicon), but I've forced myself to accept that my time is more to be valued (unless I faced a situation like the OP, which I never have). ~ Edited 2021-06-13 21:46 by lizby PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
| Bowden_P Senior Member Joined: 20/03/2019 Location: United KingdomPosts: 162 |
Hi everyone, Thanks for your replies. I am using Captain Boing's one-bit-per-flag scheme for flags, which has saved quite a lot of memory. This is used with disco4now's #REPLACE in MMEdit to also use string arrays rather than individual string variables, so that the LENGTH option is available. Tinine - could you describe this technique please? Sound like another trick I could apply! Peter - your statement of 56-64 bytes reflects just how much memory the variable's name uses. I've combed through my program to both shorten and remove vowels from variable names where sensible, and this certainly reduces memory usage. Going back to my original queries - is it really practical to use "files" with a program loaded too? It's memory needs seem almost all-consuming for a MM+ chip! With best regards, Paul. Nothing so constant as change. |
||||
| circuit Senior Member Joined: 10/01/2016 Location: United KingdomPosts: 231 |
Could you explain "variable packing", please, and how it is implemented? |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8572 |
The storage size for a variable is not influenced by the size of the variable name. The only size advantage of shorter names is in the program (prom) rather than the variable storage (ram) |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 5710 |
Have a look at this. It won't run on the PicoMite (yet) but I ran it on the DOS version of MMBasic. bits01.zip Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| Bowden_P Senior Member Joined: 20/03/2019 Location: United KingdomPosts: 162 |
Hi Peter - sorry - my post wasn't very clear, but as you say - shortened names economize on Flash usage. Hi Mixtel90, Thanks for the .zip. You describe there the same bit manipulation scheme that I have adopted - it is quite effective for both Flash and RAM saving if combined with disco4now's #REPLACE, and also enables meaningful names to be used in the source. With regards, Paul. Nothing so constant as change. |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 5710 |
Here's a version of the bit twiddling program that I've tidied up. It runs fine on the PicoMite. :) bits02.zip . . Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
 Print this page |
