orgua / OneWireHub

OneWire slave device emulator
GNU General Public License v3.0
343 stars 86 forks source link

ESP8266 compatiility #22

Closed medamarko closed 6 years ago

medamarko commented 7 years ago

Did anybody tried to run this lib on esp8266? I can compile but i t cannot run, Im always getting this error (tried several examples with pio 5 as onewire pin): ` ets Jan 8 2013,rst cause:4, boot mode:(3,6)

wdt reset load 0x4010f000, len 1384, room 16 tail 8 chksum 0x2d csum 0x2d v00000000 ~ld `

dvv commented 7 years ago

Try inserting tmr.wdclr() in places looking as blocking ones.

orgua commented 7 years ago

did you have any luck with this tip? maybe we should include this watchdog reset to the main-routines?

chasm-git commented 7 years ago

On the ESP8266 both the OW and debug default pins are already used for SPI flash communication, and debug is on by default.

Here is what I did to make the DS18B20 example run on a nodemcu board. In the sketch itself: constexpr uint8_t pin_led { 16 }; // build in LED constexpr uint8_t pin_onewire { 4 }; // pin D2

In OneWireHub_config.h GPIO_DEBUG_PIN to 5 which is pin D1. Alternatively turn GPIO debugging off. Also in platform.h VALUE_IPL to something else than 0 to get rid of the division by zero compile error.

With these changes the code runs without watchdog problems, acting normally on the serial console. However I can't see the emulated senors on the bus. Quite possibly a VALUE_IPL problem, me guessing wrong.

Running the calibrate_by_bus_timing code is not really an option. The ESP8266 is infamous for being picky about long loops and the watchdog get triggered consistently.

chasm-git commented 7 years ago

After some fun and games with ESP.wdtFeed(); the calibrate_by_bus_timing program runs. VALUE_IPL calculates to 21-23. (80Mhz) Going with 22 seems to work. I can see simulated DS18B20 using both ESP8266 and Arduino nano bus masters.

This is not 100% stable yet. Occasionally there is a glitch and only the single hardware DS18B20 on the same bus gets discovered and read. No access to an oscilloscope or logic analyzer at this time to check the 1ms timing via GPIO_DEBUG, sorry.

orgua commented 7 years ago

could you push your changes as a pull request? or attach your changed files here? i have ordered some esp-boards and would like to try it myself. i guess you are using the nodeMCU-boards with the lua-firmware. there is a scheduler included that seems to be the source of the glitches.

chasm-git commented 7 years ago

Sure, there should be a pull request.

That was an nodeMCU dev board, but generating firmware with the Arduino software instead of lua. The usual difference between the dev boards is the amount of exposed IO, an outlier is the WeMos D1 mini pro which does not use a module and includes much more flash. The esp modules are divided by the amount of exposed IO, flash size and FCC rating. You can run most software (original AT commands, LUA, Arduino, developed with the SDK, ...) on all esp modules, availible IO and flash size being the obvious limitations.

I like the nodeMCU 1.0 boards because they are small, have all the supporting infrastructure and expose all pins of the ESP module. The integrated UART makes development simple and the price is also right.

orgua commented 6 years ago

tested hub with a wemos d1 r2, nodeMCU 1.0 ESP-12E and even a esp32 they all work!