10 years, 1 month ago.

question on BufferedSerial::prime function

Hi,

I have question about the following code. We are calling the BufferedSerial::txIrq() function and also attching to TxIrq. What is the purpose of the last two lines ?

void BufferedSerial::prime(void) { if already busy then the irq will pick this up if(serial_writable(&_serial)) { Serial::attach(NULL, Serial::TxIrq); make sure not to cause contention in the irq BufferedSerial::txIrq(); only write to hardware in one place Serial::attach(this, &BufferedSerial::txIrq, Serial::TxIrq); }

return; }

Question relating to:

Inherit from Serial and use software buffers for TX and RX. This allows the UART peripherals to operate in a IRQ driven mode. Overrides most (but not all) stdio functions … buffer, BufferedSerial, BufferSerial, Serial

1 Answer

10 years, 1 month ago.

TxIrq is the single place writes to hardware occur. The TX interrupt is off by default and until there is data in the buffers. To enable the TX interrupt in a semi-generic way (ie some always fire when available and others only once) we make that call and then enable the TxIrq to empty the rest of the buffer.

As per my understanding, the function call to BufferedSerial::txIrq(); transmits the entire software buffer as we have a while loop. After this function call enabling the Txirq to empty the rest of the buffer does not seems correct. What is your opinion ?

I have clearly understood how the RX interrupt works. I am not quite sure how you are using the TX interrupt in your code.

Can you please describe more about it.

posted by Jags K 24 Oct 2014

Sure. That loop fails when the hardware FIFO isn't longer writable (ie: full). Then it exits and and the TX interrupt picks up. Behavior will change based on FIFO size and TX irq triggers but that shouldn't much matter. The idea is that it just wont block.

posted by Sam Grove 24 Oct 2014