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.

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.

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?

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

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.

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).

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.

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,

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.

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...

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

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.

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.

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.

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

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...

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?

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.

Has anyone got any experience with these units?

DSO Nano v2

Hi all,

I have though up a circuit which will help me on a project i am working on. The basic outline is as follows:

I have 5 ports into which i can plug in up to 5 DS18*20 temperature sensors. The ports are numbered 1 - 5.
The problem i came accross in the early stages was, how do i know in my code which sensor ROM code is for which sensor (without having to force a higher temp and read all of them to see which code is higher.)

Say i had sensor in port 1 monitoring a power supply internal temp, Sensor in port 2 monitoring water temperature somewhere. And a sensor in port 3 monitoring another temperature somewhere else.

How could i pair the locations of the sensors (port or physical) to the rom codes?

This is where i thought of the attached circuit(It may be overkill, and may be missing some componenets such as resistors etc. But that is what this thread is for).

The idea is, each sensor port has an address of its own. On initialization, the shift register is fed the relevant bits to turn on one DS1820 at a time and read the ROM code then assign that rom code to that port name.

After all 5 ports have been individually turned on, and ROM codes discovered/not found, the shift register is fed all 1's to turn all DS1820's on.

So the question:

1. What transistor should i use to switch the DS1820's on/off (or maybe even a trasistor array? i was looking at this)

2. Am i missing any resistors (maybe on the transistors or something) if so what values would you suggest.

3. Can you think of a better way to do this, other that plugging each individual sensor in to its own digital IO port on the Netduino?

4. Can you offer any modifications to make this more effecient etc...


Thanks for your help on this, Constructive critisism is appreciated and any suggestions welcome.

Regards,
Stuart.

Hello Stuart.
I am NOT sure to understand well what you are looking for, NOR I know the 1-wire protocol (I had a peek right now at the specs).
Basically you would have a "kind of switch" to use on the beginning of your program, so that the codes of the probes could be read. Then, you will have a code-port pair well-known.
Instead of using your circuit (missing the resistors from the HC595 to the transistor base), I'd suggest an alternative, that will flip upside-down the whole approach. However that's working only if I understand correctly.

Consider this chip: 74HC4051. It's basically a bidi-switch. Just think the old-fashion electric appliances, having a rotary switch with position 1,2,3 etc. Its particularity is that is "transparent", as it was a wire connecting an input to the output...by the way it's almost improper to call them "input" and "output".

Well, now refer to the HC4051 sheet. Consider to connect each data lead of your probes to the Yx pins of the 4051. The Z pin will be connected to the Netduino 1-wire pin.
Your program must choose, once a time, which "Y" to connect with "Z". To do that, you must set the S0,S1,S2 inputs properly, using three Netduino outputs.
Using this approach, you MUST always switch the right probe. You cannot select more than a probe a time, but the circuit looks much more compact and clean.

Feel free to tell me if this idea fits your goal or not.
Cheers

Hi thanks for the suggestion,

Unfortunatly i want to be able to addrss all of the probes at the same time as well as individually on initialization.

I should have mentioned that I am using spi with the shift register and there are othrr tegisters on the spi which controll lcd's etc. So using the chip mentioned above would use more pins

Thanks again for the input