 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 : Saving space in the firmware
Page 1 of 2   |
|||||
| Author | Message | ||||
CaptainBoing Guru  Joined: 07/09/2016 Location: United KingdomPosts: 2170 |
bearing in mind the value RISC bought to the CPU market back in the 80s, it is important that a language concentrate on providing a really good core of "primitives" Geoff has mentioned that for a long time that he is really pushed for space in the xx170 firmware for new developments, so I was wondering; what would you get rid of to free-up space? There are a few functions that rarely get used and are easy to derive yourself if you need them. I would point the gun at: Max() & Min() - two or three lines of code inside a function Date$ & Time$ - replace with a single Now$ and use Left$/Right$ to extract the bits you want. This brings a few benefits elsewhere in your own code; date & time are often queried together, RTC SETTIME becomes easier and setting the date & time is a single action. Would you consider these to be valid considerations for the MMBasic Lite (is it still supported?) What are your own thoughts on the lite, cut down version - do you use it? |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4044 |
Some/most of those are very small so will save next to nothing. Get the source and take a look. Better, build it and look at the MAP file to see how big each part is and then pick something big enough to save a decent amount of space. Or just use a bigger chip :) John |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3292 |
FYI Max() & Min() use 328 bytes. The main problem is, what do you use the space saved by removing certain features? Most would like it to be used to implement some feature, but each person has their own favourite. I would also also be interested in the answers to that one. Geoff Graham - http://geoffg.net |
||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9610 |
The Lite version is perfect if you have a big code you need to run on the smaller MM's, but living without the editor? I think not.  The built-in editor is what makes the Micromite the Micromite, and without it, you are back to the Arduino or PICAXE method where you have to run the code and if there is any bug, you have to recompile and download again. What I love about the built-in editor, is that if the program falls over with an error, you can enter the editor, fix it, confirm it is fixed, and then update the master code in MMEDIT - which I always have running at the same time. Very quick way to squish bugs in the MMBASIC code, and much faster then having to redownload the program each time it falls over while in debugging stage. I would expect that unless Microchip release a new version of the 28's with more Flash and RAM, that the 170 PROBABLY won't get that many more new features, as I seem to recall reading that Geoff wanted to keep the little remaining space for bug fixes that may be needed. Correct me if I have got that wrong. If you need more RAM and/or Flash, it's time to move up to the MM+/MMX series of chips. I guess they ARE SMD, and that might put some people off, but the Explore-64 was designed specifically to get around that issue, by having a breadboard-friendly module you can still use to experiment with, without needing to worry about soldering any SMD.My 2c only, and I suddenly realise that I have digressed a little from the topic - sorry.  Smoke makes things work. When the smoke gets out, it stops! |
||||
| CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 2170 |
@Grogster: For me, I rarely use the editor for the reason you highlight and that different terminals seem to not always be fluent VT talkers and that the running code and the "writing" code get out of step. As soon as a bit of code gets beyond a few lines it ends up in an editor on my laptop with all the flexibility that brings. My dev' cycle might seem a little convoluted but it works really well for me: everything is written and maintained in the editor (Notepad++) Ctrl-A, Ctrl-C, F10 on the Mite (via putty or USB Terminal), a right click to paste everything, Ctrl-Z and that is it. It is a fast cycle and I reduce field reliance to an editor and a terminal prog. Getting rid of the editor on production projects was a great move and all my later production runs use the LiteMite. Your point on MMX is well taken and larger projects certainly head down that route... cant get an MMX into a ceiling rose those. One of my little mite boards, HC-12 and a tiny mains PSU go in with room to spare for the SSR to control the light below (just). "My 2c only, and I suddenly realise that I have digressed a little from the topic" so?  |
||||
| CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 2170 |
Yeah they were never going to be huge, I was just trying to grab a couple of little-used things off the top of my head as examples of getting rid of things that can be built easily enough using base statements/functions. In truth I hate to see anything of a language itself being sacrificed. Specialized functions built in to service a specific piece of hardware or an obscure function are better served by a good library so the programmer can choose what he wants in the code - which is why I like the way LiteMite has gone. |
||||
GoodToGo! Senior Member  Joined: 23/04/2017 Location: AustraliaPosts: 188 |
Gotta say, I’ve never used the editor, I use either MMedit and, to a lesser extent, Notepad++. At this time my progs aren’t big enough to fill a 170. I haven’t used the lite firmware either, because I tend to use the Select Case, LCD and RTC commands pretty often. Cheers! GTG!  ...... Don't worry mate, it'll be GoodToGo! |
||||
lew247 Guru Joined: 23/12/2015 Location: United KingdomPosts: 1702 |
The now$ and extract date and time sounds ideal to me, it's dead simple to extract both |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2442 |
a well timed thread... a few days ago i was looking at the C source for the MEMORY command. geoff wrote a while back that this consumes around 3k of flash space, and i was interested in trying to figure out how to write a replacement in basic. but then looking at the source, it occurred that cmd_memory (the function that does the work) in places duplicates stuff that is carried out elsewhere. for instance consider the section of code that sums the basic program held in flash: // count the number of lines in the program p = ProgFlash; [...] if(i && ProgramSize == 0) ProgramPercent = ProgramSize = 1; this summing is also carried out as part of the functioning of SaveProgramToFlash (used by AUTOSAVE and the editor). if SaveProgramToFlash were to store the size of the number of lines and flash spaced used (stashed away in a couple of integers in flash), then there would be no need for cmd_memory to carry out the calculations. i suspect the same principal may apply for saved variables, custom functions, and fonts. anything in RAM is changing dynamically, so would still need to be counted up every time MEMORY is called. btw: did anything ever happen around getting rid of TRON and TROFF? i doubt if anyone would notice if they went. and TRACE On|Off could even be replaced with OPTION TRACE On|Off to save a token. cheers, rob :-) |
||||
| Phil23 Guru Joined: 27/03/2016 Location: AustraliaPosts: 1667 |
My 2c on a Lite would be to dump all the "Special Device" support. DS16B20's Temp/Hum Sensor Distance Servos Keypad Text LCD Graphic LCD Maybe even RTC … … … Have them available as external's, but keep the editor there as it is a valuable basic tool. Pretty sure there would be very few implementations that would use all of the above. But then again this may be a direction for Geoff that is more trouble than it is actually worth. Basically if a 170 can't cut it, an E64 should do the job. Cheers. Phil. |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2442 |
i believe DISTANCE has already gone that way, becoming a c-function. my suspicion that the decision was helped along by the HC-SR04 and similar boards provided quite 'variable' performance for many users! the same has happened with the HUMID command, that makes use of DHT22 sensors. like many humidity sensors, these often seem to work for a while (6 months or more) before packing up due to contamination from the atmosphere. this makes for a less-than-happy user experience. a while ago geoff mentioned in a forum post that one key point for an inbuilt function is that it be something that can not easilly be otherwise accomplished in basic. going beyond this, one of the 'selling points' of the micromite, from the start, has been a simple out-of-the-box experience for the beginner. as such, support for certain 'core' devices was built in by geoff: DS18B20, keypad, HD44780-based LCD modules, servos. all these were cheap peripherals, that could easily be hooked up on a breadboard, and then accessed with just a few basic statements. now, i must confess that i have always thought support for colour LCDs should be via c-functions. but having said this, a great many forum members do seem to use colour LCD modules with touchscreens in many projects. cheers, rob :-) |
||||
Azure Guru Joined: 09/11/2017 Location: AustraliaPosts: 446 |
Silly question (maybe) how much slower is using a CFunction than having it built-in to MMbasic. If the difference is minimal then one way would be to build a library of CFunctions (that have been removed from internal) and you just include the ones you want. This is already being done with some functions. I agree it is not ideal as it adds more steps for the beginner but at the same time it adds a lot of flexibility for new options. Could be written up (as a suggested way) to load the one that are wanted during the initial board setup and then save them to the library. Then they are there until the library is cleared. Just a thought that might create useful discussion for Geoff to consider. |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3292 |
I agree with all that has been said in this thread on this subject. As Rob pointed out there are quite a few places where space savings can be found and I hunt them down when a bug fix or two needs some more flash. However, each only returns a few hundreds of bytes which are good for bug fixes but not enough for major new features. Another option is to crank up the compiler optimisation. At this time the speed critical areas are optimised for speed and the rest is optimised for space saving. If I optimised the whole lot for space saving we would have plenty of free flash but with a big reduction in speed (about 30% slower). Making the interpreter modular or employing CFunctions has often been suggested as a solution. For example, making special devices into externally loadable "modules". This sounds good but for various technical reasons it is not practical. CFunctions in particular are fraught with difficulties. They run just as fast as built in functions but compiler and other issues means that they are only good for some jobs. For example, the DISTANCE function could be made into a CFunction but not the IR function. The question remains... what would you do with this extra flash if you had it? Support for some extra LCD panels and GUI controls would be nice but not critical. A great solution would be for Microchip to make the MX470 in a 28-pin SDIP package but I have been told that the die is too big to fit. I think that we were lucky to have the MX170 in a SDIP, previously we only had the MX150 in such a package and with half the flash it was an enormous squeeze getting a cut down MMBasic to fit. Geoff Geoff Graham - http://geoffg.net |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10310 |
I don't understand the motivation behind this thread. AFAIK the only reason to remove functionality would be to substitute something new and more generally useful and as Geoff has commented there is absolutely no consensus on what this might be. There are 3 current limitations: first: the number of commands and functions (each must be less than 128). This is not to do with available memory but with the way the internals of MMBasic work. It could be overcome with a major re-write but this just makes the language bigger and more complex to master. second: the available flash memory which is shared between the MMBasic language and the user program third: the available RAM. MMBasic uses a small amount of this but the majority is already available for user variables. The available RAM also limits the size of a program that can be edited or uploaded. The second limitation specifically affects the MM2 due to the limited flash memory available. Removing functionality would not change the size of a program that could be edited or uploaded but would only increase the size/number of routines that could be pre-loaded into the library as either Basic or C functions or subroutines. So........ what is the objective of saving space in the firmware as posited in the thread title? Nothing Geoff can do can make the 28-pin DIP MM2 into a MM+ with, for example, GUI support. There are lots of options for higher power Micromites with more memory but none of them available in DIP packages which I sense is the real crux of the issue behind the thread. |
||||
| viscomjim Guru Joined: 08/01/2014 Location: United StatesPosts: 925 |
I would use the extra space to store data and variables if it could work beyond the 2k limit. Could possibly eliminate the use of external memory device in some applications. |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2442 |
personally (and this is just my opinion), i'd beef up the built-in editor a bit more (including mouse cursor positioning via X10 escape sequences), and expand the MEMORY command so that it can list all current variables, their type, how many bytes of RAM each consumes, and length for strings. and perhaps trap a few more syntax errors, like DIM mdow(7) AS STRING LENGTH 3 = ("SUN","MON","TUE","WED","THR","FRI","SAT") that has tripped up so many of us. oh, and add ATAN as an alias for ATN :-) technically, at some point microchip will be in the position to shrink the die size for the MX170 and MX470 through moving them to smaller lithographic nodes, and hence also reducing cost. at that point i could see doubling flash being on the cards, but only if they decide (from a marketing perspective) that they want to carry on with DIP packaging. bear in mind that a 512k flash MX170F512 already exists in: 64 pin QFN package, 64 and 100 pin TQFP, and perhaps most interestingly a 100 pin TFBGA that measures only 7mm x 7mm - that is small enough to sit on top of an SDIP package. so if anyone wanted to, they could today build a 28-pin MX170 with 512k of flash, albeit as a TFBGA sitting atop a 0.3" wide PCB carrier with attached pins. cheers, rob :-) |
||||
| Phil23 Guru Joined: 27/03/2016 Location: AustraliaPosts: 1667 |
|
||||
| lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3378 |
Can you explain this in a little more detail--in particular, the setup of putty and how the F10 key works--I read that it stands for AUTOSAVE, but when at the ">" prompt, if I hit F10, "OY" is printed. Right click then stalled after a few lines. PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
| CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 2170 |
here you go, I exported by workbench session for you. If you pop the attached file in C:\Program Files\ExtraPuTTY\Bin\Sessions (or whereever you store your putty sessions) you'll have all the settings I use 2018-10-11_163839_lizby.zip hth |
||||
panky Guru Joined: 02/10/2012 Location: AustraliaPosts: 1114 |
I agree with Peter's observations here. If you are running out of space on an MM2, move up to an MM+, it's really not all that much bigger in terms of board space. If you are frightened of the smd, there are numerous sources of pre-built boards that are not all that much more expensive than buying the bits and doing it yourself - and you get all the wonderful features of GUI. Personally, all my projects are based om MM+ using LCD displays and GUI display elements. I would really, REALLY like to have even more GUI functionality such as touchable DISPLAYBOX, a way to assign an area as GUI so I can do non GUI inside this space but treat it as a GUI CTRLVAL. I do use 170's but basically as dumb front ends to a MM+ display controlling back end. Wonderfull, wonderfull job Geoff, in creating the amazing MM environment, it fills my days (when SWMBO doesn't have jobs lined for me 😂😂) with enjoyment and the challenge of building and programming my "toys" ( as she calls them)!! Thanks, panky. ... almost all of the Maximites, the MicromMites, the MM Extremes, the ArmMites, the PicoMite and loving it! |
||||
| Page 1 of 2 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
