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

Yes, please try that.

Also...we created a patch in the v4.1 firmware which helped fix this issue. We removed the patch in v4.2, since Microsoft incorporated a permanent fix for the issue there. If you are running into new issues with 4.2, we'd love to know more...so we can update the bug ticket at netmf.codeplex.com.

Thanks for helping test 4.2!

Chris

Running 4.2, i still get the Debugger not in an initialized state, rebooting message.
Hitting the reset button does nothing, pulling the power and re-inserting it seems to move things along.

MFDeploy sometimes doesn't print the entire text...there's some buffering going on. But the .NET MF runtime does a bit of signature checking each time you boot it. There are multiple levels of verification built in.

Chris

Thats good to know,

Seems I am good to go. i just deployed the very well known "blinking LED" code and it deployed and run successfully.

I have however noticed that when deploying, i will sometimes get a message along the lines of "Debbugger not in an initilized state; rebooting" but it does not seem to do anything.

It it just a case of disconnecting the device/pushing the reset button at this point and trying again?

Hi Stuard,

When you went from 4.1.x to 4.2b1 you also updated the bootloader. When you tried to go back to 4.1.x, did you wrote back the older bootloader as well?

I did indeed. And just to confirm, i verified the written bootloader with the file using SAM-BA.

Hi Stuart,

It looks like you're all set. Sometimes MFDeploy needs a quick disconnect/reconnect of your device after updating...the Device Capabilities info (and the fact that your Netduino is booting into the TinyCLR runtime) means that it updated correctly.

Please go ahead and deploy some apps to your Netduino. If it gives you any troubles, we'll be here to help sort it out. The good thing about Netduino is that, since it's open source, you can erase and reflash it any way you'd like...and there's a community of nice folks here to help if you run into troubles.

Chris

Awesome, thanks confirming that all is ok.

Just to confirm, MFDeploy doesnt need to give a full output for the update to be successful? (as I tend to only get "Chk s" or "Chk signa" but never a full line of text...

Hi Stuart Crawshaw,

Welcome to the boards!
In MFDeploy, if you click Target->Device Capabilities, what does it output?
And which firmware version did you had before, and to which version you're trying to upgrade?

Hi,

Thanks for the reply. If i run the Device Capabilities option i get:

HalSystemInfo.halVersion:               4.2.0.0
HalSystemInfo.halVendorInfo:            Netduino (v4.2.0.0 b1) by Secret Labs LLC
HalSystemInfo.oemCode:                  34
HalSystemInfo.modelCode:                177
HalSystemInfo.skuCode:                  4096
HalSystemInfo.moduleSerialNumber:       00000000000000000000000000000000
HalSystemInfo.systemSerialNumber:       0000000000000000
ClrInfo.clrVersion:                     4.2.0.0
ClrInfo.clrVendorInfo:                  Netduino (v4.2.0.0 b1) by Secret Labs LLC
ClrInfo.targetFrameworkVersion:         4.2.0.0
SolutionReleaseInfo.solutionVersion:    4.2.0.0
SolutionReleaseInfo.solutionVendorInfo: Netduino (v4.2.0.0 b1) by Secret Labs LLC
SoftwareVersion.BuildDate:              Jun  8 2011
SoftwareVersion.CompilerVersion:        400902
FloatingPoint:                          True
SourceLevelDebugging:                   True
ThreadCreateEx:                         True
LCD.Width:                              0
LCD.Height:                             0
LCD.BitsPerPixel:                       0
AppDomains:                             True
ExceptionFilters:                       True
IncrementalDeployment:                  True
SoftReboot:                             True
Profiling:                              False
ProfilingAllocations:                   False
ProfilingCalls:                         False
IsUnknown:                              False

which does seem like it has updated. But what is concerming me is that it may not be fully updated/stable as all the output from MFDeploy is not there.

I have updated from the stock FW when i bought the unit, to the 4.2 beta 1 version (including the bootloader), then tried a non-beta (4.1.0.6 i think) and that had the same output result in MFDeploy and now I have tried again with the beta (as the above output would suggest.

But as mentioned before, due to the output (or lack thereof) i am dubious as to whether it has updated correctly.

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.

Hi All,

I am currently having a major problem updating the firmware on my netduino.

Here are the steps i am taking:

• Open MFDEPLOY.exe
• Click Ping (Get response "Pinging... TinyCLR")
• Browse for update files and click Deploy
• Progress bar says the following:
  
• Connecting to device
• Connecting to TinyBooter
• Checking Signatures
• Erasing 0x0010C000
• Deploying ER_FLASH
• Checking Signature
• Executing Application

The progress window then closes and i am left with an output of:

Pinging... TinyCLR
Chk siCh

If i try anything else in MFDEPLOY after this, i get "Pinging... Error: No response from device"

If i disconnect it from power and then reconnect, i can then ping it but i dont think the Firmware is properly installed.

Any clues?

Thanks.

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,