Using espsoftwareserial on freeRTOS

[ramadhanafif]

I'm working on a project to communicate with other peripheral with UART with freeRTOS on ESP32.

I discover from experiments and other issues on this git, that to avoid write/read error, write and read cannot be preempted to other thread. Simple solution would be vTaskSuspendAll() and xTaskResumeAll() guard. However, since no context-switching is allowed this also means I cannot use vTaskDelay() or delay() or yield().

Upon inspecting your code, I discover that SoftwareSerial::write() uses lazyDelay() which contains delay(). At the moment, my workaround is to use lazyDelay()as wrapper to preciseDelay(). This has been proven to work quite nicely.

void SoftwareSerial::lazyDelay() {
    preciseDelay();
}

Technically, using preciseDelay() means hogging CPU, which can lead to error caused by watchdog timer. My current solution is just be disciplined and avoid writing long data at once.

My question is, what is the purpose of differentiating delay to lazy and precise? Is there a technical reason that the deadline is legal to be exceeded?

Additional question: to your knowledge, what are the issues that stopping this library to be fully supported in RTOS? Is there are potential bug that I might miss?

[nicklasb]

Actually, it shouldn't be impossible to make it independent of the Arduino (even the arduino-esp32) platform, and make it possible to run as a pure ESP-IDF-component. As far as I can see, the use of Stream.h is the only thing stopping it?

[dok-net]

PRs are welcome.

[nicklasb]

@dok-net As always. :-) Bit my question was serious, is it "only" stream.h that stops it, or am I missing something?

Because it seems that a stream.h-port to ESP-IDF would solve this issue for several projects now, perhaps that is something worth putting some hours into.

[nicklasb]

@dok-net , @ramadhanafif

Hm. I copied Stream.cpp and Stream.h into espsoftwareserial and removed the arduino-esp32 requirement. Looking at what happened when i built it, it would seem that it would work by just creating a small compatibility library with millis() et al? Yes, there are some conveniency functions around strings in Stream.h that might be harder, but espsoftwareserial (and many others) don't use anyway?

That said, I am not sure what solutions would fit into the vision of this library, any thoughts?

[ramadhanafif]

I think making it native to esp-idf are great steps forward. Hopefully we can minimize bugs caused by dependency to arduino library.

With that being said, I think some library uses Stream class to pass data around. Last time I saw this was in ArduinoJson library. Its very rare usecase, but it might be better to made another fork?

Is there a roadmap for this lib? @dok-net

Last time I attempted to modify softwareserial, I also run into issues with the WString.h. Do you encounter this one as well?

[dok-net]

@ramadhanafif I can only repeat myself, any substantial PR will be reviewed, but there is no ongoing work to modify this Arduino library to work on the IDF without an Arduino component, as Espressif calls it. Remember that the classic ESP32s are dual core, so without core pinning, there may be issues with IRQs.

[nicklasb]

@dok-net I'm thinking that a compat-style library would be a first step, as that would put all the specific functionality in one place. If one get that working, it becomes easier to see what better, more finalized, solutions could be made based on that.

If other libraries that use espsoftwareserial requires arduino-functionality that espsoftwareserial don't, I can't see how that is the responsibility for an esp-idf-compatible espsoftwareserial to help out with. Those cases will likely break for a million other reasons anyway. Or maybe I am misunderstanding what you said?

[dok-net]

@nicklasb Yes, indeed you've lost me. Please check https://docs.espressif.com/projects/arduino-esp32/en/latest/esp-idf_component.html I don't think I am going to spend any time on separating EspSoftwareSerial from Arduino, least not as long as the ESP8266 is the primary target of the library. But, PRs are welcome anytime, I would ask for a comprehensive addition to the README on how to build a firmware image in that case, the Espressif documentation is a lot of work to parse in my spare time given that I have no personal need for IDF-only builds.

[nicklasb]

@dok-net Oh, I am sorry, I tried to answer @ramadhanafif about his comment on "some library using Stream.h" and ArduinoJSON, but @:ed you instead! But you bring up a good point; the reason for me wanting to not having to use Arduino at all is that it:

1. Uses memory. (even worse if one still uses ESP8266:es)
2. Adds complexity, arduino-esp32 isn't a problem-free library to include.
3. Steals my life by making my projects take a lot longer to compile. :-)

Understood.

[dok-net]

I think it has been established that such an undertaking is a major design and implementation effort. I don't see myself investing my life's short time to spare your's anytime soon ;-) I'm closing this issue for that reason. If you ever like to submit a PR, please include complete building instructions or proper links to good documentation how to this at the same level of complexity as setting up the Arduino Core for ESP32, then I will gladly reproduce and review. Thanks for your interest in this project, but please remember that it was designed for the ESP8266, and the shifting focus on the ESP32s which in general should have been bestowed with a proper number of HW UARTs is still an undecided direction for this lib.