 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 and Micromite Plus Beta 28
  Page 2 of 3   |
|||||
| Author | Message | ||||
| WhiteWizzard Guru  Joined: 05/04/2013 Location: United KingdomPosts: 2944 |
@Geoff, Whenever MMBasic's inbuilt editor is run, you currently clear variables to make as much space available for the editor. This is fully understandable in smaller devices like the MX150 & MX170. However, does the 'bigger' MX470 have enough space to allow you to keep variables 'untouched' whenever the Editor is run? Reason for asking is below . . . I am trying to name pins on the MM+ with the help of LIBRARY SAVE. So a library (i.e. program) is created such as: wwPINS
sub wwPINS A1=15 'allows pin 15 to be referred to as A1 end sub The reason for calling the wwPINS at the start of the libraries code is so that after reset, and at the command prompt, A1=15. So a users program will now include the line wwPINS at the start so that they can then refer to pin 15 in their program with something like SETPIN(A1),dout If wwPINS is not included in the program, then A1 will currently be set to zero as soon as the editor is entered and hence subsequent running of the program will try and SETPIN(0) (which obviously then generates an error). So having wwPINS at the start of the LIBRARY, and having wwPINS at the start of a program means that you can refer to PIN 15 as pin A1whenever the program runs, and whenever you do a reset up until the point you enter the editor. HOWEVER, as soon as the editor is entered, then subsequent command prompt queries/commands mean that A1=0. So if the MX470 has enough memory; is there a case for not 'clearing' variables? Hope this makes sense  . . . . .
WW |
||||
MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
Yes that is exactly what i hope to achieve. In normal mode it functions as a USB-Serial but if you first lower DTR (which would be connected to #MCLR) and then send a bunch of '>'s within the first 2 seconds it enters programming mode. The pic32prog then does its thing by sending commands to manipulate the pins to progam the chip. All in place and all from the console. I was planning to use it as a surprise, but alas, the thought has been around for a while.  
I am getting there slowly. I can get it to switch modes, but i still need to port over the code that runs in the nano. It looks that that part will not be difficult as it is only responding to commands it is being send. The 'brains' are in the pic32prog program. This opens also the possibility to be able to program other chips then a pic32. The whole range of 8-bits, 16-bits etc have a simpler programming protocol. The final test would be to program a 1455 with another 1455. It should also be possible to program a pic32 using a uMite together with pic32prog. Just port the Nano code and it should work. If using cFunctions it might even be fast! I am actually trying to do it Basic just to get a feel of what the Nano does. Microblocks. Build with logic. |
||||
| Chris Roper Senior Member  Joined: 19/05/2015 Location: South AfricaPosts: 280 |
Thanks Geoff, Just upgraded a MX170 28pin and its looking good. Cheers Chris http://caroper.blogspot.com/ |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6283 |
While playing with LIBRARY SAVE, I discovered that you can have multiple user functions with the same name. If a function MAX() exists in the library and your program also has a function MAX(). the function in your program gets used rather than the library function. It is a 'feature' that should get a mention in the manual. Is the order of preference always the same? I also discovered that you can have two functions with the same name existing in your program. I would call that a bug (that has existed for many years). Jim VK7JH MMedit |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3292 |
@WhiteWizzard: I can see what you are trying to do but I believe that there is a better way to do it. I am thinking of running the library code every time a program is run and just before the main program in normal flash is run. That way you can setup I/O pins, define special variables, etc which will be constant for every program regardless of how it was run. However, you cannot also run the same library code when the Micromite initially starts up - you need to have some way of running different code at startup. So, I am proposing that the interpreter looks for a subroutine called StartUP which it runs only once at power on. This sub could be in the main program or in a library and could look like this: SUB STARTUP
RTC SETTIME END SUB The main body of your library code could then setup your constants: CONST A1 = 15 'allows pin 15 to be referred to as A1
... etc BTW it is better to use CONST rather than define a variable. Comments anyone? Finally: The file cfunction.h that I posted earlier contained a bug (thanks again to Peter for finding it). Please replace it with this version: 2015-09-16_013702_CFunctions.zip Geoff Geoff Graham - http://geoffg.net |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3292 |
Yes, the order is always the same (main code first, then library code). You are right that this should cause an error but I am reluctant to use valuable flash (especially in the MX170) doing yet another sanity test. I will have a look at the subject when I have a stable beta version and fully know the situation regarding flash space. BTW, no one has noticed yet that the latest MX170 beta has 2K less flash for programs - but I hope to claw that back with later optimisations. I know that 2K is not much but I would prefer to not go backwards. Geoff Geoff Graham - http://geoffg.net |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2442 |
i'm still of two minds over the whole LIBRARY concept. on the positive side: i can see it as a really good way for anyone to 'customize' a micromite to have builtin functions for specific hardware. with an MX170 it could possibly even be used to patch in code to drive an LCD and keyboard that replace the console. this could realize a low-power 'pocket computer' using just the MX170 and a pair of AA batteries, 40x8 mono LCD and small keyboard - i really like this idea, i miss he era of pocket computers. on the negative side: are the MX170 and MX470 in fact two very different beasts? if the MX170 is targeted as an embedded controller (another idea i really like), then having methods of creating 'hidden' code seem counterproductive: what is the point, when the controller is in a dedicated application and there is no need to 'hide' some part of the code but not another? in a classtoom/teaching environment how much havoc could the feature cause, bearing in mind that a factory reset clears the library? does the LIBRARY concept remove the 'uniformity' of the language? on the whole, i feel that i would rather see the flash space (in the MX170 at least) made available for other things - one really useful feature to have built in (for instance) would be code to use an external 24LC512 I2C EEPROM as a data storage device that is seamlessly spliced into the existing open/input#/print#/seek#/close routines. given the choice between the LIBRARY routines, and something like external EEPROM support built in, which one would be more useful in building actual mmicromite (MX170) applications? now, of course, the MX470 may be a completely different beast. in the MX470 case a different set of priorities and applications may exist, and flash itself is a tad more abundant. 100% just my opinion, mind you. cheers, rob :-) |
||||
| isochronic Guru Joined: 21/01/2012 Location: AustraliaPosts: 689 |
Hi An idea I am cogitating for my own programs which would be a nice synergy here ? It is a source checksum command which would check the saved text program content. Eg something like CHECKSUM 123456789 999999999 The first number is the sum of all the text ascii values. If it doesn't match the summed stored program ascii then an error is flagged (ed) as it means there has been an alteration or glitch. A 00000000 (zero) could be a temporary ignore switch. The second number is a dummy string of ascii that allows finalization adjustment. So to protect a program the ascii sum is calculated by the developer and set as the first number. The second string ascii characters are then nudged down so that the total sum still matches. It sounds like it would be a way of catching startup glitches etc, MMx is welcome to use it, cheers |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3292 |
Actually the driver behind the LIBRARY idea was the need to strip the hex codes out of the CFunction declaration. That saves a lot of program flash space and that is even more important to the MX170 than the MX470. For anyone who is confused at this point: When a program is loaded MMBasic will extract the hex codes from any CFunctions and save them in flash as an executable chunk of code. But, the original hex codes are still in the CFunction in flash using up valuable flash memory - they need to be there so that the user can edit and list them. Many ideas have been presented to overcome this issue but they all failed on some key issue or other. With the LIBRARY concept the code is transferred to a secret place where it can never be edited, so the original CFunction hex codes could be removed during the transfer thereby getting around the wasted flash issue. It was only when I was implementing this feature that it occurred to me that it could also do a similar thing for normal BASIC code with very little extra cost - but that was not the main driver. Geoff Geoff Graham - http://geoffg.net |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2442 |
given that each CFunction is encoded into a known location in memory, and is of a known length, why can the 'source code' not be reconstructed from that location in flash whenever the editor is launched? admittedly, the exact format might not be recreated (words per line, spacing between words, comments within the function), but does that matter? as long as each time the same sequence of data is recreated from flash (when the editor is opened) and saved back into flash (when the editor is exited) then i can see no major problem. would it be any easier if the CFunction header had to specify the number of words to follow (and that a mismatch between the number specified and number found generated an error message)? if it is an issue of basic code + cfunction source > available RAM to edit it all at once, then a simple solution would be to allow two editable 'code spaces', with one for basic code and the other dedicated to CFunctions. but both fully editable, no "secret places". it could well be i am missing something here
cheers, rob :-) |
||||
| Chris Roper Senior Member Joined: 19/05/2015 Location: South AfricaPosts: 280 |
I see this as a circular argument Rob, What if your Project needs external EEPROM, but mine needs large amounts of Flash for WaveTables, for instance. You include the EEPROM library along with any sensor Library functions and have that functionality, even during the development and testing phase. I, on the other hand, can strip out all libraries, fonts, display drivers etc. and have maximum available Flash. The same device can now handle both situations with ease. Cheers Chris http://caroper.blogspot.com/ |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3292 |
Because the whole text (incl the CFunction hex codes) must be in RAM for the editor to work on. The same applies to the other ways of getting code into the Micromite (AUTOSAVE and XMODEM). The result is that, because the whole program must be buffered in RAM, the RAM is actually the limiting factor. With libraries this limit can be removed. That has its own set of issues with special commands to save in one area or the other, edit one area or the other, delete one area or the other, etc. It is a positive minefield. Compared with this what is so wrong with the LIBRARY approach? Geoff Geoff Graham - http://geoffg.net |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10315 |
Geoff has already made the following point but I don't think it is fully understood so I want to re-state it. The way the Micromite code works (without a very major re-write) is that the usable flash memory for user programs cannot be greater than the amount of usable RAM. On the MX170 there is 64K of RAM of which 6K is used for internal things like various buffers and the C stack and heap. This means there can only be 58K of flash available for user programs. On the MM+ this roughly doubles as the MX470 has 128k RAM. In various posts above there are requests to strip out functionality and have it available as loadable drivers to "increase available flash" - it wouldn't, the 58K limit would still apply. The challenge for Geoff is working out what to include in the firmware whilst still leaving 58K of flash free (i.e. balancing all of our disparate priorities) I hope this makes things a bit clearer. |
||||
| Chris Roper Senior Member Joined: 19/05/2015 Location: South AfricaPosts: 280 |
I, for one, fully understand that and probably badly phrased my intent. I am not talking about striping out the core, I will use C or C++ if I need the entire Flash. What I was referring too is all the requests made, in various threads, to add Additional functionality to the core. If the Additional functions are in a library they behave as part of the core but can be removed when not needed, freeing up the Flash - Not additional flash, the original 58K - for maximum use by applications that have no need of the other Library functions. If future Device drivers, Fonts, display Drivers etc. are implemented as Libraries, it prevents bloat or having to shoe horn them into the core. With the added advantage that the target application can decide if it needs them or not. Cheers Chris http://caroper.blogspot.com/ |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2944 |
Don't know if I've uncovered a bug but there is an issue when I do this. When CONST A1=15 is set up as library main code (outside of a subroutine) then when MM is powered up (or reset) and I PRINT A1 the result shows 15 as expected. BUT when I run a program such as SETPIN(A1),dout I get an error message saying Pin 0 is invalid
Is this because the library feature shouldn't really be used for setting constants? Setting up as a variable (as per my original post) works fine apart from the EDITOR reseting the value to 0 so then the next time at the COMMAND PROMP I refer to A1 it equals 0. However, running my program sets it back to the correct value by calling the wwPINS sub (part of the library) at the beginning of my program. Please let me know if you think it is a bug; or more-likely me actually mis-using the CONST declaration in a library? |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2944 |
@Geoff, One annoying little bug/feature: I have noticed that when you have a library implemented and you then type LIBRARY DELETE followed by LIBRARY SAVE (to update a library) then sometimes I get a '[' character prefix the initial 'L' (of Library save), and sometimes the 'L' doesn't appear (as if I hadn't typed it). Note that this is on a PS2 keyboard when using LCD1963 as console. It happens most of the time but not every time. Could this be part of the keyboard timing issue (i.e. Ctrl-C)? WW |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3292 |
With the current beta that is correct. This is because MMBasic clears all variables, constants and I/O pins when RUN is used. This is why I am thinking of running the library code every time a program starts, ie, following RUN. Then you can set constants (in the library code) that will be seen by the main program. That does sound like a bug. I will investigate. Geoff Geoff Graham - http://geoffg.net |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2442 |
is the library function not already a subtle variation on two code spaces? one code space is fully editable. the other one can be transferred to (LIBRARY SAVE), be listed (sans CFunctions), but not edited. functions within the first code space can call functions within the second, but not vice versa. turning the question around: ignoring CFunctions for the moment, are the limitations of (a) not being able to edit the library, and, (b) library functions not being able to call functions in the main program space, not arbitrary limitations? CFunctions aside, is there any reason the two code spaces ('main' and 'library') can not be equal in every regard? imagine the two spaces instead called "P0" and "P1". a space is edited by typing at the command prompt EDIT [P0 | P1], where EDIT without parameter opens the last space edited. when editing, the status line in the editor clearly displays "P0" or "P1". similarly, there would be LIST [P0 | P1], NEW [P0 | P1], RUN [P0 | P1], etc. the crossover would be that both spaces would 100% share the same RAM space - shared variables, one shared function table. the only real conflict would be with the command RUN without parameters. i'd be inclined to have it run the main code from P0 by default - this would be the only asymmetry. now CFunctions are a completely different issue. as i have said earlier, i still can not understand why there is any need to keep the 'text' version of a CFunction when that text can be reconstructed from the binary data when the editor is launched. this in itself will reduce the CFunction flash overhead from 3:1 down to 2:1 for a start. and upon reflection - given two fully editable code spaces, perhaps that could be an acceptable compromise? again, just my opinion. at the end of the day, if one doesn't like a feature it is easy enough to just not use it. like those pesky local variables and new-fangled colour LCDs! cheers, rob :-) |
||||
| MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
I like the idea of two code spaces. It seems, big emphasis on seems, that the difference with a single code space is just an extra block of memory in flash. If RAM is the biggest obstacle to develop larger programs then cutting it into more (why limit it to two ) "fragments" would be ideal. Only limit to keep things doable is that fragments can only contain complete subroutines/functions/cfunctions.
Microcontrollers always have lots more flash then RAM so it would really make a difference. The interpreter can see the MMBasic code in flash as one single program, or maybe even in the future (version 10 ) use cooperative multitasking, still one variable space but then two or more tasks that can run simultaneously. It does not seem that impossible anymore ones there are more 'code spaces' in flash.
Microblocks. Build with logic. |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2442 |
more than two editable code spaces would pose problems. essentially, each space needs to be placed hard up against an 'edge': in the case of linear memory, the two available edges are top and bottom of available flash. assume the two code spaces are called "P0" and "P1", with P0 packed low in available flash, and P1 packed high. imagine we are in the editor, editing P0. we press 'save'. first the CFunctions of P0 are converted from ascii-hex into words, and placed in flash starting at the lower limit working upwards. after this the CFunctions are stripped out of the text, and the remaining basic code is tokenized and packed above the P0 CFunctions. if we are in the editor editing P1, and we press 'save': the P1 CFunctions are converted from ascii-hex into words, and packed at the top of available flash. next the CFunctions are stripped out and the remaining basic code tokenized and packed below the P1 CFunctions. this leaves a 'space in the middle', which in theory could be used to hold a transient function address tables that is constructed from a scan of both P0 and P1 after any save of either. i've not seen the source code, but the above seems logical. with more than two code spaces, however, things would become far far far more complicated. cheers, rob :-) |
||||
| Page 2 of 3 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
