Netduino home hardware projects downloads community

Jump to content


The Netduino forums have been replaced by new forums at community.wildernesslabs.co. This site has been preserved for archival purposes only and the ability to make new accounts or posts has been turned off.
Photo

OneWire ALPHA


  • Please log in to reply
167 replies to this topic

#61 Stuart Crawshaw

Stuart Crawshaw

    Advanced Member

  • Members
  • PipPipPip
  • 60 posts
  • LocationLeeds, United Kingdom

Posted 07 July 2011 - 11:04 AM

Appologies for pretty much hijaking this thread, but i have one more question. Regarding the OneWire library here, If i have 5 sensors connected to the netduino, is there any way i could read a particular sensor, say sensor 4. and then take a reading from sensor 2. the example code shows that the SkipRom command is sent followed by a ConvertT command then read scratchpad, but this does not show how to target a specific ROM. Hope this makes sense.
Intelligent People Aren't Afraid To Ask For Help.

#62 Stuart Crawshaw

Stuart Crawshaw

    Advanced Member

  • Members
  • PipPipPip
  • 60 posts
  • LocationLeeds, United Kingdom

Posted 07 July 2011 - 07:23 PM

Never mind,

I figured it out.


// Instruct a single DS18*20 to do a temperature conversion and read result.
public static void GetSingleTemperature(byte[] romAddess)
{
  var oneWire = new OneWire(Pins.GPIO_PIN_D0); // Adjust the pin if necessary
  if(oneWire.Reset())
  {
    // DS18B20 Thermometer
    oneWire.WriteByte(OneWire.MatchRom); // Address single device
    oneWire.Write(romAddress);           // 64bit ROM code stored in byte[] romAddress
    oneWire.WriteByte(DS18B20.ConvertT);
    Thread.Sleep(750);                   // Wait Tconv (for default 12-bit resolution)

    oneWire.Reset();
    oneWire.WriteByte(OneWire.MatchRom); // Address single device
    oneWire.Write(romAddress);           // 64bit ROM code stored in byte[] romAddress
    oneWire.WriteByte(DS18B20.ReadScratchpad);

    // Read just the temperature (2 bytes)
    var tempLo = oneWire.ReadByte();
    var tempHi = oneWire.ReadByte();
    var temp = DS18B20.GetTemperature(tempLo, tempHi); // ((short)((tempHi << 8) | tempLo))/16F
    Debug.Print(temp.ToString());
  }
}

// Get temperature reading from all devices on the bus.
public statis void EnumerateAllDeviceTemps()
{
  var rom = new byte[8]; // 64-bit
  var deviation = 0;  // Search result
  do
  {
    if((deviation = oneWire.Search(rom, deviation)) == -1)
      break;
    if(OneWire.ComputeCRC(rom, count:7) == rom[7])
    {
      // Found a valid device ID
      GetSingleTemperature(rom);
    }
  }
  while(deviation > 0);
}

Intelligent People Aren't Afraid To Ask For Help.

#63 mishoboss

mishoboss

    New Member

  • Members
  • Pip
  • 5 posts

Posted 11 July 2011 - 03:45 PM

Any chance supporting DHT11/DHT22 humidity and temperature sensors? They're not one-wire, but the communication is similar and needs to be done native, not in managed C# code. I see Steve88W wrote earlier in this topic that there is a "huge step closer to supporting the DHT11 and DHT22". Any progress on that?

#64 skytribe

skytribe

    Member

  • Members
  • PipPip
  • 11 posts

Posted 12 July 2011 - 12:13 AM

Any chance supporting DHT11/DHT22 humidity and temperature sensors? They're not one-wire, but the communication is similar and needs to be done native, not in managed C# code. I see Steve88W wrote earlier in this topic that there is a "huge step closer to supporting the DHT11 and DHT22". Any progress on that?


Add one for DHT11 sensors support.

#65 Valkyrie-MT

Valkyrie-MT

    Advanced Member

  • Members
  • PipPipPip
  • 315 posts
  • LocationIndiana, USA

Posted 22 July 2011 - 02:19 PM

Hi phantom, grimbouk:

When the .NET MF 4.2 firmware is finished in the next month or so, we'll be happy to build a custom version with CW2's latest OneWire feature...for Netduino, Netduino Plus, and Netduino Mini.

Chris


Chris, I've been running the 1-Wire stuff now for a month, reading 7+ sensors on 2 different Netduinos and it is solid. It is easily one of the most reliable parts of my system. I would encourage you to include the current+tested version in the next release and save CW2's enhanced version for the next Alpha/Beta build...

Thanks,
Valkyrie-MT

#66 Scott Green

Scott Green

    Advanced Member

  • Members
  • PipPipPip
  • 34 posts

Posted 11 August 2011 - 03:35 AM

Sorry for the newb question, but can you tell me where I unzip the files for the example program prior to build and deploy? Firmware installed, just need to know where to put the unziped contents, and the DLL when built. Thanks, Scott...

#67 CW2

CW2

    Advanced Member

  • Members
  • PipPipPip
  • 1592 posts
  • LocationCzech Republic

Posted 11 August 2011 - 06:51 AM

...but can you tell me where I unzip the files for the example program prior to build and deploy?

Hello Scott, you can unzip the files anywhere you want. The sample application (OneWireTestApp.csproj) has set all needed dependencies (projects, dlls), which are build automatically and deployed to your Netduino. If you want to use OneWire class in your own project, add a reference to CW.NETMF.OneWire.dll (i.e. from "...\Netduino_v4.1.1_beta1_CW.NETMF.OneWire-1.0.5.0\Solutions\Netduino\Interop\CW_NETMF_OneWire\ManagedCode\bin\Release\le\" directory).

Hope this helps.

#68 momo

momo

    New Member

  • Members
  • Pip
  • 1 posts

Posted 13 August 2011 - 10:22 AM

Hi, I am new to Netduino Plus. Actually I am using the .Net Micro Framework 4.2 RC, Netduino SDK 64bits V4.2 Beta and the Netduido Plus firmware V4.2 RC. Is there some OneWire function in it? Where can i find more information on Netduino Plus hardware support? By the way, many thanks for the job done.

#69 Scott Green

Scott Green

    Advanced Member

  • Members
  • PipPipPip
  • 34 posts

Posted 13 August 2011 - 05:49 PM

I'm trying to use the serial port to control a SparkFun serial LCD, and use the OneWire support of this firmware at the same time. I started out using both the DLL included with this release as well as the SerLCD class elsewhere in the forums. When I build either one by themselves, I can either write to the LCD or read 1wire temp sensors, but not both at the same time. I always get an InvalidOperation exception on the serial port open. So, to simplify the equation, I've added the following code to the OneWireTestApp. This just opens the serial port, writes a few lines to it, then starts waiting for button presses to read the temp sensor. I'm getting the same exception on the line lcd.Open(); Anyone else having this problem? public static byte[] getBytes(String message) { System.Text.UTF8Encoding encoding = new System.Text.UTF8Encoding(); return encoding.GetBytes(message); } public static void Main() { sw1 = new InterruptPort(Pins.ONBOARD_SW1, true, ResistorModes.Disabled, InterruptModes.InterruptEdgeLow); sw1.OnInterrupt += new NativeEventHandler(sw1_OnInterrupt); // TODO: Change pin according to the actual wiring oneWire = new OneWire(Pins.GPIO_PIN_D0); SerialPort lcd; lcd = new SerialPort(SerialPorts.COM1, 9600, Parity.None, 8, StopBits.One); lcd.ReadTimeout = 10; lcd.Open(); byte[] byteme = getBytes("Welcome to Netduino"); lcd.Write(byteme, 0, byteme.Length); byte[] bytes = new byte[1] { 12 }; lcd.Write(bytes, 0, bytes.Length); Thread.Sleep(Timeout.Infinite); }

#70 CW2

CW2

    Advanced Member

  • Members
  • PipPipPip
  • 1592 posts
  • LocationCzech Republic

Posted 13 August 2011 - 06:34 PM

I'm trying to use the serial port to control a SparkFun serial LCD, and use the OneWire support of this firmware at the same time.

IMHO the problem is that your oneWire object uses pin D0 that also has alternative function of being RxD of COM1 and it tries to reserve it during its initialization, which results in exception. To resolve the issue, you can use different pin for OneWire, e.g. D2, or switch to COM2 (D2, D3) for serial communication.

#71 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 13 August 2011 - 06:35 PM

Hi momo,

...I am using the .Net Micro Framework 4.2 RC...Is there some OneWire function in it? Where can i find more information on Netduino Plus hardware support?


There is no one-wire support built into the Netduino 4.2 RC1 firmware, but we build make a version with OneWire support shortly after the .NET MF 4.2 is completed (out of beta).

Welcome to the Netduino community,

Chris

#72 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 13 August 2011 - 06:37 PM

Hi Scott, COM1 uses pins D0/D1 and your OneWire device is also using pin D0. That won't work, as they overlap :) Can you put your OneWire device on another pin (or use COM2 -- which is pins D2/D3)? Chris

Edited by Chris Walker, 13 August 2011 - 06:37 PM.
CW2 beat me to it! Thanks, CW2. He's correct as usual :)


#73 Scott Green

Scott Green

    Advanced Member

  • Members
  • PipPipPip
  • 34 posts

Posted 13 August 2011 - 07:38 PM

IMHO the problem is that your oneWire object uses pin D0 that also has alternative function of being RxD of COM1 and it tries to reserve it during its initialization, which results in exception. To resolve the issue, you can use different pin for OneWire, e.g. D2, or switch to COM2 (D2, D3) for serial communication.


CW2, That did it! Thanks!

Scott...

#74 Scott Green

Scott Green

    Advanced Member

  • Members
  • PipPipPip
  • 34 posts

Posted 14 August 2011 - 06:04 AM

FANTASTIC! The One-Wire code in the firmware appears solid to me. I haven't seen any issues with it. Although, I really wanted to see a much simpler and object oriented way of working with 1 wire, so I wrote a wrapper class (called OneWireNetwork) out of CW2's sample. I only tested it with my DS18B20 sensors, but I have more coming soon and hopefully will add classes for them. So, what I did was create a collection class of devices that has a "Discover" method to scan the One-Wire network for devices. I hope this can be the start of a One-Wire framework that will make this the easiest One-Wire platform available. I have attached the code to this post. It is a complete replacement for CW2's OneWireTestApp project from the first post. Also, this example works with 1, 2, 3, or more devices, using parasite power or not.

By using the library, the code gets very simple:

public static void Main()
    {
      // TODO: Change pin according to the actual wiring
      var deviceNetwork = new OneWireNetwork(Pins.GPIO_PIN_D0);
          
      // Interrogate the devices on the network (adding them to the collection)
      deviceNetwork.Discover();

      while (true)
      {
          // Loop through all the discovered devices
          foreach (var aDevice in deviceNetwork)
          {
              Debug.Print("Address: " + aDevice.Address);
              
              if (aDevice is DS18B20) 
                  Debug.Print("Temp: " + (aDevice as DS18B20).Temperature);
          }

          Thread.Sleep(20000);
      }
    }

Output:
1-Wire device present
Multiple devices present
72000002DC320128
B2000002DC405128
54000002DC577D28
Address: 000002DC3201
Temp: 23.375
Address: 000002DC4051
Temp: 23.4375
Address: 000002DC577D
Temp: 23.5
The program '[16] Micro Framework application: Managed' has exited with code 0 (0x0).

Things still to add:
Support for reading and writing to the device memory
Throw Events for device alerts
Robust exception handling
Throw Events for devices being added or removed
Support for a variety of One-Wire devices
Automatic instantiation of classes based on detected device family (should probably use some Reflection here)

I think CW2's firmware should get included into the next Beta. Let's get more people trying to use it...

*** Thanks again to CW2 ***

-Valkyrie-MT



Valkyrie,

I noticed that ever time you call Discover() it causes "foreach (var aDevice in gdeviceNetwork)" to add a new device to gDeviceNetwork...

May be intended, but if you put the discover in a loop, it adds a new device for every 1wire device you have on the network each time you call it. Seems like you should put a CRC check to make sure that the same device is not being added for each call...

FYI: I moved the Discover() call outside the loop, once at the top of Main() and it solved my problem..

Scott...

#75 Valkyrie-MT

Valkyrie-MT

    Advanced Member

  • Members
  • PipPipPip
  • 315 posts
  • LocationIndiana, USA

Posted 14 August 2011 - 02:29 PM

I noticed that ever time you call Discover() it causes "foreach (var aDevice in gdeviceNetwork)" to add a new device to gDeviceNetwork...


That was a very early implementation. I fixed a few thing and have added the CRC checking as well. Unfortunately, code specific to my project creaped into my implementation and I haven't had time to factor it back out. But, I can say that the API is capable of everything I wanted and is very reliable.

-Valkyrie-MT

#76 Scott Green

Scott Green

    Advanced Member

  • Members
  • PipPipPip
  • 34 posts

Posted 14 August 2011 - 11:57 PM

Not entirely sure I understand your question, so I'll try to answer with some observations/facts.

  • You must have this native driver to directly communicate with 1-wire devices (parasitic or not) with the Netduino (alternatively, you can use components like those from Peter Anderson)
  • With this firmware, I can read from a mix of DS18B20, DS18S20, DS18B20PAR sensors some connected in parasitic mode (only 2 wires - ground and 1-wire signal) and others connected with the 5VDC (non-parasitic). I currently have 5 sensors connected - 3 are not parasitic and 2 are parasitic. That works fine.
  • On occassion, I will get a bad read (think 1 in 50 reads) for whatever reason (possibly because I don't have a MOSFET as recommended), but with the CRC check, you always know, so I handle them easily. And usually, it won't happen twice on the same sensor.

-Valkyrie-MT



Valkyrie,

Can you elaborate on the CRC fix you are using to deal with the bad reads? I am getting some bogus temp readings as well..

Scott...

#77 Valkyrie-MT

Valkyrie-MT

    Advanced Member

  • Members
  • PipPipPip
  • 315 posts
  • LocationIndiana, USA

Posted 15 August 2011 - 04:24 AM

Can you elaborate on the CRC fix you are using to deal with the bad reads? I am getting some bogus temp readings as well..


For instance with temperature sensors, I've found that there are 2 kinds of bogus values. Ones corrupted in transmission (will fail CRC) and incomplete calculations from the sensors (which returns a default value that passes CRC). So, what I do is maintain the last sensor value in a variable and give that when requested. While at the same time, I routinely try to update the value. Below is the actual code I use for the sensor read with CRC and uninitialized value checking...

                // Write command and identifier at once
                var matchRom = new byte[9];
                Array.Copy(_rom, 0, matchRom, 1, 8);
                matchRom[0] = OneWire.MatchRom;

                _core.Reset();
                _core.Write(matchRom);
                _core.WriteByte(DS18X20.ReadScratchpad);
                System.Threading.Thread.Sleep(5);  // Wait Tconv (for default 12-bit resolution)

                var response = new byte[9];

                var status = _core.Read(response);
                var CRCPass = OneWire.ComputeCRC(response, count: 8) == response[8];
                var Initialized = OneWireExtensions.BytesToHexString(response.Range(0, 1)) != "0550";

                if (status == 9 && CRCPass && Initialized)
                {
                    if (this.FamilyCode == 0x28)
                    {
                        _lastTemp = ((short)((response[1] << 8) | response[0])) / 16F;
                    }
                    else if (this.FamilyCode == 0x10)
                    {
                        _lastTemp = (float)(((short)((response[1] << 8) | response[0])) >> 1) - 0.25F + ((float)(response[7] - response[6]) / (float)response[7]);
                    }
                    
                    _lastTempTime = DateTime.Now;

                    Debug.Print("Getting DS18X20 Temp - " + this.Address + ", " + _lastTemp.ToString());
                }

Also, the .Range method is just an extension method that returns an arrange of the requested range.

-Valkyrie-MT

#78 spur

spur

    Member

  • Members
  • PipPip
  • 27 posts

Posted 11 September 2011 - 06:39 PM

I'm having a problem with the 4.1.1 version of the OneWire firmware. I have a program that reads DS18B20 sensors that I was using with your original OneWire firmware version that worked great. But when I upgraded the firmware on my Netduino Plus to the Plus version of the 4.1.1 OneWire firmware that is attached to the first post in this thread, I get this error when trying to run the same code: "Resolve: unknown type: SecretLabs.NETMF.Hardware.OneWire Error: ff000000" I'm not sure what the problem is. Any ideas? Thanks for your help

#79 andersborg

andersborg

    Advanced Member

  • Members
  • PipPipPip
  • 53 posts

Posted 14 September 2011 - 01:37 AM

The Netduino Plus ZIP doesn't contain the DLL or the other code, only the firmware. If I use the one for Netduino the code builds, including with some of the example code, so the class is used, but I get a "hardware error" (very "descriptive") when deploying. Anything obvious I might have done wrong? Cheers, Anders

#80 andersborg

andersborg

    Advanced Member

  • Members
  • PipPipPip
  • 53 posts

Posted 14 September 2011 - 03:00 AM

I deployed the Netduino Plus version of the firmware with OneWire again, to secure I didn't make a mistake with that. I also put OneWire.cs and DS18B20.cs in my own project and removed the DLL. No build errors. When I deploy on the Netduino I get a NotSupported exception on instantiating OneWire, so clearly I did something wrong. I better stay off this for a while :).




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.