??? 12/02/04 09:49 Read: times |
#82367 - " Responding to: ???'s previous message |
Erik,
I'll try again. Facts: 1) It is possible to have a long ISR without experiencing problems. 2) A long ISR is sometimes the best solution to a problem. 3) A long ISR is sometimes the simplest solution to the problem. If 2 and 3 are true for a given problem then a long ISR is the way to go. You cannot argue that "the effects of a long/bad ISR tend to show up "once a month in a released product"". This may well be true for a 'bad' ISR, but why should it be so for a long one? "It all comes back to my distrust of so called "testing"." Software has to be designed to work properly. In order to do that you have to understand the implications of what you're doing. If you think that a piece of software will be inherently more reliable because you've used short ISRs instead of long ones then you have failed to understand these implications. |
Topic | Author | Date |
soft I2C and interrupts. | 01/01/70 00:00 | |
Interrupt Issue with I2C | 01/01/70 00:00 | |
Interrupts & I2C | 01/01/70 00:00 | |
I2C or SMBus | 01/01/70 00:00 | |
Not SMBus PHILIPS I2C | 01/01/70 00:00 | |
a possible fix | 01/01/70 00:00 | |
Generic answer that is not true | 01/01/70 00:00 | |
ok Michael | 01/01/70 00:00 | |
Easy as pie. | 01/01/70 00:00 | |
Polarised view | 01/01/70 00:00 | |
no, Donald | 01/01/70 00:00 | |
" | 01/01/70 00:00 | |
Burned Fingers | 01/01/70 00:00 | |
Donald, Michael | 01/01/70 00:00 | |
Erik | 01/01/70 00:00 | |
100% Agree | 01/01/70 00:00 | |
Ok![]() | 01/01/70 00:00 | |
Lazy | 01/01/70 00:00 |