TWAI transmit handling design is intentional or accidental? (IDFGH-14399)

[kdschlosser]

Answers checklist.

• I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.

v5.2.3

Espressif SoC revision.

ALL

Operating System used.

Linux

How did you build your project?

Command line with CMake

If you are using Windows, please specify command line type.

None

Development Kit.

ALL

Power Supply used.

External 5V

What is the expected behavior?

To be resource efficient.

What is the actual behavior?

This is a long read so be warned.

My assessment of the TWAI driver could be flawed. Someone with knowledge of the low level aspects of the ESP32 TWAI hardware and the driver would know. If my assessment is flawed then tell me it is. But this is what I am seeing by looking at the code.

I am writing some code to be able to use the TWAI driver and while I am doing i realize that the way it needs to be done is not going to be very resource efficient. Using a polling loop to check for alerts just doesn't seem the best thing to do. I started looking at the TWAI driver code and I noticed something that kind of threw me. The way that frames get transmitted, It is done within the context of a single ISR that handles everything TWAI related.

The transmit workflow is like this.. When the user transmits a frame that frame gets placed into a queue, it doesn't actually get transmitted right away even if there isn't a frame being transmitted. The transmit actually occurs inside of an ISR that gets triggered for the transmit buffer being empty . Think about that for a second. That means that the ISR needs to be triggered for the transmit buffer being empty over and over and over again even when there is nothing to be transmitted. This would need to happen at a pretty high rate of speed.

how the workflow should be when transmitting a frame is like this. The only time that an ISR should occur for the transmit buffer being empty is when it changes from having data in it to being empty. When a user wants to transmit the transmit buffer should be checked to see if there is data in it. If there is not then data is loaded into the buffer and it gets sent. If another call is made to transmit and the buffer still has data in it then the transmit will be queued. When the buffered data is finished being transmitted the buffer will change from being used to being empty and the ISR would occur. That is when the queue gets checked and if there is another frame to be sent then it gets sent and the process repeats until the queue is empty and at that time no more ISR's would occur for the transmit buffer being empty.

My understanding of how an ISR works might be incorrect so let me know if it is wrong. The over simplification of it is the state of the CPU needs to be saved. The ISR code loaded and ran and then the state gets restored. Doesn't that take time to do? Nothing is free in this world, everything has a cost (the biggest of life's lessons). If too many ISR's are taking place on a CPU core can you end up with undefined behavior occurring? Would there be a performance impact from all of the context switching to handle the ISR's?

I would imagine this would need to happen at a regular interval for the ISR happening for the transmit buffer being empty. It would need to happen at a fairly high rate of speed otherwise it would cause latency issues. Correct?

Is the hardware transmit buffer only large enough to hold a single frame? This question is to answer if the use of the word "EMPTY" is correct or not. If the hardware buffer is able to hold more than one frame and the ISR occurs as a notification of there being space available to place another frame into the hardware transmit buffer then the buffer is actually not EMPTY, it could possibly have data in it that is still transmitting. That would mean there is some incorrect naming in used in areas of the driver. I would think that if the hardware buffer was able to hold more than a single frames worth of data that there would be a loop over the transmit queue loading all frame that could fit in the available space. This is not the case so I imagine that the hardware transmit buffer is only able to hold the data for a single frame. Maybe I am wrong?, Maybe I am right? IDK the answer to that. It is something that needs to be known in order to write the most efficient code that is able to be written.

I do not know enough of the low level aspects of the ESP32 to know if what I am seeing is actually a design issue in hardware or in software, It definitely looks like there is an issue with it. What I can tell you is that there has got to be a better way of handling this. The number of ISR's that have to be occurring when using the TWAI hardware has got to be extremely high and there should be a way to mitigate how many of them are occurring. The user is able to choose which "alerts" they want to be notified for happening but altering which ones they want to know about has no impact other than the alerts value being stored in a variable for later collection by the user. The alerts still happen and consume the same amount of processor time whether or not the user wants to be notified about them.

Steps to reproduce.

This doesn't need to be reproduced as it is more of a question that it is something that causes a defined error that is able to be seen.

Debug Logs.

No response

More Information.

No response