Hi friends,
I am using timer 0 & timer 2 interrupts for functionality and printf functions also am using to display the status .... (for printf statement Timer 1 using)some times that printf function skipped....but the fuctionality working fine.... why this is happening???? plz help me...
Basically, slow IO (eg, serial port) is just something that you should not do in any ISR!
I would take issue with any sweeping statement like that. A more reasonable suggestion would be that you should not do so unless you are sure you know what you are doing, although one might take the view that unless you know what you are doing you shouldn't be writing code at all.
Interestingly, and I'm sure this wasn't the intent, your statement does entirely rule out using interrupt driven serial comms.
"Interestingly, and I'm sure this wasn't the intent, your statement does entirely rule out using interrupt driven serial comms." Except if the important word of "any ISR" was "any".
"I would take issue with any sweeping statement like that.
As would I.
If you know what you're doing, then many things are can be done within an ISR.
Just consider a pre-emptive task scheduler.
No, it doesn't:
With interrupt-driven serial comms, all one normally does in the ISR is to load and/or unload the SBUF (or equivalent) - the actual slow IO is handled by the hardware between interrupts.
But I take your point about sweeping generalisations.
Just consider a pre-emptive task scheduler.<i/>
I don't think this is what Jack Sprat meant. Would you still back this statement knowing that an ARM7 at 72[MHz] does a content switch within 8-11 microseconds of less (by many kernels, including mine)?
"Would you still back this statement knowing that an ARM7 at 72[MHz] does a content switch within 8-11 microseconds of less (by many kernels, including mine)?"
Don't see any connection between one and the other there?!
And yes, I'm fully aware of the speed of an ARM7.
although one might take the view that unless you know what you are doing you shouldn't be writing code at all.
I am sure Jack in the Can will state that he had the whole K&R and "the bible" memorized and mentally massaged before he wrote his first line of code.
Not at all. He spent his time telling Kernighan and Ritchie what to write. Alas K&R was a bit slow and did introduce a number of errors.
Kernighan and Ritchie
Have you ever considered that "Jack Sprat" might be one of these people? I'm serious!
"I'm serious!"
That's what worries me!
I haven't twittered you Steve. Go away until I do, please (I have a new, interesting post).
I would take issue with any sweeping statement like that.
Well, an answer should only be that much cleverer than the question. Some questions really need rule-of-thumb, generalized answers, if only because the person asking doesn't have the mental framework to understand the full-fledged, all-special-cases-mentioned-and-covered textbook answer.
The question at hand IMHO is well inside that category. For the time being, all the OP needs to know that he shouldn't do CPU-intensive stuff like printf() in an ISR, period.
By the time he knows enough to be able to handle the consequences of violating that rule, he'll probably also know that people with enough skill can violate it.
Indeed - which is why I prefixed my answer with, "Basically, ..."
Yes, I do realise that. I guess you really meant to say that slow IO (eg. RS232) shouldn't be done from an interrupt but fast IO (eg. RS232) is ok?
I'd still rather see an answer that admits the possibilility that it can be done successfully. Anything less is, I feel, misleading.
No, of course not. I used a revolutionary modern technique that involved consulting the manual when I didn't know what I was doing. I found this to be so successful I still do it today.
It always seems so much simpler and more reliable than iterating through the 'guess and debug' process.