 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 : Micromite Chinese Menu Option
| Author | Message | ||||
jwettroth Regular Member  Joined: 02/08/2011 Location: United StatesPosts: 80 |
As I've said before I'm a huge fan of the Micromite (MX150) and Plus (MX170). I've prototyped and built multiple small industrial and medical instruments with them. I have a sort of library of hardware and software snippits put together that make for an incredible level of productivity vs. my normal process of using various processors, libraries, some unique hardware drivers and mostly C application code. An interpreted language makes bringing up new hardware so effortless. I can play with the part at the console as I integrate it into the real code- develop subroutnes and refine things. I generally do a final pass to clean things up, make bounds checking more robust, etc. It really is a great system for the kind of work that I do. I had and old instrument that I was tweaking that was based on the MX150 original Maximite. It was a prototype Glucose meter that I did as a demonstrator. The budget was very small so I used the above technique- it went very well. The customer wanted 50 units for lab testing and was effortless. To make the changes requested recently, the easiest way to go was to simply replace the MX150 with an MX170 and carry on with all the new features. I was wondering though if it would be possible create a sort of precompiler checklist of features that I really needed and compile a custom version of the code for a given project. It would take a lot of macro level programmng during compiling to look at the swtiches and include or exclude code blocks. This would have a couple of benefits- You would gain code space, ram space and likely latency because a lot of things that could potentially be running in the background would not be required. The first category of possible eliminations would be sensors- all are useful but I've seldom used all of them in a single design and have never used several at all though I'm sure that they're useful for many others. >>Candidates for Sensor Switches 18B20 Support, IR Support, Keypad, Character LCD, Color LCD, GUI Touch, GUI Extras, RTC Support, Servo Support, Sonar Sensor Support, I2C Master Support,I2c Slave Support, SPI Support, One Wire The second category is limiting some of the generous allowance for default strings and literals. The granularity of this doesn't have to be very fine, perhaps just two options >> Candidates for literal and Implementation characteristics commnand line 80 vs 255 chars variable name 8 vs 32 characters nesting for loops of 3 vs 10 nesting for gosubs of 10 vs 30 The third category is limiting some advanced options >>Candidates for Advance Options Cfunctions Libraries Calling these codes could just produce a simple error. If the user couldn't find an easy workaround, he could reset the options and recompile and burn a new MM. I don't know the relative size of the features and don't know the level of interdependency that exists. I think that the "option picker" could be smart enough to know that RTC support would necessarily require I2C support for example. I'd like to hear others opinions on this proposal. I'd also like to here from Peter and Geoff and other Guru's on the potential value of this proposal. I'm an old timer that used to build pretty sophisticated systems with 2K of assembly language. I know that these days are gone it seems like it could improve the MMite for some users. Thanks for listening. Its a project that I would be happy to pitch in with. John Wettroth |
||||
Mixtel90 Guru  Joined: 05/10/2019 Location: United KingdomPosts: 8297 |
That sounds like *very* fundamental changes to MMBasic to me. To be honest, I don't think you'd save as much as you may think either. If you were just after one specialised version of MMBasic for medical purposes then Geoff might be fine with that, but effectively producing a host of incompatible versions probably isn't on, really. Do you need all the I/O? Have you considered the PicoMite as a platform? It has a lot of attributes that would make it a good choice for embedded control as, unlike the Maximites, that's what it was originally designed for. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3308 |
Hi John, good to hear from you. I guess that your suggestion of removable components comes from a desire to increase the amount of flash at your disposal (ie, more free flash = bigger programs). I did look at this once and as a result came up with the Micromite Lite for the MX170. This took out things like the editor, some external devices, SELECT CASE and the MEMORY command (which surprisingly used a lot of flash). The result is an increased size of programs from 54KB to 74K (25% more than the standard version). One thing that I learnt from this exercise is that the core interpreter uses a lot of memory so if you really want to save memory you will have to cut out key components such as variable types, commands such as IF...THEN, etc. Given that the Micromite Plus has 100KB program space the simple answer is to move to this larger chip. If Microchip provided the MX470 in a 28-pin dip the problem of program space would be solved for most people. Your proposal would require dynamic linking of the hex file and this has its own issues. It is complex, would require a PC and would be very difficult to do given that the interpreter relies many different modules to work. So, sorry, I don't think that this would be a practical option. The maximum string size is another thing that is deeply integrated into the interpreter. The memory management system allocates memory in 256 byte chunks which is why the memory allocated to a string variable is 256 bytes. This could be reduced (to say 32 bytes) but that would require the memory management to track many more memory chunks which has performance and memory consumption issues. In my experience the amount of RAM is generally not a problem on the standard Micromite and, if it was, there is always the Micromite Plus. Geoff Geoff Graham - http://geoffg.net |
||||
| jwettroth Regular Member Joined: 02/08/2011 Location: United StatesPosts: 80 |
Thanks very much to Mick and Geoff for your thoughtful replies. Thanks to Geoff for remembering me from a decade ago- I'm a real fan of what you've created and have experimented with all your creations- up to an including the CMM2- WOW. My software experience is with tightly embedded code in low level languages- C and a fair amount of assembly (still). My real skill is in analog design but everyone needs some level of software competence just to tickle all these devices into doing their thing. I probably need to upgrade my software skills and leave the past behind. Thanks for the consideration and carry on. John Wettroth |
||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
