This leaves me more confident. I Had to tweak the timings in read and write timeslots, and I was affraid that i might be just tweaking the lib for my own probes or probe cable length, etc.
That proves the opposite.
Regarding the original example, I have the same problem, I only get FFFFF. I don't have any clue about that, but I suspect that might be something about the probe discovery process. In my test, I just skip that, because I'm addressing only one prob.
I've left that aside to first conclude if the actual code work with every prob.
We are now 3 with working due with onewire.
Unfortunately, I can't continue to test why it doesn't work with example, has i told before, I've accidentally burned my due...
My suggestion now, is to transport the discovery process to the function that works and test it( and removing ds.skip() ).
If more people joins this effort, maybe we can get to a final library faster.
My test function was first built a very long time ago based on that example, it should work...
I tested your lib and sketch on linux with IDE 1.5.1 (didn't compile with 1.5). I edited OneWire.h as suggested. Sketch worked. Also tested with no delay(1); -- still worked.
I tested the Examples>OneWire>DS18x20_Temperature. It would work if I replaced ds.select(addr); with ds.skip(); With delay(1);'s it worked each query. With no delay(1); every other query would return Data with FFs
ROM = 28 86 42 5B 3 0 0 84
Chip = DS18B20
Data = 1 82 1 4B 46 7F FF E 10 70 CRC=70
Temperature = 24.12 Celsius, 75.43 Fahrenheit
No more addresses.
In a later experiment, I got the Example to work by adding delay(1);'s in the ds.select() function in OneWire.cpp
Ok, so if I understand right the delays are needed for your usage also, right?
The only way to get stable readings for long run was with that delays. My function worked without them, but it returns FFF from time to time!
With the delays, I had it running for more then 48hours without a failure.
mantoui:
I tested the Examples>OneWire>DS18x20_Temperature. It would work if I replaced ds.select(addr); with ds.skip(); With delay(1);'s it worked each query. With no delay(1); every other query would return Data with FFs
your sketch, seemed to work consistently with or without delay(1);
the Examples was bad every other query without the delay(1) using ds.skip()
I got Examples to work by adding delay(1) between every write in the select() function in OneWire.cpp,
and no delay(1) in the Examples sketch
I had also tried delayMicroseconds in select() with no luck, so I switched to delay(1); but presumably something
shorter than a millisecond might work ... sort of hit and miss.
I rewrote write_bit() in OneWire.cpp to match (more or less) what was working on the maple. This seems to work for me without any delay(1);! Works on both the little ds18b20 sketch and the Examples>OneWire>DS18x20_temperature.
void OneWire::write_bit(uint8_t v)
{
IO_REG_TYPE mask=bitmask;
volatile IO_REG_TYPE *reg IO_REG_ASM = baseReg;
if (v & 1) {
// noInterrupts();
DIRECT_MODE_OUTPUT(reg, mask); // drive output low
DIRECT_WRITE_LOW(reg, mask);
delayMicroseconds(5);
// DIRECT_WRITE_HIGH(reg, mask); // drive output high
DIRECT_MODE_INPUT(reg, mask); // let pin float, pull up will raise
delayMicroseconds(60);
//interrupts();
} else {
//noInterrupts();
DIRECT_MODE_OUTPUT(reg, mask); // drive output low
DIRECT_WRITE_LOW(reg, mask);
delayMicroseconds(60);
DIRECT_MODE_INPUT(reg, mask); // let pin float, pull up will raise
//DIRECT_WRITE_HIGH(reg, mask); // drive output high
//interrupts();
}
delayMicroseconds(10); // 10uSec recovery time
}
I combined mantoui's updated OneWire::write_bit function along with the changes made by alvesjc and I'm now able to run the DS18x20_Temperature right out of the box.
This effort should go a long way in getting other people moved over to the Due because so many projects have requirements to read temperatures and interact with other one wire devices.
Thanks for all your help in getting this working.
I've put all the stuff in a zip file for others to test without having to edit the files.
I'm current the de-facto maintainer of OneWire, but only because it was essentially abandoned when I picked it up and fixed the many bugs. If anyone else really wants the position, it's open....
Long-term, is the ODSR (presumably will work starting with 1.5.2) or CODR and SODR approach the best way?
mantoui:
I rewrote write_bit() in OneWire.cpp to match (more or less) what was working on the maple. This seems to work for me without any delay(1);! Works on both the little ds18b20 sketch and the Examples>OneWire>DS18x20_temperature.
I combined mantoui's updated OneWire::write_bit function along with the changes made by alvesjc and I'm now able to run the DS18x20_Temperature right out of the box.
This effort should go a long way in getting other people moved over to the Due because so many projects have requirements to read temperatures and interact with other one wire devices.
Thanks for all your help in getting this working.
I've put all the stuff in a zip file for others to test without having to edit the files.
So many people already complained about onewire, so I thought you're just gone of the Arduino world and took the initiative to try to make this work for everyone in this great new platform.
I has needing this lib for my project, so I started to dig on this.
You're most welcome to include the changes in your git!
Though read_bit() seemed to be working, I modified it as well to match the maple version. The two sketches seemed to work with the slimmer version. NO delay(1)'s required.
uint8_t OneWire::read_bit(void)
{
IO_REG_TYPE mask=bitmask;
volatile IO_REG_TYPE *reg IO_REG_ASM = baseReg;
uint8_t r;
DIRECT_MODE_OUTPUT(reg, mask);
DIRECT_WRITE_LOW(reg, mask);
delayMicroseconds(5);
DIRECT_MODE_INPUT(reg, mask); // let pin float, pull up will raise
delayMicroseconds(5);
r = DIRECT_READ(reg, mask);
delayMicroseconds(60);
return r;
}
alvesjc:
I' had it running with other timers, but would have failures from time to time, some of them were very spaced in time.
I can believe that. Several of the code fragments above have the interrupt disable removed. If an interrupt occurs during a bit read or write, it will lengthen the timing. On ARM, the problem is probably less, because the process is so much faster, especially with interrupt overhead (the context is saved by hardware, utilizing a separate bus, rather than by code in the interrupt routine). This was one of the 2 major bugs before I made version 2.0.