 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 Feature Request
Page 1 of 2   |
|||||
| Author | Message | ||||
Oldbitcollector Senior Member  Joined: 16/05/2014 Location: United StatesPosts: 172 |
For the last couple weeks, I've been mulling over how to best describe this request, and after a conversation about it at our last DIY meeting, I think I'll give it a shot. The Micromite has the "FANTASTIC" ability to have SUBs which can be called from the command-line. I wish ALL micros had this ability. What I'm discovering is that there are subroutines I tend to use all the time. The request: Could we have a separated space in the memory in which commonly used subroutines are stored? I know that it would create a potential for BASIC programs to break if the subroutines were not also provided, but it would be extremely handy otherwise. I could keep my common routines handy without having to copy/paste or retype them into every program. Thanks for the consideration, and comments are very welcome. Jeff My Propeller/Micromite mini-computer project. |
||||
G8JCF Guru  Joined: 15/05/2014 Location: United KingdomPosts: 676 |
@Oldbitcollector Would #include do the trick ? Peter The only Konstant is Change |
||||
| Oldbitcollector Senior Member Joined: 16/05/2014 Location: United StatesPosts: 172 |
I'm not sure a simple #include would work. It might. What I'm picturing is something that would have two separate programs sharing the same memory space. The combined program would work just as it would now, but the editor would have a new function to switch over to the secondary code space. The new command would only flush out the main code space. Xmodem would continue to work with the initial code space. Additions would be a function key in the editor to switch to that section of memory to edit sub routines. My Propeller/Micromite mini-computer project. |
||||
| G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676 |
@Oldbitcollector are you editing your source on the uMite itself ? If so then #include is no good. If you use MMEdit to edit your source, then a #include to include code into the xmodem stream as it is downloaded to the uMite could be used to always "include" your favourite Subs/Functions into the code, perhaps #append might be a better term to use eg your usual MMBasic code, then last line of your code has #append "myFavouriteSubs.bas" In addition, if this was a much sought after feature, TassyJim might consider adding it to Preferences, ie whenever Download code is clicked, append the named file at the end of the download. Personally I prefer #include since that's in keeping with other languages/paradigms/pre-procesors and keeps the including of libraries/external source general purpose 73 Peter The only Konstant is Change |
||||
| Oldbitcollector Senior Member Joined: 16/05/2014 Location: United StatesPosts: 172 |
Ah, I see what you are doing... Hmm. I'm not using MMEDIT, as we designed our own VT100 terminal "mini-computer" to connect to the Micromite for editing our programs right on the Micromite itself. We are using xmodem between the two micros to transfer programs to/from SD. I'll bet we could implement something like this, but I'd really like to see it exist in the Micromite itself. My Propeller/Micromite mini-computer project. |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4036 |
I recall Geoff mentioning that space is at a premium in the umite... John |
||||
BobD Guru Joined: 07/12/2011 Location: AustraliaPosts: 935 |
The Maximite has a capability similar to what you are asking for. See the Library Load and Library Unload commands on page 33 of the current Maximite Manual. You can programmatically read in files as needed, off the SD card and unload them when you no longer need them. A partial quote: [quote] Will load a library file ('file$') into general memory. Any user defined commands and subroutines in the file will then become available to the running program. Up to 8 files can be loaded simultaneously. [/quote] |
||||
| G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676 |
@oldbitcollector The uMite is memory constrained and is targeted at embedded systems (I think) where the cost and power budgets must be kept to the minimum. So all the "luxuries" have to be done somewhere else - in my case MMEdit on a PC, and I'm sure Linux users have numerous other ways, involving vi/emacs/pp/sx and any other number of editors/tools, UNIX users really are spoilt for choice ! I'm going to start up a Debian VM and try out Geany again !! The big problem (IMHO) in doing the development on the uMite itself is that because of restricted memory, one is forced to compromise on good practice, eg omit comments wherever possible, omit blank lines, omit indentation, etc, because all of these things use up memory but do nothing in the execution of the code. So, IMHO, what you end up with is difficult to read, maintain, modify, and understand code. I know I keep going about MMEdit, Jim put Auto-Crunch into MMEdit at my suggestion, and that single feature alone has made writing extensive/long/complex uMite code possible because MMEdit strips out all the indents/trailing spaces/comments before Xmodem'ing the code down to the uMite. Without MMEdit and Auto-Crunch (and a host of other useful stuff) I know I would have been far, far less productive, and might even have been put off trying to write complex stuff. Perhaps your "mini-computer" (using a Maximite/PI ?) could provide the IDE, do the Auto-Crunch, #include etc and then send the runtime code to the target uMite ? Something like your "mini-computer" + a handful of uMites could be a boon to education where the cost of providing a PC to each student rules out that option, and even if cost was not the barrier, having a "closed" system might make for a much more reliable/trustworthy/well-defined/robust/less-steal-able platform on which to teach programming and electronics to students. After all if they blow up a uMite, that's literally just a couple of bucks, blow up a raspberry PI and that's 50 bucks down the drain. Thanks for opening up a really interesting topic. Peter The only Konstant is Change |
||||
| Oldbitcollector Senior Member Joined: 16/05/2014 Location: United StatesPosts: 172 |
Forgive me... I'm raising this thread once more as the playing area has changed since July, and we have nearly three times as much memory to play with. A secondary editable space which is cleared by a secondary NEW command would be an amazing feature. I've got about a dozen very common SUBS and FUNCTIONS which would find a home this way. :) Jeff My Propeller/Micromite mini-computer project. |
||||
| cosmic frog Guru Joined: 09/02/2012 Location: United KingdomPosts: 302 |
In AMOS BASIC on the Amiga you could FOLD and UNFOLD all the subroutines so as to make your code look neater which was a nice feature, but what Oldbitcollector would need is something like a separate editor for subs. It's a good idea if it can be done. Dave. |
||||
| G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676 |
Hi Jeff I'd like all the development related stuff, eg Edit, taken out of the uMite so as to leave as much room available for program and data as possible. The uMite is aimed at embedded applications so it seems a bit of a waste (IMHO) of valuable resources to include stuff in there which will spend 99.999% of the devices life never being used. Peter The only Konstant is Change |
||||
| JohnL Senior Member Joined: 10/01/2014 Location: SeychellesPosts: 128 |
How relevant is Basic Interpreter in above context? Geoff has done a great work in continuing with additions and enhancements. But, I think that the fundamental problem with MMbasic for embedded applications is the Interpreter. Immediacy of an Interpreter is the most powerful feature during development, but is 100% useless after that. MMBasic with compiling option would solve just about all issues. 1. Ultimate speed improvement. 2. Ultimate available memory improvement. 3. No need for Cfunctions and messy jugling, all code done in Basic. 4. Make MMBasic as a true alternative to other compiled languages. 5. More? Be able to compile for different 8,16,32 bit ucontrollers. How difficult would it be to implement compiling option, Basic to byte code or Basic to C and then use existing C compiler? |
||||
| cwilt Senior Member Joined: 20/03/2012 Location: United StatesPosts: 147 |
Peter, I think removing that would kill the ability to do over the air updates for some of us. Olbitcollector, I think your best bet is to add the ability to include code when uploading from the MMC. Have an option that automatically includes another bas file. Perhaps more than one. |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3282 |
Let me think on that one... what we need is something simple and intuitive in both the implementation and syntax sense. Geoff Geoff Graham - http://geoffg.net |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2428 |
how about a keyword "#locked" that is inserted at any single place in the source code when a certain key sequence (perhaps a function key) is entered. once created, the #locked marker and any code appearing after it is immune from new and can not be edited or in any other way changed. it can, however, still be viewed. to edit the locked portion of code, the user just has to press the same key sequence at which point #locked becomes #unlocked and has no further effect. #unlocked can be deleted in the editor as an atomic object, or pressing the key sequence again changes it back into #locked. this would seem to be an addition that mostly just requires changes in the editor, although i am uncertain of the overall value. it does mean someone can 'lock' a complete program to prevent accidental editing, while still allowing viewing. also, it allows an easy way of merging using autosave. cheers, rob :-) |
||||
| G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676 |
Autosave Append N : If N is ommitted, Append the code currently being loaded onto the end of the code already stored in Flash. If N is specified then append the code AFTER section N, shuffling up the code in Section N+1 accordingly. Allows for Larger Flash code than RAM available. When Appended, MMBasic automatically appends a SECTION number to the just Append'ed code block Autosave Insert N : Insert the code currently being loaded just BEFORE section N, moving Section N to make room for the code being loaded and renumber all subsequent Sections, eg if one issued Autosave Insert 5, then the code being loaded would become Section 5, and Section 5 would become Section 6 and so on. If N is ommitted then inserts the code at the start of Flash, shuffling up all existing code to make room. Autosave : As currently List Sections: List the number of Sections in Flash List All: List all code stored in Flash, ie as now List Section N: List the code stored in Section N in Flash New N : Delete Section N from Flash. Shuffle up/down all later sections to close the gap, and renumber the Section numbers to eliminate the section number 'hole' New : Delete ALL sections from Flash RUN : Functions exactly as currently RUN N : Run program starting at the start of Section N My main reason for wanting this Section idea implemented is to allow the use of uMite MKII MMBasic on the larger PIC32's where Flash space far exceeds RAM space. This section approach would permit much larger MMBasic programs to be loaded into Flash and executed. In addition, this section concept would permit libraries of MMBasic code to be loaded and kept available to the interactive environment. Something to chew on ? Peter The only Konstant is Change |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3282 |
Wow guys, these are rather complicated suggestions and syntax. Almost like a second language and would require a lot of confusing explanation in the manual. I was thinking of something simple like: AUTOLOAD HIDDEN This would load the code into a hidden area that would not be seen with LIST or EDIT and would remain intact after a program load or NEW. The hidden code could contain user defined commands, functions and CFunctions, all of which would be available at the command like or to a running program. But then I thought, who would use this feature? If special functions were required in a program then they could be simply placed at the end of the program. Remember that 99% of programs running on the Micromite are less than a few hundreds lines and having a few extra lines on the end is not a big deal. These hidden commands/functions would also be available at the command line but the command line of the Micromite is mostly used for just setting options and running a program. Only a few people (like Olbitcollector) use the Micromite as a general purpose computer and therefore use the command line a lot. So, it could be done but I would prefer to not load up the Micromite with features that will be hardly used. Geoff Geoff Graham - http://geoffg.net |
||||
| cwilt Senior Member Joined: 20/03/2012 Location: United StatesPosts: 147 |
I don't see the need for hidden code. Though my plan is to put my nRF code on a mite which will be more than a few hundred lines of code by itself. Personally I like the idea of mmedit or the MMC having a setting that would append another file to your working code during upload. |
||||
| G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676 |
@cwilt #include using a pre-processor during download to the uMite - http://www.g8jcf.dyndns.org/mmbasic/MCPP.zip @Geoff Don't like the idea of the Hidden code, just doesn't seem right ! Peter The only Konstant is Change |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6269 |
MMEdit has had the ability to merge INCLUDE files for a long time. Peters INCLUDES have taken it a step further. @Geoff While I have no need for it (but who knows in the future), rather than HIDDEN, would LIBRARY be a better name for it? As long as the included functions could also be used when part of the main program. Jim VK7JH MMedit |
||||
| Page 1 of 2 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
