 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 : ON ERROR Revisited & Software Int
| Author | Message | ||||
panky Guru  Joined: 02/10/2012 Location: AustraliaPosts: 1099 |
For discussion: I have a situation where I need a small tight piece of code to be totally free from interrupts but I also need to use interrupts in my program. I was thinking (Yes, I know, a very dangerous occupation for an old bloke, but anyway ...) Currwently ON ERROR traps a faulty piece of code and does one of several things - ABORT,IGNORE or SKIP Would it be an idea to change this such that any error would trap out to an interrupt disabled function defined with an OPTION command? eg. OPTION ERRORTRAP,FuncName FUNCTION ErrorTrap (lineno,errorline$[,skiplines]) ... code to handle error ErrorTrap = skiplines 'number of lines to skip ' default to 1 ie. line after error line END FUNCTION The error handling subroutine would be passed the absolute line number or the error line, the error line as a string and optional lines to skip on return. Default would be to return to the line after that containing the error. An extension of this is that it would allow a programmer to build in a software interrupt by using any sequence of characters that formed an invalid command that would then trap out to the ERRORTRAP function. eg. OPTION ERRORTRAP,ErrorTrap ... some code SoftInt ... END FUNCTION ErrorTrap (lineno,errorline$[,skiplines]) IF LEFT$(errorline$ = "SoftInt" THEN ... code to handle software interrupt ELSE ... code to handle error ENDIF ErrorTrap = skiplines 'return number of lines to skip ' default to 1 ie. line after error line END FUNCTION If ERRORTRAP was not defined, the error would do the default abort. If activated, it would give the user the option of taking some action for the error and/or carry out a piece of code as a software interrupt with all other interrupts disabled. I think it would also be a usefull debug tool. I realise that the software interrupt could be handled by code using flags etc. but it would not have interrupts disabled. Another feature of this is all commands and functions could be included in all versions of MMBasic with the programmer responsible for handling un-implimented commands/functions. Eg. MMBasic for DOS could still be used to develop programs with analogue and digital inputs using the SETPIN /PIN commands but they would just trap out when run on MMBasic for DOS but work as required on a Micromite. May not be feasible, possible or desireable but I thought I would throw it out for discussion. Cheers, Doug. ... almost all of the Maximites, the MicromMites, the MM Extremes, the ArmMites, the PicoMite and loving it! |
||||
| MikeO Senior Member  Joined: 11/09/2011 Location: AustraliaPosts: 275 |
Hi Panky I kind of  have something already that I have been using for a while. I have a function called ChkErr(). I call this following a line that could cause an error and of course you have to set up the On Error Skip before the potential error line. This way It give me the opportunity to interrogate the error and take some action. I have rem ed out my current default actions but you would get the drift. It also returns the error number so some further action (like exit sub) could be taken. It could be used in your situation perhaps.So Usage could be: on error skip line input #1,b$ if ChkErr()>0 then Exit Do Function ChkErr() As Integer ChkErr=0 if mm.errno<>0 then print "Error# ";mm.errno; " "; mm.errmsg$ printline "Error# "+str$(mm.errno)+ " "+ mm.errmsg$ 'xbsend "udp.send:|"+from$+"|Error#|"+ str$(mm.errno) + " " + mm.errmsg$ +"|" 'WaitforReady 'reset flag ChkErr=mm.errno end if end function I realise this as it is would not fulfill the desire for disabled interrupts So a thought on this would be to use a couple of pins, one output to one input, the input has an interrupt attached to it and the specified sub could act as a software enabled interrupt with all other interrupts disabled (presumably that would be the case) Enough thinking for today! Mike Codenquilts |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3167 |
It sounds as if you are hankering after Microsoft BASIC's ON ERROR GOTO command. The problem with this is that you then have one subroutine handling all errors and it becomes unwieldy with a huge decision tree to check all possible line numbers and error codes. The other issue is that most BASIC programs do not use line numbers and you cannot rely on the position of the offending command in the source code as that will change with editing - so you cannot identify where the error occurred. I believe that Bill rather let himself down with this construct. After some experimenting I figured that it was cleaner to to position any error checking immediately after the commands that might throw an error. The volume of coding is similar to ON ERROR GOTO but the code is in a more logical place. I think that the requirement to disable interrupts when handling an error is rather specific to your circumstances. I have not seen a need like that before. Could you not define a subroutine that enabled/disabled all required interrupts? You could then call it just before/after critical sections of code. Geoff Geoff Graham - http://geoffg.net |
||||
CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 1994 |
ON ERROR GOTO would be fabulous but everything is easy for the person who doesn't have to do the work, right? Would it be easier to implement something similar to SKIP but to skip a number of commands when an error occurs? I expected/assumed ON ERROR SKIP x would do this (and didn't) it was only when I re-read the manual properly that I realised how it really works. Problem is backward compatibility with working code so a new ON ERROR option would be needed - ON ERROR GOTO could be implemented as follows If an error occurs in the next statement, skip the line after it too. So ON ERROR GOTO would be simple: ON ERROR SKIPFOLLOWING ' I know, I know... not very inventive but you get the idea a=1/0 GOTO Fred ErrorHandler:... ... Fred: ... Normal service continues A bit clunky and uses GOTOs but it de-centralises error handling to locally in the code in point and possibly the minimum of upheaval in the MMBasic code as you only have to abandon the statement with the error and skip the one immediately following and not handle any RESUME or keep track of the current Error handler. the SKIPFOLLOWING only applies at the point it is used. Others will hopefully chime in with more elegant soutions - that is if it is a monster job to get ON ERROR GOTO. On the subject of disabling interrupts, I set a flag and all my ISRs check that before continuing. This is at the head of any ticker SUBs If FlagTest(DI) Then Exit Sub so I just let the tickers run and they come back immediately - might not fit everyones requirements my 2p |
||||
| panky Guru Joined: 02/10/2012 Location: AustraliaPosts: 1099 |
@Geoff, I understand fully. The line number I was thinking of was your internal line number you use for subs, functions,etc. The idea of the error trap was just an extension of what you already do - that is, trap the error, pick up the error code and error message and display. If all these could optionally be passed as arguments to a programmer accessable subroutine/function, code could use it at will. If the optional error trap was not defined by the programmer then everything would work exactly as is. The issue with disabling interrupts is just both tracking which are active and their parameters, as well as priority of possible interrupts. Could you define the priority of all interrupts? My understanding is all the following are (or can be) interrupt driven: Console Rx 1,2 .... Pin (in order of definition) Timers (1,2 3,4) Settick SPI (1,2 ....) I2C ...any other? Am I correct in assuming that within ANY interrupt service routine, ALL other interrupts are disabled? Thanks, Doug. ... almost all of the Maximites, the MicromMites, the MM Extremes, the ArmMites, the PicoMite and loving it! |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3167 |
There is no internal line number. A source code line number is provided in any error message but that changes with editing so it cannot be used to reliably identify what statement generated an error. Regardless, a single error handler just is too cumbersome to be workable. The priority of interrupts (highest to low) is: CFunction Interrupt ON KEY I2C Slave Rx I2C Slave Tx COM1 COM2 COM3 (MM+ only) COM4 (MM+ only) GUI Int Down (MM+ only) GUI Int Up (MM+ only) WAV Finished (MM+ only) IR Receive I/O Pin Interrupts in order of definition Tick Interrupts (1 to 4 in that order) Yes, that is correct. Geoff Geoff Graham - http://geoffg.net |
||||
MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
As Geoff mentioned interrupts are disabled once in a interrupt service routine. This will give the opportunity to use that as follows. You trap the error. Store the errors details setup a Tick interrupt with 1ms After 1ms you will get a tick interrupt and then in that service routine you can do the things undisturbed by other interrupts. At the start of that routine you can then disable the tick interrupt so it does not interrupt again. This only works when you have at least one of the four available tick interrupts free. You can setup a tick interrupt for any piece of code that you want to run undisturbed by other interrupts. You are not able to call it directly, so only use it when a tiny delay is no problem. Microblocks. Build with logic. |
||||
| panky Guru Joined: 02/10/2012 Location: AustraliaPosts: 1099 |
Thanks Geoff and Jean, it was just a thought. Jean - neat idea on using the timer, thanks, Doug. ... almost all of the Maximites, the MicromMites, the MM Extremes, the ArmMites, the PicoMite and loving it! |
||||
GoodToGo! Senior Member Joined: 23/04/2017 Location: AustraliaPosts: 188 |
+1. It would add to the reportwir.... repatware.... reportwoire... repaertw.... it would be another handy item to use in the group of commands available to trap errors. God knows I need all the help I can get!  Cheers! GTG!  ...... Don't worry mate, it'll be GoodToGo! |
||||
 Print this page |
