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...
Instead of printf Shall i use SBUF????? That is efficiecnt way or not????
... if by Shall i use SBUF you mean use a "simple' interrupt driven serial routine instead of printf, it is about 1000 times more efficient.
printf, being a "jack of all trades" take up an inordinate amount of space and time to be able to handle things you do not and do need in one routine.
one mans opinion is that printf has no place in limited memory applications.
Erik
Yes it is more Efficient. But if you are printing form different levels of interrupts or main you will have issues. All one level and not from main Loop is OK. But printing from the timer interrupt will slow it down especially at slower baud rates.
one mans opinion is that printf has no place in limited memory applications
In one man's opinion how much memory would one need to have for it to be an unlimited memory application?
640K ought to be enough for anybody.
That depends on what you mean by "efficient"...
printf almost certainly does what it does pretty effeciently. The thing is that it does a really vast amount - so, if all you want is trivial text output, it is a very poor choice.
But I have seen projects where they dismissed printf as "ineffecient" and, instead, wrote a "simple" routine to just output text. Then they had to add a "simple" routine to just output a number in hex. Then they had to add a "simple" routine to just output a number in decimal. Then they had to add a "simple" routine to just output a number from xdata in hex. etc, etc, etc,...
In the end, I'm not convinced that they gained much over just using printf in the first place!
Jack Sprat has already had a post about a year ago about the increase in size when adding printf().
The thing to rememeber if sending data from an interrupt is to try to limit the output to a single character, and making sure that the interrupt load is less than the capacity of the serial port. With a bit of careful planning, you could have the majority of interrupts able to emit a character with zero wait.
Quite.
However, common sense can't be allowed to interfere with philosophy in ''51 ain't no PC' country. You just gotta get off your horse, throw away the programming manuals and fire up the ICE if you're gonna be a true '51 man.
But that's true irrespective of whether you use printf or not!
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.