ESP-IDF support

[fedepell]

Adds support for serial for ESP-IDF and introduces a document on how to use it in that environment.

Assumes to be merged after #741 (I will rebase accordingly in case).

[cla-bot]

We require contributors to sign our Contributor License Agreement. In order for us to review and merge your code, please fill https://forms.gle/5635zjphDo5JEJQSA to get added. Your document will be manually checked by the maintainer. Be patient...

[cla-bot]

We require contributors to sign our Contributor License Agreement. In order for us to review and merge your code, please fill https://forms.gle/5635zjphDo5JEJQSA to get added. Your document will be manually checked by the maintainer. Be patient...

[diplfranzhoepfinger]

sorry, i overlooked this !

[fedepell]

sorry, i overlooked this !

No problem :) Sorry for my delay now, was on a short vacation ;)

I hope we can get this (ESP support in general, in some variant) in as it may be very handy to have it mainstreamed. Also I've done a lot of testing with my code (both serial and TCP) and works like a charm (while the official internal library has a lot of limitations, ie. trivially missing possibility to have multiple connections which is just addressed in the beta).

[robin-twice]

@fedepell Thanks for your efforts with the ESP-IDF platform support!

I've tried to use your implementation as well, but stumbled upon some issues and wanted to asked whether you can confirm that: Using the ESP-IDF UART VFS with Modbus RTU, the uart_read() function does return early on some special characters (0x0A, 0x0D) depending on the line endings, which then creates either CRC errors or incomplete messages thereafter:

2024-10-07 07:23:09 Waiting for a confirmation...
2024-10-07 07:23:09 <47><03><02><00><0D><0A><B1>
2024-10-07 07:23:09 ERROR CRC received 0xB10A != CRC calculated 0x4EF0
2024-10-07 07:23:10 [47][03][9C][98][00][01][25][13]
2024-10-07 07:23:10 Waiting for a confirmation...
2024-10-07 07:23:10 <8C><47><03><02><00>
2024-10-07 07:23:10 Request for slave 140 ignored (not 71)
2024-10-07 07:23:10 The responding slave 140 isn't the requested slave 71

I've found a ticket on the ESP-IDF project where this issue with VFS UART read() behaviour is being addressed:
espressif/esp-idf#14155

Would be interested in your opinion about that and whether you've seen similar issues.

[stephane]

Could you rebase your draft PR against master branch, please?

[fedepell]

Could you rebase your draft PR against master branch, please?

Rebased on master and squashed commits to one!

[fedepell]

@robin-twice : sorry for the late response, very busy period :(

I've noticed some seldom "bad crc" messages, but didn't investigate in big detail as I saw (I did many long term tests and kept statistics of errors by type and so on) the same (very low) amount, actually even slightly higher, using the ESP native modbus library (which may suffer from the same problem if it reads data same way?) which I compared to (so I assumed it was just my lab-grade cabling or the 485 level adapter I have flying).

I'll try to give it a deeper look ASAP, hopefully this weekend or next week!

[fedepell]

I just pushed a few moments ago two little changes:

• use uart_vfs_dev_use_driver instead of esp_vfs_dev_uart_use_driver as the latter is deprecated and resulted in a warning
• Add in the docs also a note of having possibly (if console UART is disabled, something I faced today ;-) ) to explicitly initialize the VFS in your code if needed (I would not put this inside libmodbus as it is a system wide decision) with uart_vfs_dev_register (see:

  libmodbus/src/esp-idf/README.md

  Line 54 in a4eb887

  solution. Be aware that if you are not using the UART0 as console (ie. you are

  )