The 24LC256 is tested successfully. I think the signal is the same but you won't harm a thing by trying I suppose

Ok sounds good to me. So on your recommendation (at least until 4.2 makes it to release, and if the powers that be roll a version with one-wire) i have downgraded to the 4.1.1 FW attached to this thread.

But now, i cannot deploy anything to it... I just get a message stating:

Error	1	An error has occurred: please check your hardware.

If you go to your project properties, what's the target framework? See this screenshot for what I mean.
Also, to which device does it try to deploy? See this screenshot for what I mean.

Hi,

Checked that as you advised and the Target is 4.1 (i have uninstalled the 4.2 SDK and installed the 4.1 again)
Then checked Deploy device, and it says USB > Netduino_netduino.

I might try re-flashing again:

To confirm, i am ok to use the 4.1.0.6 TinyBooter for use with the 4.1.1 Beta 1 with CW's OneWire FW? If not where can i download the correct booter image (its hard to find downloads for the different versions on here )

Should be right.
As far as I know, yes.

Sorted it, was my fault really.

I had reference the dll for the onewire managed code which resides in the "le" folder where as the test app references the on in the root of the Debug directory.

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);
}

Do you have an example IC? I used a 24LC256 EEPROM with success on a 4.1.x Netduino.

I believe This one is in the same family. You mention using it successfully? Did you use commands such as Random Read (Figure 7.2) as this requires a repeated START signal?

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.

HI Stuart,

An I2C EEPROM also works on 4.1.x firmwares. Code sample can be downloaded at http://forums.netdui...e-i2cbus-class/

Even the ones where repeated START signals are required?

Hi guys,

I havent been able to find the answer to a question i have been asking myself.

Does this only apply to the DS1820 sensors when used in Paracitic power mode ONLY? as my understanding is, it was a limitation because of the timings being in milliseconds and anything longer than 970uS would cause a power-on reset to occur?

So, the question is, do i need this native driver if i an wiring my DS Sensors in a non-paracitic circuit?

Thanks,
Stuart.

Anyone?

Hi guys, I havent been able to find the answer to a question i have been asking myself. Does this only apply to the DS1820 sensors when used in Paracitic power mode ONLY? as my understanding is, it was a limitation because of the timings being in milliseconds and anything longer than 970uS would cause a power-on reset to occur? So, the question is, do i need this native driver if i an wiring my DS Sensors in a non-paracitic circuit? Thanks, Stuart.

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

Thats a shame, i was hoping to write my own class to handle the DS1829 sensors so i could continue to use/test the 4.1 FW.

The 1-Wire firmware is built with the 4.1.1 Beta 1 FW already. Were you testing the 4.2.x FW? As I understand it, the reason you have to have the 1-Wire support in the firmware is because 1-Wire communication is too fast for the managed code to handle.

-Valkyrie-MT

Hi,

Yes i am running the 4.2.x FW. I originally wanted to know if the OneWire limitation was for paracitic mode only, but you have answered that question for me.

But yes, it does seem that the managed code is too slow for onewire to be used without native support.

the reason i want to use the 4.2.x FW is its I2C support as i want to include an I2C EEPROM chip i have to save user settings (such as high temp thresholds etc for a thermostat type setup).

Hi all, Does this beta include the OneWire support by CW2? On another note, Since updating i can no longer deploy to my Netduino... I just sticks at deploying... I did notice however that when updating with MFDeploy, the output did not seem "complete" (see below) Deployment Status says: 1. Checking Signature 2. Erasing 0x0******* (cant remember exactly) 3. Deploying ER_FLASH 3. Checking Signature 4. Exiting application and the output window of MFDeploy says: "Chk s" and thats it. If i then try to click Target > Device Capabilities, it says "Error: No Response From Device" Ive seen screenshots and this normally says "Checking Signature, "Signature Passed"? Any idea what might be going wrong? Thanks,

That's true indeed.
Consider that any heat sink close to the soldering point will cool the iron temperature. That could give a bad melting and a matt/crystalled result. Along this way, a regulated iron guarantee always a good soldering.
Cheers

Thanks for the heads up.

Im currently using a variable temperature gas soldering iron, it seems to do the job quite well. I manage the tip temperature with an infrared thermometer.

Thank you all so much for your input, this has been very helpful. Thank you Dan for the links you posted, I was looking for something like that. Especially since the croc-clips would act as a kind of heat shunt to protect the component being soldered. Regards, Stuart

The DS1820 i am referencing is a 3-pin package similar to that of the 2n2222 transistor. By techniques i mean how would you do it, do you have any tips or tricks etc...

Hello Everybody, General question to go out ot everyone regarding Soldering Techniques.... When soldering small components, for example: the wires on to the pins of a DS1820 sensor, how do you go about this? Ill also open this question up to everyone to share any other soldering Techniques they use when soldering other things too! Thanks again guys, Cant wait to see how you get yours done! -------- Stuart.

Just to add as i dont know if its been touched on in this thread. The DS1207 requires the repeated start support of one of the custom built FW's (Im using 4.1 with CW's OneWire Library) Can you confirm if you are using the stock firmware or a custom build with the repeated start bit support?

Also i noticed this in your code

I2CDevice.I2CTransaction[] tran = new I2CDevice.I2CTransaction[]{tran_write}; 
 
            int data = RTC.Execute(tran, 100); 
 
            Debug.Print("\nThe number of data transfered is: "+ data.ToString()); 
 
            tran = new I2CDevice.I2CTransaction[] { tran_read }; 
            
            data = RTC.Execute(tran, 100); 

After each Execute, it would produce a stop bit. Thus cancelling the address it was at (I think) and the read may not know where to reference.

Stefan, Can you confirm this? as i dont have my DS1307....yet...

Yes, I connected everithing well again......thank you very much for wasting your time with my problem, shure that the problem it´s a little detail(a dumb detail shure) but if I can i would try to put a photo of whow I´ve got the connections.........

You are not wasting our time i assure you. The success of a good community is mutual help. No problem is dumb, its all down to experience (I am not an expert in electronics at all, im a coder)

No question, big or small is a dumb question. The most intelligent thing people can do when unsure is to ask

P.S. Did you see my code example i posted on the previous page (hate pages ) the attached library/wrapper may well prove useful.

I updated the firmware to 4.1.1 beta version but I´m in the same way, it doesn´t work neither with my code not with that one you posted, it gives me the same error that i have told you before..........

OK,

Can you post the code you have used, please bare in mind that the transaction for a read should include an initial write (to write the address of the register to be read) and then a read.

Please see this excract of code from the FusionWare I2C Library (attached).

/// <summary>Performs a common Write-repeatstart-read command response operation</summary>
/// <param name="Config">Configuration for the bus during this operation</param>
/// <param name="WriteBuffer">Buffer containing data to write</param>
/// <param name="ReadBuffer">Buffer to receive data. The Length property of ReadBuffer determines the number of bytes to read</param>
/// <param name="TimeOut">Millisecond time out value</param>
/// <remarks>
/// Many I2C devices have a simple command response protocol of some sort
/// this method simplifies the implementation of device specific drivers
/// by wrapping up the I2CTransaction creation and timeout detection etc.
/// to support a simple command/response type of protocol. It creates a write
/// transaction and a read transaction with a repeat-start condition in between
/// to maintain control of the bus for the entire operation. 
/// </remarks>
/// <exception cref="T:System.IO.IOException">Operation failed to complete</exception>
public void WriteRead(I2CDevice.Configuration Config, byte[] WriteBuffer, byte[] ReadBuffer, int TimeOut)
{
    ThrowIfDisposed();
    lock(this.Device)
    {
        this.Device.Config = Config;
        I2CDevice.I2CTransaction[] xacts = new I2CDevice.I2CTransaction[] {
            I2CDevice.CreateWriteTransaction(WriteBuffer),
            I2CDevice.CreateReadTransaction(ReadBuffer)
        };

        // I2CDevice.Execute returns the total number of bytes
        // transfered in BOTH directions for all transactions
        int byteCount = this.Device.Execute(xacts, TimeOut);
        if(byteCount < (WriteBuffer.Length + ReadBuffer.Length))
            throw new System.IO.IOException();
    }
}

EDIT: Corrected spelling of FusionWare

Can't confirm nor contradict it; I didn't wrote the code, only successfully implemented it. But I used the 4.1.1 beta firmware at that time.

Ahh ok,

I believe it would thought, makes sense that it would to me.

If it is the case, then the read command would be executed without an address being sent to the device.

You may also want to check out Stuart's DS18*20 Temperature Sensor Auto Identity Circuit.

Thanks for the link to my topic! Just to update on this, i am awaiting components to build the circuit, just need some transistors really. Currently working on the code to do the hard work and then ill post it all on my thread.

In theory, with my idea, you would have as many sensors on the bus as needed (buy you would need a transistor for each of them to turn them on/off) and a shift register per eight sensor/transistor pairs.

so in the case of 8 sensors, you would send 1 byte to the shift registor to set pin 0 high and the rest low -> read the ROM code from the sensor bus, and then turn off pin 0 and turn pin 1 on etc etc... at the end send all 1's to the SR and all sensors will be active.

Hi mcinnes01, The idea is feasable. Only I have decided that the tansistors should be on the groung pins of the sensor as they won't allow the data pins to work otherwise. Once I have some code I will post it on here with my final circuit design too. You idea would also work but would be a alittle bit of an annoyance if you have to do it a lot. I was either going to store these values on an eeprom or similar. Also this way I can drive an lcd and this temp sensor circuit off of 5 pins total.

You might also check out DS1825 thermometer, which has 4-bit location address.

Hi CW,

Thanks for the reply. I was really interested in the sensor provided but noticed it is only available in one package type.

I want to eventually have these on the end of wires etc for long lead probes.

I am greatful you took your time to suggest these though. I will be sure to bookmark them incase of another project.

thanks again,
Stuart

Another elaboration on my idea could be to sense if there is a current on a particular port. That way when you plug in a probe your code knows which socket it realtes to and can then go about checking the addresses as described above. That way it wouldn't matter which order you plugged them in you would just need a current sensing circuit across the the 5 sockets. This would work as you wouldn't simultaneously plug all 5 sensors in, so the code could easily assign the address to a variable relating to the corresponding socket that it sensed a change in current from logic level to 0.

Yes, that thought had crossed my mind, but i would like to connected/disconnect devices while the board is un-powered (to limit that chances of shorting or anything else that could happen as I am plugging the devices in.

Mainly the idea was to combat the senario what all sensors are plugged in, placed in the location to be monitored and the netduino powered on. Then i could use a menu system to say Port one is monitoring a power supply, port 2 a water filter temperature and so on, without having to connect them individually and assign their names.