strange design for the STR750 UART transmit interrupt

[nir]

Posted on June 07, 2008 at 15:59

strange design for the STR750 UART transmit interrupt

[nir]

Posted on June 03, 2008 at 03:50

I would like to know why, concerning the UART transmit interrupt, the STR750 should be different from other UARTs and even different from the previous STR711?

It is common that when dealing with transmit interrupt, the interrupt is triggered when the transmit buffer is empty. But in the STR750 the interrupt occurs if the buffer 'passes through' a predefined buffer threshold level. This design is dangerous, since closing interrupts momentarily for some reason and then opening them might lead to a miss of the transmit interrupt.

[kleshov]

Posted on June 03, 2008 at 07:47

The manual says that the transmit interrupt request is asserted when 'transmit FIFO becomes <=' the watermark. Note the sign '<='. To clear the interrupt requst you have to fill the FIFO above the watermark. Disabling interrupts will not clear the interrupt request. I cannot see a problem here.

[nir]

Posted on June 03, 2008 at 09:10

You have some inaccuracies in your answer:

Suppose threshold level of transmit UART was set to 1/8 or 2 bytes, and currently transmit FIFO has 3 bytes. In that case an interrupt will occur when one byte or more will be transmitted by the UART. Now, suppose that now there is nothing left to push to UART buffer. According to your reply, the interrupt is pending until more bytes are pushed to the UART - From what I see on my target, in that case, after handling the interrupt and clearing it, of course, the interrupt is not pending any more and there is no need to push more bytes to the buffer. But there is another problem that rise when using this method: 1. It is common that the bytes are pushed into the transmit FIFO only in the interrupt handler. Outside the interrupt bytes are pushed only into the RAM buffer. Using the STR75 method, one has to push several bytes to the FIFO first (until the threshold level) outside the interrupt for letting the interrupt cycle start to work and from that point push data into RAM buffer that later in the interrupt will be pushed to the UART FIFO. [ This message was edited by: nir.aloni on 03-06-2008 15:07 ]

[kleshov]

Posted on June 03, 2008 at 15:38

I am not able to discuss this in detail since I don't have an STR750 to experiment with. My experience is limited to STR710. I thought it was just a case of misunderstanding.

But based on my experience, I would not be surprised if some peripherals behaved, let's say, suboptimal. Documentation could be better, too. For example, the I2C peripheral of the STR710 looks quirky, and sometimes you cannot deduce its behavior from the docs and have to resort to experiments. The flash memory interrupt is simply broken. Sometimes I wonder why they have to re-implement the UART each and every time. There are plenty of tried and true UARTs out there, just copy one of them...

[jpeacock2]

Posted on June 04, 2008 at 14:13

The UART TX interrupt works fine on the STR750. An interrupt occurs when the FIFO transitions through the buffer watermark, generating an IRQ to the EIC, but the interrupt is latched in the UART until cleared. Momentarily disabling interrupts does not clear the request; the ISR for the UART must clear the IT pending bit for the IRQ to be cleared from the EIC.

And the assumption that the TX FIFO has to be filled from an ISR doesn't always apply. I use the TX FIFO as the buffer, filling all 16 positions in a print task, then suspend the task for the time it takes to empty the FIFO. No TX interrupts and low overhead on the print task, since it only wakes for every 16 characters. I could have used the TX watermark interrupt instead of timer to wake the print task, but it happened to work out better for the application since tx output is a very low priority.

[nir]

Posted on June 05, 2008 at 05:00

The example of the print task is an excellent example for showing how the STR75 UART transmit section design is limitting:

1. If you don't use the watermark, the task schedualing is dependent upon the baud rate of the UART. This works until someone decides to change baud rate without knowing that this affects the schedualing. 2. If you do use the watermark interrupt, you will have to do some checks to see how many bytes can be pushed at interrupt time to transmit buffer, instead of doing nothing and pushing 16 bytes when the interrupt is for TX buffer empty.

[jpeacock2]

Posted on June 05, 2008 at 14:47

I wouldn't call it ''limited''. I do a time delay based on baud rate solely due to application requirements, to minimize context switching and interrupt time by a very low priority task. As for filling the fifo, I don't care how much space is available, I just fill it from the task message queue until the appropriate flag is set.

[nir]

Posted on June 07, 2008 at 15:59

if it works for your application, fine. Just make sure no context switch happens while you push bytes to buffer which can cause inter-byte time out from the peer, or a specific task runs long enough to make the delay longer than you thought. Anyway, my issue is about the transmit interrupt of the UART and you do not use it.