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
How fast is your processor? ie, what clock frequency, and how many cycles per instruction?
What else is it doing?
I had a Triscend E5 running at 24MHz with four 9600-baud serial ports, all ring buffered in XDATA and not dropping characters
which derivative? show your ISR atomicity? other ISRs?
Erik
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.
I'm running a P89C668/V664 (18.432MHz, 6clocks/cycle) with multiple serial data channels (UART @ 115200baud, SPI, I2C @ 370KHz), with a MODBUS packet rate of 20ms/pkt, and it doesn't drop a single packet.
The XDATA myth is often mentioned as a 8051 'issue'. The fact that XDATA takes one extra cycle to be accessed makes absolutely no difference on the vast majority of applications. To compute lvalues for subscripted data from pointers, for example, takes much longer than a 16bit access to XDATA. This is NOT your problem. The fact that the core runs at 12clocks is a much more important performance issue.
One situation where you will want to use DATA instead of XDATA is when you have a high-frequency interrupt, like a timertick, and have to update 10 timers. The extra few microseconds of XDATA access will be relevant in that case.
you have no idea what some so called programmers do. I have seen "ISR overload" failures at 11,0292MHz/9600 baud
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.