pstolarz / onewireng Goto Github PK

Please add also this common feature.

Hello! Would you guys be up for adding support for an overdrive mode? I'm working with a chip that uses only this high speed version of 1-Wire, so I could work on the initial implementation

I am using an RP2040 with arduino pico sdk (not MBED).
The problem is that if I use oneWireNg (PIO version) I can’t instantiate more than 2 onewire connections. If I try to use more than 2 of them the RP2040 hangs even before entering setup().

in this way the RP2040 works

static OneWireNg_CurrentPlatform pippo(BEDROOM_PIN, false);
static OneWireNg_CurrentPlatform pluto(BATHROOM_PIN, false);
//static OneWireNg_CurrentPlatform topolino(LIVINGROOM_PIN, false);
//static OneWireNg_CurrentPlatform minnie(KITCHEN_PIN, false);

in this hangs

static OneWireNg_CurrentPlatform pippo(BEDROOM_PIN, false);
static OneWireNg_CurrentPlatform pluto(BATHROOM_PIN, false);
static OneWireNg_CurrentPlatform topolino(LIVINGROOM_PIN, false);
static OneWireNg_CurrentPlatform minnie(KITCHEN_PIN, false);

I also tried to use the bitbanging mode and in this mode I can instantiate 4 connections but then it hangs when I try to reset the 1-wire bus.
This last problem is also present in OneWire not ng and is caused by the use of noInterrupts() and interrupts() before and after delayUs().

The only way I can use the bitbanging version is to comment out noInterrupt() and interrupts() in Platform_Time_Critical.h

#elif defined(ARDUINO)
# define timeCriticalEnter() //noInterrupts()
# define timeCriticalExit() //interrupts()

Also in the old version of oneWire, if I want it to work, I have to comment out most of the noInterrupts() and interrupts().

like PaulStoffregen/OneWire#117
is it planed?

Tested code on ATtiny3217 and 804,
#include in DSTherm.h:16:10: fatal error.

Though compiles for old AVR and RISC.

Can the circuit for CONFIG_PWR_CTRL_ENABLED be modified to use a BJT instead of a MOSFET? If yes how would the circuit look like?

Hi @pstolarz - Having trouble getting this going on RP2040, Pico W board.

Board: Raspberry Pi Pico W
Board support package used: https://github.com/earlephilhower/arduino-pico/, latest
OneWireNg Version: 0.12.1

Example: DallasTemperature.ino within this library.

I'm unsure why CurrentPlatform.h is not picking up the class since ARDUINO_ARCH_RP2040 is a valid build flag:

# if CONFIG_RP2040_PIO_DRIVER && defined(ARDUINO_ARCH_RP2040)
#  include "platform/OneWireNg_PicoRP2040PIO.h"
# define OneWireNg_CurrentPlatform OneWireNg_PicoRP2040PIO

Errors from Arduino:

/Users//Documents/Arduino/libraries/OneWireNg/examples/arduino/DallasTemperature/DallasTemperature.ino:20:
/Users//Documents/Arduino/libraries/OneWireNg/src/OneWireNg_CurrentPlatform.h:59:3: warning: #warning "Can't detect platform. Use proper class for the platform you are compiling for!" [-Wcpp]
   59 | # warning "Can't detect platform. Use proper class for the platform you are compiling for!"
      |   ^~~~~~~
DallasTemperature:77:45: error: wrong number of template arguments (0, should be at least 1)
   77 | static Placeholder<OneWireNg_CurrentPlatform> _ow;
      |                                             ^
In file included from /Users//Documents/Arduino/libraries/OneWireNg/examples/arduino/DallasTemperature/DallasTemperature.ino:22:
/Users//Documents/Arduino/libraries/OneWireNg/src/utils/Placeholder.h:26:7: note: provided for 'template<class T, bool Init> class Placeholder'
   26 | class Placeholder
      |       ^~~~~~~~~~~
/Users//Documents/Arduino/libraries/OneWireNg/examples/arduino/DallasTemperature/DallasTemperature.ino: In function 'void setup()':
DallasTemperature:28:25: error: expected type-specifier before numeric constant
   28 | # define OW_PIN         13
      |                         ^~
/Users//Documents/Arduino/libraries/OneWireNg/examples/arduino/DallasTemperature/DallasTemperature.ino:136:42: note: in expansion of macro 'OW_PIN'
  136 |     new (&_ow) OneWireNg_CurrentPlatform(OW_PIN, false);
      |                                          ^~~~~~
DallasTemperature:136:42: error: expected ')' before numeric constant
  136 |     new (&_ow) OneWireNg_CurrentPlatform(OW_PIN, false);
      |                                         ~^
      |                                          )
DallasTemperature:138:17: error: invalid type argument of unary '*' (have 'int')
  138 |     DSTherm drv(*_ow);
      |                 ^~~~
/Users//Documents/Arduino/libraries/OneWireNg/examples/arduino/DallasTemperature/DallasTemperature.ino: In function 'void loop()':
DallasTemperature:164:17: error: invalid type argument of unary '*' (have 'int')
  164 |     DSTherm drv(*_ow);
      |                 ^~~~
DallasTemperature:189:26: error: invalid type argument of unary '*' (have 'int')
  189 |     for (const auto& id: *_ow) {
      |                          ^~~~
Using library OneWireNg at version 0.12.1 in folder: /Users//Documents/Arduino/libraries/OneWireNg 
exit status 1
wrong number of template arguments (0, should be at least 1)

Trying to test OneWire on raspberry pico W in Arduino IDE 2.0.3. Appears to be a problem others are having when downloading code the IDE hangs with an uploading message that doesn't go away. https://forum.arduino.cc/t/often-stuck-on-uploading-ide-2-0-3/1063796/4

For OneWireNg Arduino testing on Pico W what version of Arduino IDE are you using?

Larger goal is to add OneWire support in Firmata to abstract out the need to write code on the pico W device in the field and push it up to server code. The low cost wireless of Pico W opens up some interesting and scaleable remote sensor projects. Want to avoid pushing out new code every time a new sensor gets added.

Hi, I have been looking to use Onewire devices with the Raspberry Pi Pico. I have tried PaulStoffregen's library
(https://github.com/PaulStoffregen/OneWire), but I only get crashes when searching for devices.

I found your library, which seems to suggest it works with the Pico so I added the library to my PlatformIO project but I am not having much luck.

I next tried the default example in both PlatformIO and in Arduino 2.2.0 but neither library would find the device attached to the Pico.
To confirm my findings, I plugged in an Arduino Micro, using the original library, I was able to read the address of the device (therefore my pull-up is sufficient)

I can attach the project I used but it was quite literally a new Arduino IDE 2.2.0 install, automatic board manager for the board (Arduino MBED OS RP2040), only the OneWireNG library installed, and the DallasTemperature example used. Any ideas what I can try to debug this?

Thanks

Greg

When I compiled example for DS18B20 from OneWireNg in this spring (for Attiny3216), everything was fine. Now it ends up compiling with an error. Can you figure out why? Some bug in the library?

C:\Users\radek\AppData\Local\Temp\cccalydd.ltrans0.ltrans.o: In function UartClass::begin(unsigned long, unsigned int)': <artificial>:(.text+0x8ee): undefined reference to operator delete(void*, unsigned int)'
collect2.exe: error: ld returned 1 exit status
exit status 1
Nastala chyba při kompilaci u desky ATtiny3216/1616/1606/816/806/416/406 w/Optiboot.

Hi,

the "ESP32 RISCV-C platforms support" commit (e862d5f) unfortunately breaks the espressif32 platform builds:

In file included from .pio/libdeps/esp32dev/OneWireNg/src/OneWireNg_CurrentPlatform.h:36:0,
                 from .pio/libdeps/esp32dev/OneWireNg/src/OneWire.h:19,
                 from .pio/libdeps/esp32dev/DallasTemperature/DallasTemperature.h:25,
                 from src/sensors/onewire_temperature.h:6,
                 from src/sensors/onewire_temperature.cpp:1:
.pio/libdeps/esp32dev/OneWireNg/src/platform/OneWireNg_ArduinoESP32.h: In member function 'void OneWireNg_ArduinoESP32::initDtaGpio(unsigned int, bool)':
.pio/libdeps/esp32dev/OneWireNg/src/platform/OneWireNg_ArduinoESP32.h:21:33: error: request for member 'val' in 'GPIO.<anonymous struct>::in', which is of non-class type 'volatile uint32_t {aka volatile unsigned int}'
 # define REG_GPIO_IN_LO GPIO.in.val
                                 ^

I'm looking at the bitbang driver and how it is constructed. In order to work it needs to utilize critical sections with other interrupts shut off as well as precise us class timing. I propose to consider adding some sort of interrupt based alternative in the future. I've seen implementations of onewire based upon serial ports for example or you could use your own timer interrupt with a light state machine behind it.

I'm writing all these because in a complex project with many components, if each of them was shutting the ints off to achieve precise timing, the ints will fatally begin to lag and other things shall start to fail..

Hi, I have been studing your library but haven't tested it yet. It is very interesting.

I believe we could take this library to the next level by including the necesssary code to support the circuitry detailed in this app note Advanced 1-Wire Network Driver

Let me know what you think so as to coordinate the work.
Regards.

A heads up that OneWireNG works perfectly on the UM Feather S2.

For my project I have a pretty long run of DS18B20's The test run is 35 long but the final version that will be deployed is going to be about 100 sensors long. What is the easiest way to assign an ID to each DS18B20 so I get sensor 1 at the top and 100 at the end and dont have to worry about arranging them when im soldering them inline?

Hey there,

When I attempt to compile the DallasTemperature.ino example for an ESP8266 using platform = [email protected] (the latest version of the 2.x ESP8266 platform available on Platformio), I get the following error:

In file included from .pio/libdeps/esp12e/OneWireNg/src/OneWireNg.h:19:0,
                 from .pio/libdeps/esp12e/OneWireNg/src/OneWireNg_BitBang.h:16,
                 from .pio/libdeps/esp12e/OneWireNg/src/OneWireNg_BitBang.cpp:15:
.pio/libdeps/esp12e/OneWireNg/src/platform/Platform_New.h: In function 'void* operator new(size_t, void*)':
.pio/libdeps/esp12e/OneWireNg/src/platform/Platform_New.h:52:14: error: redefinition of 'void* operator new(size_t, void*)'
 inline void *operator new(size_t sz, void *ptr) NOEXCEPT {
              ^
In file included from /Users/jbeeler/.platformio/packages/[email protected]/xtensa-lx106-elf/include/c++/4.8.2/bits/stl_construct.h:59:0,
                 from /Users/jbeeler/.platformio/packages/[email protected]/xtensa-lx106-elf/include/c++/4.8.2/bits/stl_tempbuf.h:60,
                 from /Users/jbeeler/.platformio/packages/[email protected]/xtensa-lx106-elf/include/c++/4.8.2/bits/stl_algo.h:62,
                 from /Users/jbeeler/.platformio/packages/[email protected]/xtensa-lx106-elf/include/c++/4.8.2/algorithm:62,
                 from /Users/jbeeler/.platformio/packages/[email protected]/cores/esp8266/Arduino.h:238,
                 from .pio/libdeps/esp12e/OneWireNg/src/platform/Platform_Delay.h:17,
                 from .pio/libdeps/esp12e/OneWireNg/src/OneWireNg_BitBang.cpp:13:
/Users/jbeeler/.platformio/packages/[email protected]/xtensa-lx106-elf/include/c++/4.8.2/new:109:14: error: 'void* operator new(std::size_t, void*)' previously defined here
 inline void* operator new(std::size_t, void* __p) _GLIBCXX_USE_NOEXCEPT
              ^

Digging into it, it appears that the __has_include check in Platform_New.h is failing.

Best that I can tell __has_include is #define'd as 0 in this version of the xtensa toolchain, meaning that simply testing if it is defined is not proof-positive that it actually available.

I've produced a MCVE here: https://github.com/thorrak/onewireng_platform_new_issue -- [env:esp8266_2.6.3] is broken, while [env:esp8266_current] works.

I have 2 boards, connected with 3 wires (power, ground, data). I'm trying to pass messages back and forth.

Would this library allow me to do that? If so, how would I configure the controller that acts as the "OneWire device"?

Recently did a try to transfer analog signal's readout through harsh electromagnetic environment, via UART, by one phisical wire, from master microcontroller Tx to slave micro's Rx. The communication works normal, but time to time the transfer falls. It would be perfect to have a chanse on 1-Wire protocol using for some measurement guarantied delivery from one MC to another MC.

Is it possible to read only one specific sensor?
Example:
I know that the sensor for BadRoom has the ID 28:FF:2C:A4:B3:16:3:CA and for LivingRoom 28:FF:D5:98:B3:16:3:C5.
Is it possible to do something like
BadRoom = getTemp(28:FF:2C:A4:B3:16:3:CA)
LivingRoom = getTemp(28:FF:D5:98:B3:16:3:C5)

Thanks!

Just FYI: OneWireNg was tested with Due and works fine.
Thank you!

This goes solidly into the wishlist territory: you currently have a DallasTemperature implementation using the new OneWireNg interface as an example. It would be great to have it as a proper class or a library of its own instead of having to go through the wrapper.

I'd rather use your implementation directly because your example implementation already supports more devices (DS28EA00, in particular) and your code in general already has better documentation and comments (and appears to be supported, whereas the PaulStoffregen one has a number of important open PRs dating back already several years).

This is of course something I could easily do myself but I only have DS18B20s at my disposal, so testing during the development would be problematic. :-)

Is it possible to lightweight compile this library ? I'm 100bytes short in my project :)

prośba o wsparcie dla esp32-s3 w bibliotece onewireng. Dzięki

Hi,

So after installing 0.10.2 over 0.10.1 I started having totally inconsistent reading.
I have 3 DS18B20 and so far all was OK.
The moment I upgrade the program has issues with finding sensors, or, invalid reading
Actually I am not able to say which one is when.
As per your example, I get either:
Invalid CRC!
or simply the sensor is omitted

Reverting to 0.10.1 solves the problem.
I did not change anything in my code, so maybe 0.10.2 has some breaking changes?

I tried connecting a DS18B20 sensor to an Arduino Opta using this library. The problem is that the OneWire protocol is half duplex, while the Arduino Opta only has digital inputs, not outputs (the only outputs it has are the four relays).
Arduino Opta datasheet

Hi,
can you please add crc16 function. I'm trying create onewire arduino nano to nano communication by OneWireHub and this libary. On slave side I was select bae0910 protocol and this need crc16. With Onewire libary I have some problem with more data communication on nano cpu, but your onewireng work perfect in first tests.
In Onewire libary is crc16 working.
Thanks
Regards

On ESP32, micros() takes about 150 cycles.

I'm using 80MHz CPU clock to avoid wasting power,

delayMicroseconds() calls micros() at least twice. This means delayMicroseconds() takes at least 330 cycles, corresponding to a delay of more than 4µs... even if the requested delay was 1µs or 2µs or 3µs. For longer delays, the actual delay will be a bit longer than what was requested. At 80MHz, delayMicroseconds() is about 2µs longer than requested.

In other words, delayMicroseconds() does not work, which is a problem for bit-banging a timing-critical protocol such as onewire... and I found this out because it was causing an impressive number of read errors on a rather long string of DS18B20 (about one error in 100 reads). I'm not using OneWireNg, I'm using Paul Stoffregen's OneWire library, modified to use an active pullup to drive my cables. So this may or may not apply to OneWireNg, but since your library also uses delayMicroseconds(), I thought you might want to know about this.

I switched to a more accurate delayMicroseconds() implementation based on a timer, and the number of read errors dropped to zero.

I'm having an issue where after a random amount of time the DS18B20 will stop sending valid data. I don't have any good debug showing what data is being sent or if any when the issue starts, but I do have my script go into a failure loop when it see's a 0 for temp on the sensor.

It usually requires a complete power cycle of the ESP32 to get it to read again. Is there a way to force the sensor to reset ?

What would the onewire code look like if I have a DS18B20 thermometer connected to multiple pins?

When I build this, I get a warning that it's not guaranteed on the Arduino Giga R1 board, but I've just built and tested it on both 9 and 12 bit resolution, and it works very well.

Many thanks - that's twice this library has been a lifesaver.

Working with https://github.com/SignalK/SensESP, which used the https://github.com/PaulStoffregen/OneWire library for a couple of years without issue. Recently switched to pstolarz/OneWireNg and pstolarz/Arduino-Temperature-Control-Library, and now several users are getting continuous crashes when using it with ESP8266, but not with ESP32. I've traced it down to somewhere inside the begin(pin) method.

The first line of the error from PlatformIO (VS Code) says Exception Cause: 9 [LoadStoreAlignmentCause: Load or store to an unaligned address]. I noticed that the following line in the begin(pin) method is trying to store the new OneWireNg_CurrentPlatform in a specific spot in memory:
_ow = new (_ow_buf) OneWireNg_CurrentPlatform

I removed the (_ow_buf) from that line, and the crash stopped. Unfortunately, I'm away from the rest of my equipment that consumes the data from this program, so I can't test it all the way through. But could this be the cause of the crash?

Hi!

I have one hardware that is working, and I build the Dallas example to know how this new lib work.

But, on the load static OneWireNg *ow = new OneWireNg_CurrentPlatform(OW_PIN, false); I get reset.. on the ESP8266. Cause 1: normal boot after power-on

load 0x4010f000, len 1384, room 16
tail 8
chksum 0x2d
csum 0x2d
vb3acf27f
~ld

But, if I change it to true:
static OneWireNg *ow = new OneWireNg_ArduinoESP8266(OW_PIN, true);

The issue of the reset don`t return. I Have pull UP 3K3.
This library is very robust.. I loved it! Congradulations!
Best Regards

does this DallasTemperature fork 's ExternalPullup example does the exact thing as the parasite powering section here?

do i need to use the DallasTemperature ExternalPullup example, or the one at the parasite powering section?
or even both of them?
I need to control the ExternalPullup mosfet but i dont know which way to use it properly..

regards,

I began to wonder: instead of having OneWireNg_Wrapper in a DallasTemperature fork, should it rather be provided by OneWire.h in the OneWireNg repo? If I understand correctly, in that case the changes to DallasTemperature would be limited just to the dependency declarations in library.json and library.properties?

It might even be possible to eventually convince the PlatformIO crowd to implement a "provides" or "replaces" field in library.json, similar to the Debian packaging Provides and Replaces keywords. In that case, no forking of any downstream repos would be required.