ESP32-CAM with ch340g needs other ser-uart signals (Ubuntu 22.04)

[ghvau]

With a new ordered ESP32-CAM (with usb mb-board, ch340x !) module I can't get a connection to jama. (-> github source code v1.2.0)
Error: ... device not compatible !

After testing with some other IDEs like Thonny and ESPlorer i get generally the same situation!
But with the ESPlorer I have additionally the possibility the set/clear the interface signals.
I can use the ESPlorer when I clear the signals RTS and DTR !!!

And now: when I start inside jama the device connection function and I see the message "Attempts to connect ..." I start in a second process a small c-prog (ioctl()) and clear both signal -------> and the device was connected !!!
ioctl(fd, TIOCMBIC, &DTR); //clear DTR pin
ioctl(fd, TIOCMBIC, &RTS); //clear RTS pin

It will be nice when you try to open the jama world for the ESP32-CAM or ch340 user with an alternative device open (cleared RTS/DTR).

Addition: Thonny can also configure dtr = False rts = False in his setup file [esp32].

[jczic]

Hello @ghvau, thank you for your feedback!

Just, what OS are you on?

Indeed, I see on pySerial that there can be sometimes particular behaviors of RTS/DSR on certain system.
Could you test by adding the following 2 lines in the file src/esp32Controller.py at line 180,
next to self._isConnected = True :

self._repl.rtscts = False
self._repl.dsrdtr = False

This could perhaps solve the problem?

[ghvau]

Hi @jczic, I use Ubuntu 22.04, see headerline. I try your proposal in the area of line 180, also on different positions arround. The only thing which changed was the error: "Can't open serial port" and still " ... device not compatible". Depending of the impelemetation of you proposal its a diffenent of saying to jama to ignore the RTS/DTR lines and an active drop down the lines with system call (ioctl) to clear the lines. I thing the device needs switching to low pegel to start communication? My workaround c-prog (ioctl()) during "Attempts to connect ..." still works.

…

On 02.05.23 08:23, Jean-Christophe Bos wrote: Hello @ghvau <https://github.com/ghvau>, thank you for your feedback! Just, what OS are you on? Indeed, I see on pySerial that there can be sometimes particular behaviors of RTS/DSR on certain system. Could you test by adding the following 2 lines in the file |src/esp32Controller.py| at line *180*, next to |self._isConnected = True| : self._repl.rtscts = False self._repl.dsrdtr = False This could perhaps solve the problem? — Reply to this email directly, view it on GitHub <#41 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A56V3ZRPFX6QK7GZACYHP5LXECR7BANCNFSM6AAAAAAXPL4I7Y>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[jczic]

Hmm, it seems that the problem comes from a bad support of line support when connecting/reconnecting with the serial port on some hardware.

Actually, disabling the lines is not supposed to be a solution, but check out this discussion with people who had similar strange problems: pyserial/pyserial#124

Because Jama does not use hardware control at all and only 2 wires are used for serial exchange.

[ghvau]

OK, there are maybe some problems with the serial interface (pyserial/pyserial#124),
but here it was a problem with the device (ESP32 with ch340):

With a dynamic trace tool (statserial) I can see the following:
1.When I connect the device, the tty port was created with signals RTS/DTR are high,
2. then I start my c-prog (ioctl()) and set RTS/DTR to low,
3. then I start jama, no change of the RTS/DTR level, still low,
4. then I start the "connect device" command, the RTS/DTR level goes to high,
5. then the error occur "... not compatible" (can overcome when I start c-prog (2.) during "Attempts to connect ...."

If I use a ESP32 with cp2102 the level RTS/DTR are unimportant !
Its for me definitive a problem with the device, which needs a low level.

I know a workaround :-)
Thanks.

[jczic]

Yes I understand but it seems that there can be the level which passes to high by itself during the connection, not because of pySerial but from the serial driver under Linux.
Have you also tried to directly pass rtscts = False and dsrdtr = False as parameters to the creation of the Serial( ....) class next to xonxoff = False?

[ghvau]

There is no change if I pass the the both parameter directly inside Serial(). But I found a syntax to change the level directly and I can see the success in the trace tool, the lines changed with the "open device" command! try : self._repl = Serial( port = devicePort, baudrate = baudrate, timeout = None, rtscts = 0, dsrdtr = 0, xonxoff = False, exclusive = True ) self._isConnected = True self._repl.setRTS(False) <------------------------------ self._repl.setDTR(False) <------------------------------ except : But I didn't find the right place in the whole program, because there is no change in the error message. It seems that the setting to low must be during/after the "Attempts to connect...", that the device can detect the change from high/low?!

…

On 02.05.23 23:43, Jean-Christophe Bos wrote: Yes I understand but it seems that there can be the level which passes to high by itself during the connection, not because of pySerial but from the serial driver under Linux. Have you also tried to directly pass |rtscts = False| and |dsrdtr = False| as parameters to the creation of the |Serial( ....)| class next to |xonxoff = False|? — Reply to this email directly, view it on GitHub <#41 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A56V3ZT5UGOOCYIV3OS57K3XEF5ZLANCNFSM6AAAAAAXPL4I7Y>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[ghvau]

I found a position (~ line 188) , and device will be connected !!!

try :
self.InterruptProgram()
self._repl.setRTS(False) <---------------------
self._repl.setDTR(False) <---------------------
self._switchToRawMode(timeoutSec=connectTimeoutSec)

Device: AI-Thinker ESP32-CAM (clone) + USB MB Board / CH340G, original MP 1.19.1 works now: ->

[jczic]

Oh great! Good news :)

I understand then that your device may be to have to reboot after InterruptProgram(...) and set the IOs to HIGH automatically.
Can you try the Reset button in the Jama menu to see if it works well and the device stays connected after it reboot?

Also, just a point: setRTS and setDTR are indicated deprecated in pySerial and are replaced by the 'setters' directly (as I had write above):

self._repl.rtscts = False
self._repl.dsrdtr = False

Does it work the same way if you use this instead?

[ghvau]

The jama Reset button works, a new connection automatically established. The rtscts/dsrdtr was described as "enable/disable hardware flow control" (2 signals in the name) and don't work here. The setDTR/RTS was described as "setDTR/RTS to defined level" (1 signal in the name) and worked in this situation. I also see the Info "deprecated", and the new syntax self._repl.dtr=False self._repl.rts=False also works !

…

On 03.05.23 20:06, Jean-Christophe Bos wrote: Oh great! Good news :) I understand then that your device may be to have to reboot after |InterruptProgram(...)| and set the IOs to HIGH automatically. Can you try the |Reset| button in the Jama menu to see if it works well and the device stays connected after it reboot? Also, just a point: |setRTS| and |setDTR| are indicated /deprecated/ in pySerial and are replaced by the 'setters' directly (as I had write above): self._repl.rtscts = False self._repl.dsrdtr = False Does it work the same way if you use this instead? — Reply to this email directly, view it on GitHub <#41 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A56V3ZXR5V7GSLEZZ77EPK3XEKNB7ANCNFSM6AAAAAAXPL4I7Y>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[jczic]

Great, thank you @ghvau, I added that in the code and update src.
As this is especially for Linux, I won't compile new binaries for Mac&Win but that's ok.

Commit : d834cda 😉

[ghvau]

Thanks also.

…

On 04.05.23 00:01, Jean-Christophe Bos wrote: Great, thank you @ghvau <https://github.com/ghvau>, I added that in the code and update src. As this is especially for Linux, I won't compile new binaries for Mac&Win but that's ok. Commit : d834cda <d834cda> 😉 — Reply to this email directly, view it on GitHub <#41 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A56V3ZVUTRKN34KS6EGMCK3XELISBANCNFSM6AAAAAAXPL4I7Y>. You are receiving this because you were mentioned.Message ID: ***@***.***>