Handle control pin timing

[brainelectronics]

Fixed

• Use ticks_diff to get correct time to lower control pin after sending the frame, see #72

[brainelectronics]

Hey @beyonlo and @panther50500 , let's give it a try :) https://test.pypi.org/project/micropython-modbus/2.3.5rc82.dev73/

[beyonlo]

Hey @beyonlo and @panther50500 , let's give it a try :) https://test.pypi.org/project/micropython-modbus/2.3.5rc82.dev73/

Thank you @brainelectronics for this PR. Sorry for the long time to test, but I was a bit sick. I'm feeling better now, and I will to test it in this week (probably tomorrow).

Just to be aligned: I will test this PR with the examples (sync and async) from @GimmickNG. In my opinion, now that this lib is more stable, I think that is a good idea that we use always the same example for the tests, where the examples can to do complete tests, like as those does. If you agree, maybe is a good idea, on the future, to put that examples as official examples for sync and async. What do you think?

[brainelectronics]

@beyonlo I hope your getting better! No worries, just take your time. I agree to use the sync and async examples for testing. I hope to get that PR merged soon, as I have several systems out in the wild with automatic updates, I have to ensure all changes are working as expected. I'm quite sure that this change will work the same way on sync and async, but you never know. Let's see ☺️

[beyonlo]

@brainelectronics The Slave RTU works, but the Master RTU do not works.

Reports:

Test1: Slave RTU 2.3.5-rc82.dev73 running with Master RTU 2.3.5-rc82.dev73: Slave RTU works, but the Master RTU do not works - to be fair, the Master works very very rarely, but in just the first time that I run it, and just when I do power off and power on from the energy.

Test2: Slave RTU 2.3.5-rc82.dev73 running with Master RTU 2.4.0-rc82.dev56: Works, with many CRC errors as you already know, but works.

Test3: Slave RTU 2.4.0-rc82.dev56 running with Master RTU 2.4.0-rc82.dev56: Works, with many CRC errors as you already know, but works.

Do not have differences between Test 2 (Slave new version) and Test 3. I was thinking that this new version could fix the CRC erros, but not yet.

Ps1: 2.4.0-rc82.dev56 was the last version that I tested (and works) on the PR #56 Ps2: Was tested just sync version. The async version was not tested because it still have problems as detected in PR #56

Slave RTU: (2.3.5-rc82.dev73)

$ mpremote run rtu_client_example.py 
MicroPython infos: (sysname='esp32', nodename='esp32', release='1.20.0', version='v1.20.0 on 2023-04-26', machine='ESP32S3 module (spiram) with ESP32S3')
Used micropthon-modbus version: 2.3.5-rc82.dev73
Using pins (17, 18) with UART ID 1
Setting up registers ...
Register setup done
Serving as RTU client on address 10 at 115200 baud
my_coil_get_cb, called on getting COILS at 123, currently: [1, False, False, False, False, False, False, False, False, False, False, False]
my_coil_set_cb, called on setting COILS at 123 to: [False]
my_coil_get_cb, called on getting COILS at 123, currently: [False, False, False, False, False, False, False, False, False, False, False, False]

Master RTU: (2.4.0-rc82.dev56)

$ mpremote run rtu_host_example.py
MicroPython infos: (sysname='esp32', nodename='esp32', release='1.20.0', version='v1.20.0 on 2023-04-26', machine='ESP32S3 module (spiram) with ESP32S3')
Used micropthon-modbus version: 2.4.0-rc82.dev56
Using pins (17, 18) with UART ID 1
Requesting and updating data on RTU client at address 10 with 115200 baud

Status of COIL 123: [False, False, False, False, False, False, False, False, False, False, False, False]
Result of setting COIL 123 to True
Status of COIL 123: [False, False, False, False, False, False, False, False, False, False, False, False]

Traceback (most recent call last):
  File "<stdin>", line 53, in <module>
  File "examples/common/host_tests.py", line 159, in run_sync_host_tests
  File "umodbus/common.py", line 197, in read_holding_registers
  File "umodbus/serial.py", line 473, in _send_receive
  File "umodbus/serial.py", line 435, in _validate_resp_hdr
OSError: invalid response CRC

[brainelectronics]

see #75

The "culprit" is actually machine.idle() which uses an IRQ in the milliseconds range

Gates the clock to the CPU, useful to reduce power consumption at any time during short or long periods. Peripherals continue working and execution resumes as soon as any interrupt is triggered (on many ports this includes system timer interrupt occurring at regular intervals on the order of millisecond).