- Netduino Forums
- → Scott Green's Content
Scott Green's Content
There have been 34 items by Scott Green (Search limited from 30-June 23)
#16599 Netduino Plus Firmware v4.2.0 RC1
Posted by Scott Green on 11 August 2011 - 02:24 AM in Beta Firmware and Drivers
#16723 OneWire ALPHA
Posted by Scott Green on 14 August 2011 - 11:57 PM in Beta Firmware and Drivers
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...
#19188 OneWire ALPHA
Posted by Scott Green on 15 October 2011 - 02:21 AM in Beta Firmware and Drivers
#18937 OneWire ALPHA
Posted by Scott Green on 08 October 2011 - 07:24 PM in Beta Firmware and Drivers
wondering if you have gotten the CRC code (after an all channel voltage read) working with a DS2450. I know that its a 16 bit CRC, and the datasheet says that its calculated from Command Byte, Address Bytes, and Data Bytes. But I cant get a calculated 16bit CRC that matches the one that is sent back from the 2450. Heres, some test code...
var response = new byte[8];
var res2 = new byte[2];
var commandaddrdata = new byte[11]; // Array used to calculate the CRC16
var status = _core.Read(response); // Data Bytes
var stat2 = _core.Read(res2); // CRC bytes
commandaddrdata[0] = 0xAA;
commandaddrdata[1] = 0;
commandaddrdata[2] = 0;
commandaddrdata[3] = response[0];
commandaddrdata[4] = response[1];
commandaddrdata[5] = response[2];
commandaddrdata[6] = response[3];
commandaddrdata[7] = response[4];
commandaddrdata[8] = response[5];
commandaddrdata[9] = response[6];
commandaddrdata[10] = response[7];
var crc = OneWire.ComputeCRC16(response, count: 8);
var crcwithcommand = OneWire.ComputeCRC16(commandaddrdata, count: 11);
_LowByte = res2[1];
_HighByte = res2[0];
float DSCRC16 = (((UInt16)_HighByte << 8) | _LowByte);
Using this code DSCRC16 never matches crc or crcwithcommand. Have tried it with both inverted and non inverted high and low bytes on the read CRC.
Any ideas?
Thanks,
Scott...
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
#16702 OneWire ALPHA
Posted by Scott Green on 14 August 2011 - 06:04 AM in Beta Firmware and Drivers
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...
#16603 OneWire ALPHA
Posted by Scott Green on 11 August 2011 - 03:35 AM in Beta Firmware and Drivers
#16689 OneWire ALPHA
Posted by Scott Green on 13 August 2011 - 05:49 PM in Beta Firmware and Drivers
#16695 OneWire ALPHA
Posted by Scott Green on 13 August 2011 - 07:38 PM in Beta Firmware and Drivers
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...
#21275 My Netduino CNC Machine
Posted by Scott Green on 02 December 2011 - 09:25 PM in Project Showcase
- Netduino Forums
- → Scott Green's Content
- Privacy Policy