[Solved] Point of Interrupt based outgoing serial data?

[haxan7]

Interrupt based incoming serial data makes sense because you don't know when's the other device is going to communicate.

But i don't understand the point of implementing outgoing serial data using interrupts (as in EX_STISR.C example).

Am i missing something here?

[Ttelmah]

Imagine you are doing a lot of calculation/data manipulation, and sending long strings to another device.
Using 'polled' transmission, you have to wait for the transmission to finish, before you can get on and do the next calculation.
Using interrupt driven, data can be written to a RAM array, and you can be working out the next value, or designing the next string, _while_ the transmission is taking place. Far better.

For anything doing multiple jobs at once (PID calculations, timing, parsing data, etc. etc.), interrupt driven TX, is just as important as RX.

Best Wishes

[haxan7]

[Ttelmah]

No.

Bputc, will only stall, if there is not enough space in the array to take another character. Otherwise it tests if the UART interrupt is already enabled. If it is not, it just writes the character to the UART, and enables the interrupt. If it is, it just writes the character to the buffer, and returns immediately.

Best Wishes

[haxan7]

[RF_Developer]

Interrupt driven buffered IO has been around since the late fifties roughly. The main driver was that peripherals are slow and processors are relatively fast. So processors waiting for slower devices to input OR output was inefficient. With buffered interrupt driven IO, the processor could be doing something useful instead of just "waiting". Modern processors have got a lot faster, several orders of magnitude, but peripherals have only got a little faster relatively speaking; some have not got faster at all. So the waste of processor time due to waiting for unbuffered peripherals has got proportionally worse over time.

Interrupt driven IO was also a key enabling technology for multi-tasking. That's true even in most PIC applications, even those which do not use an RTOS. You can output a string, which takes several milliseconds at least, and while ISRs deal with that, main code can, say, sample and process the next few ADC , or deal with commands received and so on.

There can be a downside with some buffered IO. Byte orientated devices, most notably serial ports/UARTS, don't often have a means of code determining when a string or message has been transmitted. Message and block orientated devices, which in PIC world means CAN, USB and LAN, but in other computers includes disc controllers and the like, can tell other code, usually by interrupt, that a complete message or block has been transferred. I've worked with NXP ARM based microcontrollers that have a multibyte SPI, and allow SPI messages to be treated as single elements, whereas on the PIC they have to be dealt with as single bytes. That though can have a downside for SPI slaves, though ARMs, which are considerably more powerful than PICs, are much more likely to be used as SPI (and I2C) masters than slaves.