 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 : Limits to Micromite II Prog Size
| Author | Message | ||||
| jimbotron Regular Member  Joined: 27/11/2013 Location: AustraliaPosts: 46 |
Hi All, I was trying to test the limits of the flash capacity on the Micromite and realise it is not that simple. Although there are 58K of flash memory available for the program, the editor and XModem transfers only allow a maximum of 53K of source code to be loaded. This means you can't really use the full 58K of flash (unless I'm missing something here). You might be able to use more via CFunctions. If previous experience is anything to go by I'm sure Geoff has given this limitation a fair bit of thought already. I have some thoughts on the matter that I thought I'd share with the forum. 1) It would appear that 53K of RAM is the limiting factor. It might be possible to edit more of the program if editor did not buffer the entire program in memory. 2) That may not be as easy as it sounds so perhaps an easier option is to reserve a second bank of program memory for subroutines and CFunctions. These could be edited and loaded separately. You'd have optional parameters for LIST, NEW and XMODEM Receive to access the second bank. 3) Somewhere in the past postings I recall someone requesting the ability to load subroutines and libraries that remain resident if the main application is erased. This extra memory could be used for that. I could imagine storing routines for driving your favourite hardware in a "protected" area of storage. You could then write and load much smaller programs in the main memory space. Perhaps quickly swapping out test code for the real program without having to reload the entire program each time. 4) This could also allow you to update the "Drivers" without changing the main code. Could be useful if you had several different applications built on the same base hardware. I'm probably getting carried away so I'll stop here. Jimmy |
||||
G8JCF Guru  Joined: 15/05/2014 Location: United KingdomPosts: 676 |
I Believe that AUTOSAVE is the issue, ie the code is loaded into RAM first in un-tokenised form, then copied and tokenised into flash. If one was able to do AUTOSAVE APPEND, ie tokenise and APPEND what is in RAM to Flash, then one could have larger programs than limited by RAM size. NEW, and LIST would continue to operate as before. As you say this has been extensively discussed on TBS before Peter The only Konstant is Change |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3165 |
Hi Jim, it looks like you are still testing the limits (and a good thing too). All three methods of getting a program into the Micromite (AUTOSAVE, XMODEM and EDIT) buffer the whole program in RAM. This is needed because when programming the flash all other chip activity must be stopped for an appreciable time. So if, for example, a program was being transferred via XMODEM, the firmware would loose characters if the data was progressively written to flash. So, the whole thing is buffered in RAM. The other factor is that as the program is written to flash (from RAM) it is processed to improve speed. So, for example, command names are converted to single byte tokens, line numbers are converted to 16 bit integers, etc. This "semi compilation" means that programs can shrink or expand a little when written to flash. Also during a save the program is scanned for any CFunctions and their bit codes are programmed into the same flash area but but after the program. So this also will add to the extra space needed over the programs size in RAM. For these reasons I made the program flash area larger than the RAM space used to buffer the program. In the original Micromite running on the MX150 flash was so tight that this was the limiting factor on program size (not RAM) but with the extra flash on the Micromite MkII I was able to allocate more to the program so now RAM is the limiter. I am not sure that it is worth going to a heap of trouble to find a good use for any spare flash left over after the program has been saved. The program space is enormous as it is and very few people will hit the limit imposed by the RAM buffer size - and if they did they would want to double the space, not just squeeze in an extra 5% or 10%. Please keep up the good work, testing the limits is always a fruitful place to look for bugs (as you obviously know!). Geoff Geoff Graham - http://geoffg.net |
||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9066 |
Yes indeed. This guy is a VERY pro-active Beta tester. I am impressed with what he has found and posted. Keep up the good work, Jim!  Smoke makes things work. When the smoke gets out, it stops! |
||||
| jimbotron Regular Member Joined: 27/11/2013 Location: AustraliaPosts: 46 |
Thanks for the explanation Geoff, Helps me to appreciate all the effort you've put into getting everything to work. You'll probably run out flash adding features before we run out of programming space. Edge case testing is indeed fruitful and it also tends to find the bugs that are likely to be encountered in real life usage. Jimmy |
||||
| jimbotron Regular Member Joined: 27/11/2013 Location: AustraliaPosts: 46 |
Thanks Grogster, I need to repay the Geoff and the community for making this available and keeping the development going. I did actually find a bug, but I think it is in MM Edit. If the program is too big, MMEdit doesn't display the not enough memory message when transferring the file. It looks like the transfer is complete, but in reality nothing loaded. This one's for TassyJim. Jimmy |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 5914 |
Yes, that looks like one for me to look for. I admit that I have never tried with a really big program. I do a lot of my testing with the programs that get posted here. That way I get to test a lot of different programming styles and that finds more things I have to cater for. Jim VK7JH MMedit MMBasic Help |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8592 |
Jim If you try the latest version of my graphics program - that really stretches things. It won't load without scrunching and I keep having to re-program the chip with the PicKit3 as "things" seem to be getting overwritten occasionally. best Regards Peter |
||||
 Print this page |
