OneWire ALPHA
#41
Posted 05 July 2011 - 01:36 PM
#42
Posted 05 July 2011 - 02:10 PM
#43
Posted 05 July 2011 - 04:55 PM
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?
#44
Posted 06 July 2011 - 12:08 AM
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?
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
#45
Posted 06 July 2011 - 12:34 AM
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
Thanks Chris! I have the 4.2 firmware on one of my netduino pluses, but just don't do much with it because I use this 1-Wire stuff so much now. I have had my 4.1 boards working for days serving web requests with 1-wire sensor data. (Note: it's only days because I am constantly changing the code and restarting it, it never fails). But, I see a lot of OutOfMemory exceptions with 4.1 (which never seem to be fatal for me). And it's not just the compacting message either. My memory exceptions always seem to be in string concatenation, so I am really looking forward to having a real StringBuilder in 4.2 and the GC improvements and the GC debugging stuff. You can be sure that as soon as there is a 4.2 build with 1-Wire for the N+, I'll be testing it extensivly! It pains me not to test 4.2 more now...
Oh, and is the 50% more RAM going to be a standard feature going forward on all the firmware builds?
Thanks,
-Valkyrie-MT
#46
Posted 06 July 2011 - 12:38 AM
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.
#47
Posted 06 July 2011 - 01:25 AM
Yes! I'm not sure how much "more RAM" the final # will be (and .NET MF 4.2 does take a bit more RAM than .NET MF 4.1), but the 4.2 firmware will provide quite a bit more RAM than the official spec.Oh, and is the 50% more RAM going to be a standard feature going forward on all the firmware builds?
Chris
#48
Posted 06 July 2011 - 01:29 AM
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
#49
Posted 06 July 2011 - 01:34 AM
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).
#50
Posted 06 July 2011 - 04:35 AM
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).
Why not use the microsd card slot to save settings to a microsd flash card? Only $3 for a 1GB card... Oh, you don't have a Plus, you have a regular Netduino... Also, in a future version of the 4.2 FW, a small amount of integrated storage will be made available for storing settings. So, I don't know that and EEPROM via I2C is the most simple choice. Although, I'm sure it would be fun to implement
-Valkyrie-MT
#51
Posted 06 July 2011 - 06:13 AM
HI Stuart,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).
An I2C EEPROM also works on 4.1.x firmwares. Code sample can be downloaded at http://forums.netdui...e-i2cbus-class/
My .NETMF projects: .NETMF Toolbox / Gadgeteer Light / Some PCB designs
#52
Posted 06 July 2011 - 08:52 AM
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?
#53
Posted 06 July 2011 - 09:09 AM
Do you have an example IC? I used a 24LC256 EEPROM with success on a 4.1.x Netduino.Even the ones where repeated START signals are required?
My .NETMF projects: .NETMF Toolbox / Gadgeteer Light / Some PCB designs
#54
Posted 06 July 2011 - 09:17 AM
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?
#55
Posted 06 July 2011 - 09:25 AM
The 24LC256 is tested successfully. I think the signal is the same but you won't harm a thing by trying I supposeI 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?
My .NETMF projects: .NETMF Toolbox / Gadgeteer Light / Some PCB designs
#56
Posted 06 July 2011 - 12:00 PM
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.
#57
Posted 06 July 2011 - 12:16 PM
If you go to your project properties, what's the target framework? See this screenshot for what I mean.But now, i cannot deploy anything to it... I just get a message stating:
Error 1 An error has occurred: please check your hardware.
Also, to which device does it try to deploy? See this screenshot for what I mean.
My .NETMF projects: .NETMF Toolbox / Gadgeteer Light / Some PCB designs
#58
Posted 06 July 2011 - 12:20 PM
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 )
#59
Posted 06 July 2011 - 12:24 PM
Should be right.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.
As far as I know, yes.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?
My .NETMF projects: .NETMF Toolbox / Gadgeteer Light / Some PCB designs
#60
Posted 06 July 2011 - 01:09 PM
Sorted it, was my fault really.Should be right.
As far as I know, yes.
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.
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users