- Netduino Forums
- → Stuart Crawshaw's Content
Stuart Crawshaw's Content
There have been 60 items by Stuart Crawshaw (Search limited from 29-April 23)
#15036 Netduino Firmware v4.2.0 BETA 1
Posted by Stuart Crawshaw on 05 July 2011 - 10:37 AM in Beta Firmware and Drivers
#15042 Updating Firmware Failure
Posted by Stuart Crawshaw on 05 July 2011 - 12:19 PM in Netduino 2 (and Netduino 1)
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
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.
#15051 OneWire ALPHA
Posted by Stuart Crawshaw on 05 July 2011 - 01:36 PM in Beta Firmware and Drivers
#15060 Updating Firmware Failure
Posted by Stuart Crawshaw on 05 July 2011 - 02:23 PM in Netduino 2 (and Netduino 1)
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.
#15062 Updating Firmware Failure
Posted by Stuart Crawshaw on 05 July 2011 - 02:29 PM in Netduino 2 (and Netduino 1)
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...
#15065 Updating Firmware Failure
Posted by Stuart Crawshaw on 05 July 2011 - 02:35 PM in Netduino 2 (and Netduino 1)
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.
#15066 Updating Firmware Failure
Posted by Stuart Crawshaw on 05 July 2011 - 02:37 PM in Netduino 2 (and Netduino 1)
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?
#15071 Updating Firmware Failure
Posted by Stuart Crawshaw on 05 July 2011 - 02:56 PM in Netduino 2 (and Netduino 1)
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.
#15078 OneWire ALPHA
Posted by Stuart Crawshaw on 05 July 2011 - 04:55 PM in Beta Firmware and Drivers
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?
#15097 OneWire ALPHA
Posted by Stuart Crawshaw on 06 July 2011 - 12:38 AM 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
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.
#15104 OneWire ALPHA
Posted by Stuart Crawshaw on 06 July 2011 - 01:34 AM in Beta Firmware and Drivers
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).
#15120 OneWire ALPHA
Posted by Stuart Crawshaw on 06 July 2011 - 08:52 AM in Beta Firmware and Drivers
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?
#15123 OneWire ALPHA
Posted by Stuart Crawshaw on 06 July 2011 - 09:17 AM in Beta Firmware and Drivers
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?
#15134 OneWire ALPHA
Posted by Stuart Crawshaw on 06 July 2011 - 12:00 PM in Beta Firmware and Drivers
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.
#15137 OneWire ALPHA
Posted by Stuart Crawshaw on 06 July 2011 - 12:20 PM in Beta Firmware and Drivers
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 )
#15139 OneWire ALPHA
Posted by Stuart Crawshaw on 06 July 2011 - 01:09 PM in Beta Firmware and Drivers
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.
#15176 OneWire ALPHA
Posted by Stuart Crawshaw on 07 July 2011 - 11:04 AM in Beta Firmware and Drivers
#15191 OneWire ALPHA
Posted by Stuart Crawshaw on 07 July 2011 - 07:23 PM in Beta Firmware and Drivers
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); }
#15205 DS18*20 Temperature Sensor Auto Identity Circuit
Posted by Stuart Crawshaw on 08 July 2011 - 11:32 AM in General Discussion
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.
Attached Files
- Auto_DS1820_Identify_Circuit_bb.zip 50.43KB 59 downloads
#15210 DS18*20 Temperature Sensor Auto Identity Circuit
Posted by Stuart Crawshaw on 08 July 2011 - 01:12 PM in General Discussion
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
#15281 DS18*20 Temperature Sensor Auto Identity Circuit
Posted by Stuart Crawshaw on 09 July 2011 - 11:41 PM in General Discussion
#15297 DS18*20 Temperature Sensor Auto Identity Circuit
Posted by Stuart Crawshaw on 10 July 2011 - 10:06 AM in General Discussion
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
#15380 Connect Debugger Without a Re-Compile/Re-Send
Posted by Stuart Crawshaw on 12 July 2011 - 04:27 PM in Netduino 2 (and Netduino 1)
#15408 Connect Debugger Without a Re-Compile/Re-Send
Posted by Stuart Crawshaw on 13 July 2011 - 10:29 AM in Netduino 2 (and Netduino 1)
Hi Stuart,
That's possible! You can start MFDeploy.exe and press F5 to follow those texts.
Awesome, Ill give that a try.
Thanks again Stefan for your help and support on my ever growing quest for netduino knowledge
Cheers,
Stuart.
#15409 An error has occurred: please check your hardware.
Posted by Stuart Crawshaw on 13 July 2011 - 10:31 AM in Visual Studio
It looks like there's a glitch in your current project files. Perhaps they're trying to use an assembly which doesn't match the version of those already on the Netduino?
Yes, i had this problem when trying with the OneWire library by CW,
I had referenced the wrong DLL in my code and it did this everytime untill i referenced the correct one.
Regards,
Stuart.
- Netduino Forums
- → Stuart Crawshaw's Content
- Privacy Policy