RS485 TX-Enable

[lblabr]

I try to get your firmware working. i'd like to access my power meter with my smart home. i tried latest release, but i couldn't configure the tx-pin. i never could save the configuration until i used the workaround from here [https://github.com/jeelabs/esp-link/pull/138]

in the ui there are no options for selecting a pin ..... is that just a frontend issue ? may i congfigure the pins another way ?

thanks in advance

Lars

[uzi18]

It is unavailable because rs485 support was removed due to some boot issues. I can try to build firmware with rs485 for test if you want?

@tve do you have any link to root couse/report of boot issue with rs485? Or maybe it is same boot issue we encounter sometimes at first flash on some modules?

[tve]

The issue was related to switching to the microsecond resolution timer, but I don't remember the details.

[uzi18]

@tve will try to revert it without use of microsecond timer

[tve]

I believe it's needed to get the accuracy required by rs485

[lblabr]

it seems that there something with my brower cache or browser it self. from another computer and your latest release i could configure tx enable, but i'm not quite sure that it is working ... i could not get some response ... i just ordered an usb stick RS485/USB to monitor the bus traffic, i'm still interested to get some wireless access to the RS485/ModBus...

i disabled debug output to console and boot is fine with wemos mini.... but it would also be great to monitor the bus traffic ether in debug coonsole or debug with uart....

do you think its possible to have debug output and bus connected at the same time on different uart's ?

if you like, i will do some debugging, but i'm not a develeoper...

thanks in advance

[uzi18]

@lblabr what firmware version did you used?

[lblabr]

i started with your the latest release file here: https://github.com/jeelabs/esp-link/releases/tag/v3.2.47.alpha

[mj-sakellaropoulos]

I can confirm the that the boot issue appears only after selecting TX_ENABLE in the UI and rebooting.

According to ESP8266 documentation , the reset is triggered by the hardware watchdog timer.

Maybe microsecond timer settings have interfered in some way with the software WDT ?

If anyone has some insights on this it would be appreciated 🙏🏻

Here is my uart output

▒▒▒U9   1▒gpio0 state=1
TX_ENABLE gpio0 state=1
TX_ENABLE gpio0 state=1
TX_ENABLE gpio0 state=1
ets Jan  8 2013,rst cause:4, boot mode:(3,7)
wdt reset
load 0x40100000, len 2592, room 16
tail 0
chksum 0xf3
load 0x3ffe8000, len 764, room 8
tail 4
chksum 0x92
load 0x3ffe82fc, len 676, room 4
tail 0
chksum 0x22
csum 0x22
2nd boot version : 1.7(5d6f877)
SPI Speed : 40MHz
SPI Mode : QIO
SPI Flash Size & Map: 8Mbit(512KB+512KB)
jump to run user1 @ 1000
▒▒▒g▒s▒▒n|▒$▒l`b▒|{▒l▒n▒▒o▒l`▒▒s▒l▒l
l`▒▒;▒d▒d▒
d`▒▒s▒l
▒▒▒
dl s$▒▒sl▒▒▒c▒▒cp|
cx▒▒▒x▒▒▒c
▒▒'▒no▒
ld▒▒▒▒▒U9       1▒gpio0 state=1
TX_ENABLE gpio0 state=1
TX_ENABLE gpio0 state=1
TX_ENABLE gpio0 state=1
[loops after this]

[uzi18]

You should avoid gpio0 because it is used on boot, try another gpio please

[mj-sakellaropoulos]

OK, I have reworked my board and changed to GPIO2.

Changing PIN assignment in UI for TX_ENABLE causes lockup, and results in the same WDT Reset.

It was also necessary to do complete chip_erase since the parameter was stored in flash and usual flashing procedure does not erase this section.

Using esp-link version 3.2.47 alpha

  1471> station:  join, AID = 1
  1471> Wifi AP: station joined, AID = 1
  2270> HTTP GET /pins: 200, 16ms, h=15560
  9730> HTTP GET /menu: 200, 4ms, h=15656
  9739> HTTP GET /pins: 200, 6ms, h=15656
  9750> HTTP GET /wifi/info: 200, 8ms, h=14904
  9751> HTTP GET /system/info: 200, 6ms, h=15664
 15152> Wifi check: mode=AP status=255
 18001> Pins changed: reset=0 isp=-1 conn=-1 ser=-1 swap=0 rx-pup=1 tx_enable=-1
 18001> Serbridge pins: reset=0 isp=-1 tx_enable=-1 swap=0
 18013> SER led=-1
 18013> CONN led=-1
 18953> HTTP POST /pins: 204, 957ms, h=16000
 32000> Pins changed: reset=0 isp=-1 conn=-1 ser=-1 swap=0 rx-pup=1 tx_enable=2
 32001> Serbridge pins: reset=0 isp=-1 tx_enable=2 swap=0 # <==== Here I set TX_ENABLE to GPIO2

#[some time passes here until WDT is triggered]

 ets Jan  8 2013,rst cause:4, boot mode:(3,6)

wdt reset
load 0x40100000, len 2592, room 16 
tail 0
chksum 0xf3
load 0x3ffe8000, len 764, room 8 
tail 4
chksum 0x92
load 0x3ffe82fc, len 676, room 4 
tail 0
chksum 0x22
csum 0x22

2nd boot version : 1.7(5d6f877)
SPI Speed : 40MHz
SPI Mode : QIO
SPI Flash Size & Map: 8Mbit(512KB+512KB)
jump to run user1 @ 1000

[marcosribeirobr]

@mj-sakellaropoulos the solution to change gpio seems to have not solved, correct?

Is the solution to use the chip with autodirecion control like the MAX13487E or is it possible to think of some software solution?

[mj-sakellaropoulos]

@mj-sakellaropoulos the solution to change gpio seems to have not solved, correct?

Is the solution to use the chip with autodirecion control like the MAX13487E or is it possible to think of some software solution?

correct, GPIO did not change anything. Solution would be to write software from scratch for wifi-rs485 bridge and bypass esp-link (it is on my TODO list). Chip with autodirection control I assume would work, but I have not tried them.

[marcosribeirobr]

The chip with autodirection control I use in other applications. Thanks for the answer.

[uzi18]

gpio2 is also bad idea, sorry missed your message

[mj-sakellaropoulos]

Since I am using an ESP-01 module, I'm not sure there are any other viable pins?

[uzi18]

it is wrong by design, please use other module with more gpios

[alextrical]

I'm also looking to get the RS485 implemented, and from testing so far it looks like its the call to the function tx_enable in "uart.c" Line 63 is the cause of the boot loop mentioned in the comment above, not sure why but t does not like 'os_printf' in this os_printf("TX_ENABLE gpio%d state=%d\n", uart0_tx_enable_pin, state);

I can reproduce this issue, by commenting in and out Line 63/ os_printf("TX_ENABLE gpio%d state=%d\n", uart0_tx_enable_pin, state);

It also still presents the same issue with or without the use of microsecond timer throughout the application. Also I'm compiling with Platformio on the off chance that makes any difference

The only issue I'm having after commenting out the code is that the TX_ENABLE state will change at the beginning of the transmission, but never revert back

[alextrical]

I believe it's needed to get the accuracy required by rs485

I don't believe the microsecond timer is required for RS485, the device most of us are trying to use is the MAX485 . The issue is that the device is Half-Duplex and needs to be told when to Transmit or Receive.

All the IC is really doing is converting TTL 1s and 0s into a differential pair, either A high and B low, or A low and B high, it just needs to be told when to switch between sending and receiving

https://www.cuidevices.com/blog/rs-485-serial-interface-explained