Fix: Fixed a reading bug in MODBUS-RTU when using DMA

[FoLeaf]

Subject: fix(rtu): Correct flush implementation for DMA transport layer
OverviewThis PR fixes a bug in the DMA-based RTU transport layer where the flush() operation was ineffective.
The original read_serial function in nanomodbus_config.c did not properly handle a zero-timeout call, which is used by the core library to flush the receive buffer. This failure to clear the buffer makes the Modbus client susceptible to spurious data or late responses on the bus, leading to incorrect errors such as NMBS_ERROR_INVALID_UNIT_ID even when the physical communication is successful.
Steps to Reproduce
Environment: Configure nanomodbus as an RTU client on an MCU using FreeRTOS. Use the DMA-based transport layer implementation for read_serial that relies on a FreeRTOS queue (rtu_rx_q) populated by a UART ReceiveToIdle_DMA interrupt.
A special case has been added at the beginning of the function. If byte_timeout_ms is 0, the call is identified as a flush request. Instead of attempting to read from the queue, the function now calls xQueueReset(rtu_rx_q).
This ensures that any flush() call reliably and instantly discards all pending data in the receive queue, guaranteeing that each new Modbus transaction begins with a clean state. This makes the client robust against noise and synchronization issues common in physical environments.
Test ResultsThis fix was validated on physical hardware. No formal unit tests were written.
Before Fix: When polling a physical slave device in an environment with typical electrical noise, the application frequently reported NMBS_ERROR_INVALID_UNIT_ID. A logic analyzer confirmed that the frames on the bus were largely correct, but spurious data was present between transactions.
None.

[donghoonpark]

I've thought that flush function customization would be more proper implementation because the noticing the flush situation in read function with parameter value is quite unclear. So I made a PR #108. If you have any opinion it would be really grateful to let me know.