ESP32 Forum

Hello.

I'm working with David Antliff to implement hardware support in esp32-owb, 1-Wire component for esp32/esp-idf. I have a preliminary driver, originally based on the nodemcu rmt driver but heavily modified at https://github.com/chmorgan/esp32-owb/c ... c2ec93b025

What I'm seeing is that the RMT output is showing up correctly and the timing is spot on perfect, it was amazing seeing how close the timing was to the target. My device, a DS18B20, is responding and pulling the line low. I'm doing the 1-wire reset via the driver's _reset() call. The bus trace looks like:

-----___ 480us__---_60us_-----

In the trace the RMT is outputting the high bus value the 480us low pulse and then releasing the bus. The 60us low section is the DS18B20 responding by pulling the bus low.

The RMT reports a single sample, something like this (I can get the exact output if it would be helpful):

level 0 480
level 1 0

This appears to indicate that the RMT isn't seeing the low state of the bus.

Anyone mind offering some suggestions for how to debug or provide additional information that could help?

Why heavily modified? Why did you take out the open drain, active drive stuff?

WiFive wrote:Why heavily modified? Why did you take out the open drain, active drive stuff?

The idea was to support the gpio and rmt implementation in parallel until the rmt implementation was known to be working well. esp32-owb also seemed to have a cleaner search implementation. I also wanted to encapsulate the implementation into a structure so you could have multiple implementations running at the same time.

Does the active drive in the nodemcu implementation work safely in all configurations? The gpio pins on the esp32 are limited to 12mA max and without a current limiting inline resistor it seemed possible to over current the pin if the pin was actively driving and you had say a dozen devices on the bus that were trying to recharge.

Would you have some idea what might be wrong with the code I posted that could cause the rmt not to receive the data properly?

Active drive is probably only a problem with multiple parasite power devices doing simultaneous conversions.

But you should enable open drain mode in init either way.

WiFive wrote:Active drive is probably only a problem with multiple parasite power devices doing simultaneous conversions.

But you should enable open drain mode in init either way.

I'll probably add some notes to esp32-owb about the issue. I'd feel like I was doing the user a disservice if I was enabling the pin to drive because of the risk of burning out the output driver. In addition the manufacturer's recommended circuit design is to use a second gpio with an external mosfet that is a hard pullup to Vcc in the case of a shared signal/power line. Using the esp32 io drivers to provide power seems like a really bad idea and something I'd like to encourage users of the esp32 not to do, given the pretty low drive current on the esp32. I should probably add a note about an inline current limiting resistor as a good idea. I'm sure plenty of people don't understand the limitations of the esp32 and I'd like to help people avoid burning their io drivers out. Plus if they did burn an io driver out I'm not sure how they would even tell. They could spend hours trying to figure out why things stopped working if the failure is isolated to that single io driver.


On the open drain mode configuration, should that be enabled before attaching the gpio pins via rmt_set_pin()? Would you recommend using gpio_set_direction() or more targeted via GPIO.pin[gpio_num].pad_driver = 1; ?

Could that be what is causing the issues with the rmt not seeing changes in the bus level?

Rmt_set_pin for TX will enable the output driver by default, so you could immediately disable it or rewrite the tx pin setup

Thanks for the pointer here. I ended up enabling open drain on the pin and everything is working correctly now. I'm not sure if you've used the nodemcu driver but you might take a look at the esp32-owb version now that it is working.