Avoiding race conditions in serial communication

[KaluzaKlein]

I am working on an Infineon board sending characters through the serial interface. Two interrupts are provided. One is raised just before the transmission of the last bit on the line and one just after that, when the Tx buffer is cleared. What is considered the best way to make the transmission? Is asking whether the buffer is free or not before transmitting enough?

 

[kalbun]

I think the answer depends from several factors.
The first ISR allows you to reduce latency time, and could be good if you need to transmit at high baudrate ("high" means a speed that the board has problems to manage)
In all other cases, I would stick on the second ISR, so you are guaranteed that the TX buffer can accept more data and reduce the risk of overflow or other serial errors.

 

[KaluzaKlein]

I'm sorry I wasn't clear enough. I was referring to the first character to be transmitted. I know that I am working on a non multi-tasking system, but something our professeur said baffled me: "You can't just ask for the buffer and then send because someone else might have taken it in the meantime". I can only think of a problem arising in a situation like this: In the main execution I ask for the buffer. It's free. At that specific moment an Rx interrupt is called whose ISR sends a response over the serial line and then returns. If the main execution continues before all the contents of the buffer have been written on the line (which actually depends on the bit rate of the line and the CPU frequency), then the character will be destroyed because the next main instruction will be to write on the buffer.
I can avoid situations like this by using an interrupt for transmission too and doing a good prioritization of the Rx an Tx IRs. However the problem of the first transmission will remain, and I am not even sure if it is worth the effort.

 

[kalbun]

Hmmmm.... AFAIK read and write serial buffers are separated. You read and write to the same address, but in facts you access two different registers/queues. So that specific problem shouldn't happen.
You could have a problem if two different parts of your code --e.g. the main code and one ISR-- try to write to serial line at the same time. In this case you need a mechanism such as a semaphore, or you could put the code that writes to serial in a critical section (well... so you may solve the race condition just to end up with a starvation problem :-D )

 

[KaluzaKlein]

Yes, this is exactly what I was thinking, because the Rx ISR that I mentioned transmits a response back (so it uses the Tx buffer). I guess it all comes down to how critical is what you're doing. If I try to add complexity I might end up blocking the program completely. On the other hand, you see gibberish on a terminal all the time, no biggie!