Help with TCP Serial Bridge

[John C. Carney]

I have followed the directions to compile my own firmware with TCP serial bridge support. I think the firmware binary has this support since it is a couple KB larger than the image that I compiled without TCP serial support.

I have configured two GPIOs as TCP TX and TCP RX. I have tried this on both the module configuration and configure template webui screens.

No matter what I try, I always get an error response from TCPBaudRate and TCPStart commands.

What am I doing wrong?

Thanks for your help.

John

[John Carney]

I figured out that it is not enough to configure "TCP TX" and "TCP RX" pins in the Configure Template webui screen. That simply edits the template. I also had to *activate* the template in the Configure Other webui screen. This allowed the TCPBaudRate and TCPStart commands to no longer error.

However, I am now having another problem. I have jumpered the TCP TX pin with the TCP RX pin as a serial loopback. I want to test if I can communicate to the device from a TCP client and have characters echoed back to the TCP client via the serial loopback. Note: these pins are not connected to a hardware serial interface. The hardware serial interface is being used by an energy monitoring sensor. Here are the log messages that I see:

02:23:11.322 TCP: to MCU/1: 6A6F686E0D0A
02:23:11.398 TCP: from MCU: 00000000000000000000000000000000000000

It appears that characters arrived correctly from the TCP client and were transmitted, but a longer string of 00 characters were received over the serial loopback. I see this behavior at low baud rate (1200 and 2400). At higher baud rates I see no received characters. Is this some kind of misconfiguration? Is it a signal / electrical issue. Unfortunately, I don't have a scope to observe the signal. Any help or suggestions is appreciated.

John 

[Philip Knowles]

That's why I hate Templates. Deactivate the Template and make changes in Configure Module then you know that the changes will happen.

You could try GPIO15 for Tx and GPIO13 for Rx as they are the second hardware serial GPIOs.

It may be worth trying the zbbridge pre-compiled bin (as TCP is enabled in that) just to check you haven't made a mistake in compiling.

Regards

Phil K

Get Outlook for Android

---

From: sonof...@googlegroups.com <sonof...@googlegroups.com> on behalf of John Carney <jcarn...@gmail.com>
Sent: Thursday, April 21, 2022 2:37:23 AM
To: TasmotaUsers <sonof...@googlegroups.com>
Subject: Re: Help with TCP Serial Bridge

 

--
You received this message because you are subscribed to the Google Groups "TasmotaUsers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonoffusers...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/sonoffusers/44d3bc48-b6c1-49c2-8ab2-c8e480865264n%40googlegroups.com.

[John Carney]

After studying the software UART code, it seems to me that what I am trying to do will not work unless I use a hardware UART interface. For the soft UART, the serial transmit is synchronous and the serial receive is asynchronous based on an interrupt triggered by a transition of the signal on the RX pin. At low baud rate, the transmitter starts bit banging and yields during each bit time. After the first bit, the receiver interrupt handling starts sampling the RX pin and waiting each bit time of the byte without yielding. At high baud rate the transmit masks interrupts and doesn't yield. The net result is that the single threaded nature of the the software UART doesn't allow for simultaneous transmit and receive which is exactly what it is attempting to do when the TX and RX pins are jumpered as in my testing.  Perhaps this is well known to the Tasmota experts, but the software UART is only useful for use cases where the RX and TX will not happen simultaneously. This makes sense for a serial protocol where a master device transmits a command and then waits for a status response from a slave device before the master transmits the next command. It does not work for my use case (terminal server) where RX and TX can happen simultaneously.

Perhaps the code can be enhanced to detect simultaneous RX and TX on the software UART and log an error. I hope this information is useful.

John

[Philip Knowles]

In that case why not swap the energy device GPIO with your TCP?

 

Might also be worth contemplating using an ESP32

 

Regards

 

Phil K

 

 

Sent from Mail for Windows

 

From: John Carney
Sent: 21 April 2022 22:07
To: TasmotaUsers
Subject: Re: Help with TCP Serial Bridge

 

After studying the software UART code, it seems to me that what I am trying to do will not work unless I use a hardware UART interface. For the soft UART, the serial transmit is synchronous and the serial receive is asynchronous based on an interrupt triggered by a transition of the signal on the RX pin. At low baud rate, the transmitter starts bit banging and yields during each bit time. After the first bit, the receiver interrupt handling starts sampling the RX pin and waiting each bit time of the byte without yielding. At high baud rate the transmit masks interrupts and doesn't yield. The net result is that the single threaded nature of the the software UART doesn't allow for simultaneous transmit and receive which is exactly what it is attempting to do when the TX and RX pins are jumpered as in my testing.  Perhaps this is well known to the Tasmota experts, but the software UART is only useful for use cases where the RX and TX will not happen simultaneously. This makes sense for a serial protocol where a master device transmits a command and then waits for a status response from a slave device before the master transmits the next command. It does not work for my use case (terminal server) where RX and TX can happen simultaneously.

--

You received this message because you are subscribed to the Google Groups "TasmotaUsers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonoffusers...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/sonoffusers/fbc460ea-a94f-4875-be86-a00f427c86fbn%40googlegroups.com.