TMS570LC4357: EMAC TXINTSTATRAW flag

Hi Durga Choudhury,

Actually, what they are saying here is that, the flags in the registers RXINTSTATRAW and TXINTSTATRAW will get set without actually need of enabling the corresponding interrupts. That means these status flags will get set without actually needing to enable the interrupt using the TXINTMASKSET and RXINTMASKSET registers.

May be in some controllers right, the interrupt status flags will get only SET when the corresponding interrupts are enabled right but here it is different, the interrupts will get generate only when we enabled the interrupt flags, but the status flags will get SET without depending on the interrupt enabling status.

Durga Choudhury said:

I am not sure how this is supposed to work because unless the interrupt is at least ack'd, it will stay asserted and the ack is usually done in a handler. So basically I have two questions:

1. What is the intended use case for this (and other similar flags)?

Durga Choudhury said:

2. Is there a way to poll for the completion of a EMAC transmit without resorting to interrupts? In the real time application that I have, timing jitter (associated with interrupts) is unacceptable, whereas polling can be done from an idle task without affecting any real time guarantees.

That is true, i mean ack'd is done in handler. what if we are not using interrupt method what if we are using a poling method. In those situations, polling these flags will helpful right?

So my conclusion here is that, these flags in interrupt register will helpful only in the polling mode and if you are using interrupt mode then these flags will get cleared in handler code it self after processing the corresponding data.

--

Thanks & regards,
Jagadish.

Hello Jagadish

Thank you very much for your prompt response, but I am afraid I still don't fully understand:

Without ack'ing, those flags will remain set. So they are not very useful because they will *always* read 1 after the first transmission. The problem I have is that the CPU can queue packets faster than the EMAC can transmit them, especially for larger packet sizes. So I want to know when the last packet is done before I queue another. Interrupt is not a good solution for me because there are some tasks in the code that require tight real-time guarantees. Polling something in a tight loop is also something I'd like to avoid because that is sub optimal. What I was hoping for is to be able to read a flag that says if the transmitter is busy or free. Can you confirm that such a mechanism exists (and if so, what it is) or it does not exist?

Best regards

Durga