We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi All,
I am writing a serial driver in C and would like to know what is realistic performance for such a beast. I basically have a ringbuffer to isolate the client from the internals of the driver. The ringbuffer structures (one for Tx and one for Rx) currently live in XDATA - is this going to kill me? The ISR has been declared as 'small' yet I am concious that each access to the ringbuffer structure is going out to XDATA - just how 'bad' is this?
With this rather simple setup I seem to drop the odd byte when running at 9.6K - I am simply sending a file via HyperTerminal into the micro and spitting it straight back out again. I have not completely ruled-out that the dropped bytes are not ocurring elsewhere, but I wanted to get the opinion of you learned folk on what is realistic for this kind of driver setup at the micro.
Thanks for any feedback.
Andy
One character in 9600baud takes a little over 1ms. If you are using UART interrupts to store received chars into a FIFO, there is not any chance of losing line data due to processor performance.
you have no idea what some so called programmers do. I have seen "ISR overload" failures at 11,0292MHz/9600 baud
Erik
you have no idea what some so called programmers do.
... cram lots of floating point arithmetic into an ISR ?
Evaluate menu commands in ISR?
"you have no idea what some so called programmers do."
Hm, good point there. But quoting you from another thread: "I know NO "good embedded '51 programmers" That are not fluent in assembly whether they use it or not."(http://www.keil.com/forum/docs/thread8892.asp).
The same applies here. It takes good understanding of the compromises and parameters for task distribution to achieve good realtime performance. But the rules are really simple.
Of course one can use printf in an interrupt, or perform floating point math, and starve the processing bandwidth. But then we are not talking about limitations of the architecture or of the processor (as the OP asked about), but of the systems designer.