 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 : MM/MM+ 5.2/6.0?
  Page 4 of 7   |
|||||
| Author | Message | ||||
| robert.rozee Guru  Joined: 31/12/2012 Location: New ZealandPosts: 2447 |
microchip could release it in a wide-DIP package, i'd imagine many folks would be quite happy with that. this would be equivalent to a PIC32MX170F512H (64k ram, 512k flash, 64-pin QFP) on a 28-pin DIP carrier board - but then if going to this extent, i guess one might as well just go for the MX470 at a similar price and double the ram. how practical would it be to move the BASIC source to reside in an (8-pin DIP) off-chip flash device? would this offer any real gains? cheers, rob :-) |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
The Basic program in flash would run somewhat slower of course. Putting MMBasic itself in flash can't be done unless the PIC32 can do external fetches for program which I believe it can't. It would almost inevitably be slow, too. [Many CPUs other than PIC32 family can do off-chip memory accesses (and sometimes quickly).] The MX470 has a lot going for it :) John |
||||
MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
My thought is that it would be better to use them under the ON statement, like the ON .... GOTO | GOSUB. But i not know if that is more difficult to parse. I think of the OPTION commands more of configuring hardware and from the command prompt. This would then also be more in line with Visual Basic Script and GWBasic which will make the transition to MMBasic more smoother for users who are familiar with those languages. If OPTION is the only way possible i would suggest to use only OPTION ERROR ABORT and OPTION ERROR RESUME as it would cover most if not all cases. Having an OPTION ERROR NEXT fall back automatically an OPTION ERROR ABORT should i think be left to the programmer. The ON versions would then be ON ERROR GOTO 0 and ON ERROR RESUME NEXT Microblocks. Build with logic. |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3303 |
The problem is really speed, interpreted BASIC on the MX170 is amazingly fast but reading a program on external flash would be painfully slow. In part this is because MMBasic does a lot of scanning looking for things like the end of a loop, etc. You could use caching to improve the performance (and MMBasic already does a lot of that) but to get reasonable performance over an SPI channel you would need to cache almost everything. Geoff Geoff Graham - http://geoffg.net |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2447 |
it was the basic code i was thinking of, not the interpreter. as for speed, i'd not be too sure about there being that much impact. provided each line of source code could be retrieved in a time that was short compared to the time taken to execute it (an average of about 35uS according to the manual), then the impact may be quite minimal. bear in mind, i'm just kicking round ideas here. cheers, rob :-) ADDENDUM: snap! geoff, you posted your reply as i was writing. sounds like you've done the maths and the idea is a fizzer. |
||||
| piclover Senior Member  Joined: 14/06/2015 Location: FrancePosts: 134 |
I disagree... OPTION ERROR NEXT allows to skip easily some simple instruction (e.g. TIME$=user_input$) without having to explicitly calling "OPTION ERROR ABORT" each time to revert to the "normal" behaviour while OPTION ERROR IGNORE/OPTION ERROR ABORT blocks allow to mark some potentially error prone blocks (typically, mathematical calculations that could go wrong if fed with bad user inputs). I like it the way Geoff described his implementation, with still, I think, the need for a user-resettable error flag in excess of MM.ERRNUM (the latter getting reset to 0 at the next valid instruction and thus possibly causing a fomer error to be "masked"). |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3303 |
Yes, that would be doable and as you said, sounds better. I am not sure about that. Most times you need to trap errors in just one statement but you do not want error trapping to continue in the following statements which are normally checking to see if an error occurred. I believe that OPTION ERROR NEXT would get far more use than OPTION ERROR IGNORE. I thought of using ON ERROR GOTO 0 but that does not make sense in this environment because there is no ON ERROR GOTO linenumber statement. Only GWBasic traditionalists would understand ON ERROR GOTO 0 Geoff Geoff Graham - http://geoffg.net |
||||
| MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
The way i did it in my old BASIC days was to use a ON ERROR RESUME NEXT. And then before a critical statement/function i would set Error code to 0 and then after the statement/function check if an error occured. If so then i could choose to alert the user or just abort the program. The next statements would then run normally and if an error occured in those then the program would just continue. So instead of sprinkling 'ON ERROR RESUME NEXT's in the code i just used one at the start of the program and sprinkled 'Err.Code = 0' which i think is a more memory conserving way of doing it. ON ERROR RESUME NEXT 'lots of code 'Critical section Err.Code = 0 F$=ReadFile() IF Err.Code = 0 THEN 'Process F$ ELSE 'Alert user something went wrong with reading the file 'PRINT Err.Description 'Exit from routine or continue decision can be made here ENDIF 'Continue with the rest of the program 'etc.. [/code] Maybe i'm just the only one who never ever want a program to abort by an error message (only while debugging/testing). Ignore or trap is i think the only way for a program to run unsupervised. Microblocks. Build with logic. |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3303 |
Would it work for you if MM.ERRNUM was NOT reset by following statements which had no errors? Geoff Graham - http://geoffg.net |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
It would be fairly like C's errno, which works quite well. It sounds like you would avoid the unfortunate behaviour (*) of C's errno. (*) it can be changed by a function/syscall that succeeds - granted the function/syscall will have said it succeeded so checking errno makes no sense, but this is a bit weird. John |
||||
| MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
Not resetting would be i think best as you can do a single check after a whole bunch of code. If you need to check a specific line of code then MM.ERRNUM = 0 would be enough. Or maybe an Err.Clear method to do the same. Microblocks. Build with logic. |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2447 |
fwiw, my vote would be for: ON ERROR ABORT ON ERROR IGNORE ON ERROR NEXT MM.ISERR is a flag that is set upon an error occurring, and cleared after the flag is read/checked MM.ERRNUM value is retained after a non-error-causing statement example usage would be: ON ERROR NEXT I = 2 / 0 ' a statement that generates an error IF MM.ISERR THEN ' check and at same time clear flag PRINT "error flag = "; MM.ISERR ' prints 0 as flag has been cleared PRINT "error number: "; MM.ERRNUM ' MM.ERRNUM value retained PRINT "error message: "; MM.ERRMSG ENDIF cheers, rob :-) |
||||
| MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
That looks good! One concern is that it would be necessary to retain the MM.ERRNO. In your example the ERRNO (and ERRMSG) would be reset after the first PRINT statement. Microblocks. Build with logic. |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2447 |
i'm assuming, above, that MM.ERRNO/MM.ERRNUM holds a meaningful value that is dependant on the error - ie, 1 = division by zero, 2 = no RTC, etc. rob :-) |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2447 |
microblocks: i've edited the post so that both would be retained :-) |
||||
| piclover Senior Member Joined: 14/06/2015 Location: FrancePosts: 134 |
Yes, it would work ! 
We still would need to allow the program to reset MM.ERR* "constants", so OPTION ERROR CLEAR would still be needed (but it's easy to implement and low cost in code bytes). |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2447 |
just spotted a minor error in the error messages: > rtc settime 1,2,3,4,5,6 Error: RTC not responding > rtc gettime RTC not responding the strings returned are not consistent, one having "Error:" in front, the other not. i guess bringing all the error strings into one place would help highlight any such small differences. also: would it be worthwhile thinking about folding the RTC command into OPTION? i recall there being a shortage of tokens left free, is this still an issue? cheers, rob :-) |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3303 |
The reason why the second message did not have "Error: " in front was that the error is not processed by the error system when it is outside of a program. This is to avoid problems when RTC GETTIME is placed in MM.STARTUP. You are right in that for consistency I should stick "Error: " on the front but it would waste some more bytes and not really achieve much. I think that I am down to about a dozen. Not great but not too bad either. Geoff Geoff Graham - http://geoffg.net |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3303 |
For info: Sometime ago someone asked for While working through my ToDo list I have reached this and just realised that it is harder than it seems and will require reading the background back from the LCD. That is also on my ToDo list but it will be complex to implement and won't make the next release. Just in case someone is hanging out for this... Geoff Geoff Graham - http://geoffg.net |
||||
kiiid Guru Joined: 11/05/2013 Location: United KingdomPosts: 671 |
Geoff, this probably went unnoticed amongst the other things... MMBasic is missing what is the equivalent of ~ in C. This makes very difficult bit flag operations. http://rittle.org -------------- |
||||
| Page 4 of 7 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
