 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 : MMbasic 5.3 Requests.
  Page 10 of 11   |
|||||
| Author | Message | ||||
| JohnS Guru  Joined: 18/11/2011 Location: United KingdomPosts: 3678 |
Why the focus on MX170? Is the MX170 special in some way? Highest (memory) spec that comes in (28-pin?) DIP? (I gather MMBasic has already been compiled for MIPS16 where it can be so flash memory really is full.) John |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2294 |
you seem to have answered your own question - the special thing is that it is the most powerful pic available in a dip package. the 0.1" pin spacing is a major accessibility advantage. plus one shouldn't forget the tiny 6mA @ 3v power consumption when the cpu clock is cranked down to 5MHz. cheers, rob :-) |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3167 |
Just out of interest I compiled the current V5.3 Beta 4 with all non essential components removed. The result is a free flash of 74K (25% more than the standard version). To do this I removed: - The editor - TEMPR, KEYPAD, LCD and RTC commands - SELECT CASE - The MEMORY command now just reports the amount of free flash All these features can be implemented some other way (some in BASIC code). For anyone who is interested, removing the editor recovered 7K, the next big ticket item (amazingly) was the MEMORY command (3K), then SELECT CASE (2K) followed by the others (2K together). Some features of the Micromite (such as the IR receiver, DISTANCE and the DHT22 support) cannot be implemented in BASIC so I left them in. Maybe they could be later replaced by CFunctions but they use little flash so I'm not sure that it would be worth it. You can try this version if you wish: 2016-11-24_120250_Micromite_Lite_5.3B4.zip I needed a name for it so I called it the "Micromite Lite". I know, I know, we are running out of names! I can hear WW pounding on the keyboard already  I am not sure if this will ever become part of the full Micromite release as it it is just an experiment for people who are pushing the limits of the memory capacity. This is easy to do with embedded fonts, CFunctions, etc as I found out with the Super Clock project and Silicon Chip with their Energy Meter. The Micromite Lite gives you the option of shifting to a stripped down Micromite when your back is to the wall. Geoff P.S. Because programs loaded via AUTOSAVE and XMODEM are buffered in RAM you are still limited to loading 50K at a time. But you can always load the components (especially fonts) in stages and save them to the LIBRARY in stages. Geoff Graham - http://geoffg.net |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2794 |
Can I suggest MMBASIC Lite instead  For everything Micromite visit micromite.org Direct Email: whitewizzard@micromite.o |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2294 |
this sort of profiling is extremely useful in identifying areas that are worthwhile optimizing, and those that will yield insignificant gains. it is interesing that MEMORY consumes so much flash, would it use less if it just reported free flash space and nothing else? personally, it is a command that i hardly ever use. as i recall, old microsoft basics used to have a function called MEM() or FRE() to return the quantity of free ram. perhaps this would be a worthwhile change for the MX170 version? the editor is the one thing i would retain (an essential characteristic of mmbasic), though i'd be happy to see all the colour LCD support gone. but, as i've said before, i am sure others would have differing opinions! cheers, rob :-) |
||||
CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 1995 |
Now this is interesting! I rarely use the editor as I always write with notepad++ and xmodem in with putty (just an old dog with old tricks) When you say LCD do you mean all the LCD Panel stuff too? Am I the only one who isn't playing with them ? (but I have plans). Most of my stuff beavers away in the dark so it's the raw computing power of MMBasic I like rather than the bells and whistles (but they are impressive!) Loading these modules as needed has to be a better solution I think and is bound to make life easier for the core development - you can't possibly cater for all devices. I am impacted by this but I am happy to take it. It's easy to fix - I like SELECT/CASE but it's easily replicated by IF/ELSEIF etc... and the RTC code, but I am already using raw i2c to grab other registers from 3231s so I feel a new module coming on. I will download and play - thanks. p.s. it is possible to get an addedum (should that be a minusendum? ) of the removed modules?... and the wife wanted to go Xmas shopping this weekend... |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3167 |
Why are you debating the editor? The Lite version is not a replacement for the Micromite and no one is planning to remove the editor from the other versions. This version is only for when you have no other choice. It is mostly this feature (and associated fonts, etc) that leads people to run out of memory. If you remove colour LCD support you would also remove the need for a Micromite Lite! Ever since I started with MMBasic five years ago some people (not you) have pushed the idea of a "Leggo block" approach where you could assemble your own custom version of MMBasic by loading various components. Lets be clear... that is never going to happen. The software tools are not available and there is not enough flash to implement a linking loader. The best that we can hope for is to replace a limited few components with CFunctions. The reason why I say "a limited few" is because CFunctions have to be constructed from position independent code and they have limited access to the internals of MMBasic. These are significant restrictions. Geoff Geoff Graham - http://geoffg.net |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2294 |
well yes, given the choice that would be the direction i would like to see made available. as a tool for teaching programming, hardware development, project creation, colour LCD support ranks below many other uses of flash space. bear in mind that this is just my personal opinion. taking a slightly different angle, the full MEMORY command consumes 3k of flash space. if this command were to be implemented purely as an mmbasic program stored in the library area, how much flash space would it likely consume? if the answer is less than 3k, then it may be a candidate for permanently reimplementing as an 'internal basic token string'. any command that can be implemented in less flash space using basic code rather than C, and is not time-critical, becomes a candidate for this treatment. for instance, the RTC commands. cheers, rob :-) |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3678 |
I'd leave out EDIT if I needed more flash in a 170 mite! But... seems to me those who really want this can just compile their own MMBasic, leaving out things they don't need. It even sounds like Geoff may have put in some things to help. (It's VERY easy in C to do this using such as #ifndef) John |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3167 |
I don't have any idea on this one. It would be interesting... would the flash consumed by implementing support for 'internal basic token strings' be more than it saved? There are quite a few options for optimising flash usage and this is one of them (and a great idea also). But I want to avoid this to be taken as a springboard for implementing more major features. What flash is left and what can be recovered will be small and needs to be reserved for bug fixes and minor upgrades. P.S. What are you doing up at this hour? It must be 3:30 in the morning over there. Geoff Graham - http://geoffg.net |
||||
| CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 1995 |
playing with MMLite - you started it |
||||
| Phil23 Guru Joined: 27/03/2016 Location: AustraliaPosts: 1664 |
I think this is where Libraries of functions for special devices would be great. I tend to lean towards functions written in Basic as opposed to cFunctions. That way users can relate them to data sheets & try & understand what's going on. I know all the information required is in the Data Sheets, but comprehending it is the issue for some of us. Probably because of terminologies used, & the presumption by the authors that the reader already has a good background in the terms they refer to. I consider myself to be reasonably smart, but data sheets do present a language issue. In some cases it would be like sending me to the Supermarket with a shopping list written in French. I'd work out a few bits, maybe, but some would read a total blank. (About the only thing I get 100% on the list would be a "Fenêtre", but there's none of those at the Super; Good Bunnings excuse though). Not saying I haven't tried, & have had some degree of success, but it can drag things out & get frustrating, as I found with reading multiple DS18B20 on a single bus, some may recall it from this tread. That is mostly working reliably now apart from the occasional error it won't trap, have read the sheets so many times, but there is still a (slowly shrinking) comprehension gap. So in summary, I agree, MMbasic does not need any more native special device support, but device support in libraries would be a great add. And if they are in basic, then we can try & learn to understand their operation with the help of the data sheets. Sure cFunctions could be offered as well, but they would be a closed piece of code as far as understanding & changing is concerned, maybe only important in instances where speed is an issue. One thing that's disappointing is that the MMBasic Library has not continued to evolve. There's some great stuff in there, both for use and as a learning reference. It would be great to see it going again. Cheers Phil. |
||||
| Phil23 Guru Joined: 27/03/2016 Location: AustraliaPosts: 1664 |
Or MMbasic Core? |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2294 |
the support is essentially already there, in the form of the existing library functions. the only addition needed (and the need is debatable) is a mechanism to 'set in concrete' the current library content, so it is no longer erased by LIBRARY DELETE and no longer visible to LIBRARY LIST. this could be accomplished by a LIBRARY LOCK command that hides existing library routines and makes them immune to being erased. the LIBRARY LOCK command could even be made once-only use. but does it really matter if the user can view these routines? do they need to be hidden at all? if not, then no changes are needed at all beyond recoding some parts of mmbasic in mmbasic. creating the mmbasic .hex distributable would consist of (a) burning an image into the MX processor, (b) uploading those routines that are library resident, (c) [optionally] locking them in place, and then (d) saving a flash image for distribution. the idea is common when designing calculators as a means of conserving scarce flash space at the expense of reduced speed of execution for the 'high-level encoded' functions. the simple answer is insomnia, the more complex answer is more complex. cheers, rob :-) |
||||
| CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 1995 |
|
||||
vegipete Guru Joined: 29/01/2013 Location: CanadaPosts: 1085 |
I was just reading the Micromite User Manual (v5.2) searching for answers (questions in another thread) and was left wondering about commands. There is a big list starting on page 52 but it is unclear to me which commands work in a program and which, if any, _only_ work from the command prompt. Could the manual be changed so that immediate or deferred mode command usage is indicated? Visit Vegipete's *Mite Library for cool programs. |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2294 |
expanding here a little on an idea i raised in another thread, and putting it where geoff is more likely to see it... what if the statement: FLASH varname = value completely replaced the existing VAR SAVE, VAR RESTORE and VAR CLEAR commands? any variable declared with a FLASH statement would permanently reside in flash, within the actual mmbasic basic program; reads would come from program flash, writes would cause the block of flash containing the variable to be rewritten - with the one limitation that a variable (like a string) could not grow or shrink in size. FLASH statements could appear anywhere in the basic code, but would need to occur before the named variable was first accessed. the user would also need to be careful to not perform excessive writes to a variable declared as FLASH - mechanisms to safeguard against this would be complicated. i suspect this all may be fairly easy to code, provided the contents of FLASH variables were stored the same format within the basic flash area as variables held in RAM. the interpreter would be able to decide on the status of any variable (FLASH vs RAM) based upon the memory address. negatives: backwards incompatible, some few hundred bytes to implement, possible need for a ram buffer for flash writes. positives: reclaim 2k/4k of flash currently reserved for saved variables, elimination of (flash) code associated with the three VAR commands, much simpler to understand and manage. basic source could would always reflect the currently saved values. number of saved variables not limited. since few real-world applications are likely to use saved variables, the net gain for most applications will be in excess of 2k/4k of flash space. geoff: does this sound like an interesting idea? cheers, rob :-) |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3167 |
Yes, interesting... and thanks for the thought - but it is impractical. I appreciate that you have spent a lot of time typing up this idea but I think that you are operating at the 10,000 ft level without knowing what it is like in the trenches. It is hard to explain without going through pages of detail explaining flash and variable management but it would require a rewrite of large hunks of MMBasic for no appreciable benefit. Geoff Geoff Graham - http://geoffg.net |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2294 |
not to worry, little time was taken writing it up, and (as always) just an idea. i do appreciate that 99 out of 100 suggestions will be impractical for one reason or another, but they are all a part of the process for arriving at that 1 in 100 that is of some use. cheers, rob :-) |
||||
redrok Senior Member  Joined: 15/09/2014 Location: United StatesPosts: 209 |
Hi Geoff; I have been working with the 64 bit integer registers. I find the lack of the carry bit a bit hard to work around. When adding 2 32 digit hex values I need to know the carry bit to be added to the higher register. I understand I can pre-test for the carry before the actual add. This seems to work but it's clumsy. Also, when doing bit shifts I miss the shift out bit. Again, I have been doing a pre-test for the shift out bit, also clumsy. Would it be possible to add a special variable that shows the value of the carry or shift bit condition of the top end of the integer register whenever an add or left shift is performed? While I haven't needed it yet, I suppose a test variable at the end of the register would be nice. The big advantage of these bits is they can be tested or added "After" the operation is performed. The work around method must be done "Before" the operation is performed. I would assume these need to contain only 1 bit of information. This 1 bit variable can be both read or written to. While i haven't fully thought this through yet. I would think that they may be in the form of: 1. CarryHigh is equivalent to 2^64 or &h1,0000,0000,0000,0000. When added to or subtracted from an integer it has the value of &h1 2. CarryLow is equivalent to &h1. when added to or subtracted from an integer it has the value of 2^63 or &h1000,0000,0000,0000. redrok |
||||
| Page 10 of 11 |
|||||
 Print this page |
