Good question! Did you pull it to 5v or 3.3v?
Yes, 5v. Although on my board, for some reason, it’s only 4.5v (I’m powering it via USB).
Hmm, that should be ok. Can you try the code I posted and see if it works? You might need to modify it to Debug.Print() instead of outputting to the LCD.
Are you sure you connected it correctly? If you didn’t, it would probably heat up rapidly. Don’t ask me how I know that :
I think Greg5 has got things right but maybe we need to tweak timing a bit? This is why I wanted to measure it not just try it…we tried it already again to double check and it is running perfectly.
…just remembered, we tested it with latest firmware that is not out yet.Maybe this was fixed and I do not know. So, the new NETMF 4.1 will be out very soon. Please upgrade the firmware when ti is out (in couple days) and let me know if you still have problems.
Hi Greg,
I have the same Logic analyser and it helped me figure out a timing problem with an STM32 controller. I can’t see your picture of the timing. If there are pulses but they are just not the right width then there is a code problem of some sort. I’ve gone back to the Primer2 as it has everything I need for my project for now and I finally figured out a file write problem. GHI provides much more support that Raisonance. You get what you pay for!
Does the 1-wire code work flawlessly using only 1-wire code? Perhaps other functions are creating timing issues for some reason.
Timing is everything with 1-wire devices!
Greg, can you run the code that I posted? It would help figure out if the issue is hardware or not. That code is tested and working on my FEZ.
-First try our example or Chris’s to rule any software problems and keep on using it.
-Try a different I/O
-What version of software you use on the logic analyzer?
-Try the logic analyzer on the arduino and measure the signals, does it recognize them correctly?
-Try it while connecting a power supply (not only USB power).
Since we tried it already and it seem to work fine, we would need more details to help us nail the problem down.
I have tried GHI’s code and Chris’s without additional luck. As I said, I was able to get one sensor working, but not the other. For fun, I just plugged this in:
Cpu.Pin myPin = (Cpu.Pin)(FEZ_Pin.Digital.IO26);
OneWire ow = new OneWire(myPin);
ow.Reset();
ow.WriteBit(0x01);
ow.WriteBit(0x00);
ow.WriteBit(0x01);
ow.WriteBit(0x00);
ow.WriteBit(0x01);
ow.WriteBit(0x00);
ow.WriteBit(0x01);
ow.WriteBit(0x00);
The Reset pulse and Presense pulse are normal, however, when it goes to write the bits, my Logic Analyzer shows timings as (in microseconds):
1: 19.06
0: 88.06
1: 18.81
0: 88.88
1: 19.38
0: 87.94
1: 18.50
Those 1’s should be a maximum of 15 micro seconds. The zero’s are within range. Yes, when I use the analyzer on my Arduino, it works just fine and identifies everything correctly.
I have tried several different IO pins with no observable difference. Unfortunately I don’t have a power supply other than a 9V one, but I have a 6V adapter coming in the mail.
Other people on the web seem to have trouble with the .NET Micro Framework and 1-Wire:
This person concluded that the MF wasn’t quick enough to handle the protocol. And here is a post from the GHI forums from someone who experienced similar quirky issues with a DS18S20.
Thanks for the details. Looks like we need to tweak this a bit more…or maybe our latest firmware we used to test already fixes this. I will connect scope and compare the numbers to yours.
By the way, all old posts you see are not a factor since there are probably many firmware version before current firmware you are using.
I’ve spoken with Pavel about his blog and I can tell you that he was trying to use bit-toggling within NETMF CLR, which obviously was too large an overhead - and as we know subject to variability that you can’t control. The great news is that GHI implement this in managed code and handle the timing for us - which means you can safely ignore the blog post when using GHI devices.
I just measure it and it is 19us on Cobra! I will let the experts know and solve this quick!
Thanks for the great support! If you want me to try and beta test some new firmware, let me know. One Wire and these DS18B20’s are pretty much the critical part of my project.
The newly released 4.1 version of the GHI SDK seems to have fixed the problem! I just tried 5 different DS18B20’s and they all were able report the right temp (individually). I will get them all on the same network and see if that works as well.
Thanks to the GHI / FEZ crew for prompt support answers and a rapid bugfix turnaround!
We are always here to support your needs 
:o We had to delay the release because of this issue. lol
Greg5,
can you post your code to loop through the onewire sensors?
Thanks,
EriSan500
here’s some that will get you started. It just loops thru the devices and debug.print’s their address.
int OW_number , i;
int OW_address[8];
OneWire ow = new OneWire((Microsoft.SPOT.Hardware.Cpu.Pin)FEZ_Pin.Digital.Di1); //set your own pin
if (ow.Reset())
{
OW_number = 0;
while (ow.Search_GetNextDevice(OW_address)
{
OW_number++;
for (i=0;i<8;i++) debug.print(OW_address[i]+":");
}
Debug.Print("Found: " + OW_number + " devices");
}
If you store the addresses you can then loop thru them and issue match_rom commands and start conversions, etc.
Hi,
This has been a very useful thread. I have been able to get a DS18B20 device to work with the one wire interface with no problems. I have not had much luck getting a DS1920 to work. I have tried several different electrical configurations. I plan on using iButton type devices with the Cobra, so any information would be much appreciated!
I will keep working on it as well, and share anything I come up with.
Hi again everyone,
I got it working with a DS1920 iButton
To do so, tie the DQ line up to 5V with a 4.7k resistor, and the ground to ground. On the iButton connector I’m using, that simply meant tying the red wire up to the 5V in/out pin on the board with the 4.7k resistor and also connecting it to the IO9 pin. The green wire goes to the GND pin. The code works the same as with the DS18B20. It reads temperatures as well.
My primary need is to read the romids for identification purposes (don’t really need a thermochron, but it served for testing), and it is working for that as well.
Hi,
I’ve just received my Fez Panda II card, and some Dallas DS18b20 temperature sensors. I try the tutorial GHI Electronics – Where Hardware Meets Software. But I can not get it work. In fact it always return the same value 85…
For more detail on connection :
I add a 4k7 following shema of MilesBurton.com.
On the panda card I plug the resistor on the 5V pin, the ground to GND and and sensor pin 2 to pin D4 of the panda (resistor connect to sensor pin 2 as well).
The Code is :
using System;
using System.Threading;
using Microsoft.SPOT;
using Microsoft.SPOT.Hardware;
using GHIElectronics.NETMF.Hardware;
using GHIElectronics.NETMF.FEZ;
public class Program
{
public static void Main()
{
// Change this your correct pin!
Cpu.Pin myPin = (Cpu.Pin)FEZ_Pin.Digital.Di4;
OneWire ow = new OneWire(myPin);
ushort temperature;
// read every second
while (true)
{
if (ow.Reset())
{
ow.WriteByte(0xCC); // Skip ROM, we only have one device
ow.WriteByte(0x44); // Start temperature conversion
while (ow.ReadByte() == 0) ; // wait while busy
ow.Reset();
ow.WriteByte(0xCC); // skip ROM
ow.WriteByte(0xBE); // Read Scratchpad
temperature = ow.ReadByte(); // LSB
temperature |= (ushort)(ow.ReadByte() << 8); // MSB
Debug.Print("Temperature: " + temperature / 16);
Thread.Sleep(1000);
}
else
{
Debug.Print("Device is not detected.");
}
Thread.Sleep(1000);
}
}
}
Is any body can help ?
Thanks in advance Pascal.