[BUG] Modbus RTU slave response time is too high

[raiden00pl]

Description / Steps to reproduce the issue

I'm just playing with Modbus RTU in NuttX and I see that the slave response time is too long and approximately constant at 50ms. Inter frame delay for modbus is 3.5 character, so this delay is much too high (should be below 10ms).

It is directly related to timeout for this select():

nuttx-apps/modbus/nuttx/portserial.c

Lines 99 to 110 in e336eba

	tv.tv_sec = 0;
	tv.tv_usec = 50000;
	FD_ZERO(&rfds);
	FD_SET(iSerialFd, &rfds);
	/* Wait until character received or timeout. Recover in case of an
	* interrupted read system call.
	*/
	do
	{
	if (select(iSerialFd + 1, &rfds, NULL, NULL, &tv) == -1)

Decreasing this value reduces the response time accordingly. It looks like there is something wrong with this serial logic.

Has anyone verified the slave response time with NuttX before? I don't know if it's broken from the start or is it something new.

On which OS does this issue occur?

[OS: Linux]

What is the version of your OS?

doesn't matter

NuttX Version

master

Issue Architecture

[Arch: all]

Issue Area

[Area: Modbus]

Verification

• I have verified before submitting the report.

[raiden00pl]

I fixed it with this change railab@4283338
Response time is now 10ms-20ms for 19200 baud but this need more testing.

Is there anyone more experienced in Modbus RTU and could help with verification? I don't really like this solution but the FreeModBus architecture is terrible and I don't see any other way.

[cederom]

Yeah this lib kinda sux, but from what I remember it is possible to configure timeouts, I used it recently and plan to so something with it on NuttX in April so I will test and report other issues when found, thanks @raiden00pl :-)

Btw on what target did you notice this problem? All of them? ESP? STM?

[raiden00pl]

tested on stm32 with DMA disabled (read is done byte by byte), but if I understand the problem correctly this is the case for all architectures. After a frame is received by slave, we stuck for 50ms in select() waiting for a next byte and only after leaving select() due to timeout (frame is already complete) we start to handle received frame, which results in 50ms delay.