Rework of esp uart interface #45
Conversation
I cannot replicate this, do you have an example of corrupted output?
This is very odd as most of the code is direct register access. Have they messed up their register definitions now?
How could that be? Are there varying silicon bugs in different production runs of the ESP32 that is masked by the library code?
Ok, could it be that the problem is with bCNC then? When I save the output via the ioSender config app I cannot see anything wrong in the data. Perhaps bCNC cannot handle high baud rates correctly? And your reworked code slows the data rate down enough for bCNC to handle it? |
Exaclty! Do you pretend to update the driver code to newer versions of idf in the future? Thanks for the help and for the great work you put into this project, and sorry if this should have been an issue. |
As long as the 4.2 version works I am in no hurry. Last time I updated I had to spend many many hours updating and verifying my code, I am not yet in the mood to do that again. You can do it?
No problem, it is ok to get the code checked. And it kind of verifies that my approach to use "bare metal" register access, at least for time critical/frequently called parts of the code, gives better performance. |
|
I will test the idf 5.0 one more time and try to make it work. If I get some good results I make a PL or a discussion about |
Hi!
A time ago I discovered a bug on my fork of this repository. When I set the baudrate to 460800 and above, when getting the response of some commands like "$ESG" or "$ESH" the list of settings was broken. (when the baudrate is 460800 this bug occurs sometimes, but when using 921600 it always occurs).
I was thinking that this was a problem with my fork, but when setting the main repository to the same settings, the same problem occurs. When testing with Teensy 4.1 nothing of this occurs.
So, after seeing this issue #43 , I tried to port the code to esp-idf v5.0, but this gave a lot of problems when compiling(it's not a stable version). So, for me, this is not an option right now.
Then I use the esp-idf v4.4(the latest stable) and the uart code simply bugs. It seems that the isr was reading the full ringBuffer every time a char is passed to the input. Simply compiling the code with the idf v4.4 gave me this error.
I reworked the code and make it work with the high-level functions of uart, and this resolve all the issues I have written.
Bonus: Using these high-level functions will help when migrating to esp-idf v5(when this becomes stable).
To clarify, using idf v4.3 and the current code for uart was giving me these errors of response. To resolve this I migrate the code to the high-level functions. And with this migration, we can now use idf v4.4 .
In my tests, all worked well, the only thing that I don't know if continues to work is the Modbus code. With the different handling of the isr I needed to change the code a little bit.
Obs: The problem with the responses only occurs when running a sender, if I simply ask for $ESG on the esp-idf monitor, it gives me all the responses correctly. I get this error running bCNC and tried different polling rates and no matter what I choose the responses are always broken.