On 06.01.2022 16:05, Uwe Kleine-König wrote: > On Wed, Jan 05, 2022 at 04:34:21PM +0300, Sergey Organov wrote: >> Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx> writes: >>> Maybe it's more sensible to make this even more dynamic: e.g. keep it at >>> 1 as default and increase the water level when a certain irq frequency >>> is reached? >> >> Too complex, and too many questions, I'm afraid. What is "irq >> frequency", exactly? For this particular driver, or overall system? >> Measured on what time interval? What is the threshold? Do we drop the >> water level back to 1 when "irq frequency" is down again? Will we just >> create re-configure storm at some conditions? Etc..... > > It could be as easy as increasing the waterlevel by one if an RX irq > happens with USR1.AGTIM = 0 and reset to 1 if USR1.AGTIM = 1. This is indeed simple, but I fail to see the actual benefit of doing so. > This makes sure that receiving at a low frequency makes the hardware > interrupt the CPU early, and a burst doesn't starve the CPU. If the communication involves multiple characters sent in burst (frame), and includes some sort of CRC check (so only complete frames are useful, as no partial processing can be done because checksum has to be checked first), then it is the latency after the last character (not the first) that matters. RXTL upper value has to be capped. If RXTL goes above CTSTL then it would limit throughput if hardware flow control is enabled. If hardware flow control is not enabled, then the higher RXTL gets, the higher is the risk of not reading RxFIFO in time. Setting RXTL to quarter of the RxFIFO (8) seems to leave enough time for RX interrupt and at the same time noticeably lowers the interrupt rate. Best Regards, Tomasz Mon
