TheBackShed.com

Forum Index : Microcontroller and PC projects : Line/statement execution and Interrupts

Page 2 of 2

Author

Message

JohnS
Guru

Joined: 18/11/2011
Location: United Kingdom
Posts: 4044

Posted: 09:03am 17 Nov 2020

Copy link to clipboard

Print this post

Cyber said

JohnS said Ever since I read Charles Petzold's Programming Windows, I have regarded interrupts as a last resort.

So you mean if can handle some event just by regulary checking it in main program loop I should do it instead of using interrupt?
I understand it is a good practice, which simplifies code debugging.
But I always thought of interrupts as an advanced and reliable feature, though hard to debug one. In fact many low level system things in PC are built on interrupts.

That quote wasn't mine, but no worries.

It's not something I ever took away from Petzold, either, but again no worries - the underlying point is good enough if you read it as "avoid interrupts if at all possible or at least until you grasp how and when/if to use them".

To a fair extent hardware / external things can sometimes force interrupts on a program, but often you're not forced and then can avoid using them (and should, probably).

Yes many low level things may force interrupts on some code somewhere - the OS ideally. It's one job of a good OS to allow most programs to be uncaring and unaware of interrupts, thus making it easier to write most programs AND they're more likely to work right.

When you use interrupts you risk such things as races. Also, ISRs are so easy to get only nearly right and then the debugging is horrid.

John

Cyber

Senior Member

Joined: 13/01/2019
Location: Ukraine
Posts: 161

Posted: 06:54am 19 Nov 2020

Copy link to clipboard

Print this post

MustardMan said Changing variables unexpectedly is a common trap. For example: n is a scratchpad number. You use it as a temporary counter in your main code (eg:n=n+1 every time someone touches the touch screen), but the ISR also uses it for looping (eg: FOR n=1 TO 5). Main code is counting presses... interrupt happens... and now your main count is wrong.

Not topic related, but this particular issue could be easily solved by adding LOCAL N at the beginning of ISR.

Even better is adding OPTION EXPLICIT at the beginning of program - this approach saved me a lot from accidently changing variable values.

Cyber

Senior Member

Joined: 13/01/2019
Location: Ukraine
Posts: 161

Posted: 06:56am 19 Nov 2020

Copy link to clipboard

Print this post

JohnS said It's not something I ever took away from Petzold, either, but again no worries - the underlying point is good enough if you read it as "avoid interrupts if at all possible or at least until you grasp how and when/if to use them".

This is a very good interpretation. Thank you.

MustardMan

Senior Member

Joined: 30/08/2019
Location: Australia
Posts: 175

Posted: 09:21am 19 Nov 2020

Copy link to clipboard

Print this post

Cyber said Even better is adding OPTION EXPLICIT at the beginning of program - this approach saved me a lot from accidentally changing variable values.

It should be mandatory!

It is one of the few things (maybe the only thing?) that can save you from misspelling a1 (one) as al (ell) or b0 (zero) as bO (cap oh). With select fonts, they look exactly the same.

Despite what nay-sayers say, BASIC is quite a capable language (especially MM-BASIC). It is a pity BASIC has gained such a bad reputation over the years, has to hold onto legacy compatibility, and won't stop you from doing horrible things.

Then again, C will let you do even horribler things (just different horribler things).

Page 2 of 2

Print this page

To reply to this topic, you need to log in.