Go Down

Topic: OneWire in Due (Read 21 times) previous topic - next topic

kcore

I've been running the OneWire code that I posted in the ZIP file in a previous post for over 12 hours with no errors pulling data from three DS18B20's.

I have not been able to incorporate mantoui's updated read_bit function but I will do that later tonight when I'm home.

Code: [Select]
ROM = 28 A0 CE 49 3 0 0 55
  Chip = DS18B20
  Data = 1 A3 1 4B 46 7F FF D 10 CE  CRC=CE
  Temperature = 26.19 Celsius, 79.14 Fahrenheit
ROM = 28 F6 C3 49 3 0 0 25
  Chip = DS18B20
  Data = 1 A2 1 4B 46 7F FF E 10 D8  CRC=D8
  Temperature = 26.12 Celsius, 79.03 Fahrenheit
ROM = 28 6B C7 49 3 0 0 C1
  Chip = DS18B20
  Data = 1 A3 1 4B 46 7F FF D 10 CE  CRC=CE
  Temperature = 26.19 Celsius, 79.14 Fahrenheit
No more addresses.


I noticed in the Examples folder there is also a sketch for a DS2408 which is an 8 channel addressable switch.  I have a number of those lying around so I may be able to test the sketch later against one and let you know the results.

Paul Stoffregen

Does Due have a tone() function yet?  If so, please output an infinite duration 15 kHz tone on a pin during the test.

alvesjc


Does Due have a tone() function yet?  If so, please output an infinite duration 15 kHz tone on a pin during the test.



I believe the tone functions are still not ported.

mantoui



Does Due have a tone() function yet?  If so, please output an infinite duration 15 kHz tone on a pin during the test.



I believe the tone functions are still not ported.


I'm not sure what this has to do with onewire thread, but I have a proof-of-concept tone(), see tone1.ino in
    https://github.com/manitou48/DUEZoo

 

Paul Stoffregen

#29
Jan 17, 2013, 08:47 pm Last Edit: Jan 17, 2013, 11:15 pm by Paul Stoffregen Reason: 1
I've been working with OneWire today.  I included the #defines for Due.

It seems to work on a couple sensors, but most of my 10 test sensors them do not work.  They all respond with a presence pulse, but then return 0xFF for every byte including the checksum.

So I started troubleshooting. I believe I've tracked the problem to a possible bug in delayMicroseconds().  I'm using Arduino IDE 1.5.1.

Here is a very simple test program, which does a reset and then sends a single byte (skip is 0xCC).

Quote

#include <OneWire.h>

OneWire  ds(10);  // on pin 10

void setup() {
}

void loop() {
 ds.reset();
 ds.skip();
 delay(10);
}


Here is the actual waveform:



On the top trace you can see the entire sequence.  On the bottom is a zoomed in view of the first 4 bits after the reset.  The time scale is 30 us/div.  OneWire sends LSB first, so this is two 0s followed by two 1s.

The first 0 bit is incorrect.  OneWire called delayMicroseconds(65), but as you can see on the trace, the time was only 30 us.  The next zero bit is generated by the exact same code, where the delay actually is 65 us.  Well, it's actually closer to 67 us, but a 2 us error is ok.  But the first pulse being less than 60 us is not ok.  The datasheet says the chip will sample the voltage between 15 to 60 us after the falling edge, so a 30 us pulse works with some chips, but not others (most my 10 test samples apparently sample after 30 us).

Here is the same code, with the same sensor and same oscilloscope setup, running on a Teensy 3.0 board.



Both of the zero bits have a 65 us wide low pulse.

Go Up