26 replies to this topic

[OZ8ET]

Sorry to be a bit negative. My previous exitement for NetduinoPlus has slowly turned into a lot of frustrations. I may be stupid, but I based my project on Onewire, and maybe I am the only one left en the world using it. After asking around a lot in the forum, I found CW2's very nice implementation which I still use with Firmware version 4.1.1. 4.1 had other problems (OutOfMemoryExeption in Stremwriter) and I have been looking forward to version 4.2 in the hope that this problem was solved. I was promised that there would be a 'speciaol verion' of 4.2 with onewire support, but after the introduction of NetduinoGo, it looks like no one cares about NetduionoPlus anymore. I am about to give up on this forum. My requests are no more answered and it is not even possible to find them searching my own comments (sometime I can find them by searching specific text). It is not my intention to be destructive, but I think my life with NetduinoPlus is running into a deadend.

[Stefan]

Hi Oz8et,

I can promise you, the Netduino Plus won't be forgotten with Netduino Go.
4.2 for Netduino Plus still has some issues, because of which it isn't released yet. This is described here: http://forums.netdui...dpost__p__30887

OutOfMemoryExeption in Stremwriter

Hmm interesting, I haven't seen your thread about that, but I'm curious how that happens. I do know though, that the Netduino has not a big stream buffer. So reading it in smaller chuncks could help.

[Chris Walker]

Hi OZ8ET, We love all the Netduinos equally, and are really looking forward to the .NET MF 4.2 QFE2 update so we can hopefully bring the Netduino Plus firmware out of beta. This board is very popular, and we intend to continue enhancing it and supporting it and its users. There is no OneWire support in NETMF, but CW2 was really cool and created an implementation for Netduino's SAM7X microcontroller. Once the .NET MF 4.2 firmware comes out of beta, we'll be happy to create a special build of the firmware with CW2's OneWire support built in. We'd do it for every beta, but we're trying to focus on helping out community members, fixing bugs, etc. What issues are you experiencing with the production firmware (4.1.0.6 or 4.1.1) today? We're happy to help...we're just limited in how much we can help with 4.2 until it comes out of beta. Chris

[CW2]

There is no OneWire support in NETMF

Just for clarification, the support for Maxim/Dallas 1-Wire was added to .NET Micro Framework 4.2 in changeset 12695, based on 1-Wire Public Domain Kit.

[Chris Walker]

Hi CW2,

Just for clarification, the support for Maxim/Dallas 1-Wire was added to .NET Micro Framework 4.2 in changeset 12695, based on 1-Wire Public Domain Kit.

Is the new support built into the NETMF 4.2 PK as good as your library? Do you think we should switch over to that version? I have heard that yours was a nicer implementation...

Chris

[OZ8ET]

Thanks for quick reply Stefan and Chris

I am now using NetduinoPlus_v4.1.1_beta1_CW.NETMF.OneWire-1.0.5.0

I was having problem with I2C because of som problem in firmware but this may have been with 4.1.0-6 - I gave up on I2C because of that.

Now I have probems with StreamWriter.

    #### Exception System.OutOfMemoryException - CLR_E_OUT_OF_MEMORY (4) ####
    #### Message: 
    #### System.IO.StreamWriter::.ctor [IP: 0023] ####
    #### Main.CIni::Save [IP: 0020] ####
    #### Main.Engine::update [IP: 0026] ####
    #### Main.OneWireEngine::onPoll [IP: 01e8] ####
A first chance exception of type 'System.OutOfMemoryException' occurred in System.IO.dll

This is the Code:

		public static void Save()
		{
			try
			{
				Debug.GC(true);
				if (File.Exists(_FileName)) File.Delete(_FileName);
				using (FileStream outFileStream = new FileStream(_FileName, FileMode.CreateNew, FileAccess.Write))
				{
					using (StreamWriter outStreamWriter = new StreamWriter(outFileStream))
					{
						foreach (object Sections in _Sections.Keys)
						{
							outStreamWriter.WriteLine("[" + Sections.ToString() + "]");
							Hashtable keyvalpair = (Hashtable)_Sections[Sections];
							//foreach (object key in keyvalpair.Keys)	outStreamWriter.WriteLine(key.ToString() + "=" + keyvalpair[key].ToString());
							string s = "";
							foreach (object key in keyvalpair.Keys) s += (key.ToString() + "=" + keyvalpair[key].ToString() + '\r');
							outStreamWriter.Write(s);
						}
						outStreamWriter.Close();
					}
					outFileStream.Close();
					_Dirty = false;
				}
			}
			catch (Exception Ex) { Fail.Create("Init Save: " + Ex.Message, 5); }
			Debug.GC(true);
		}

ways to (partly) deal with the problem are:
- spreading "Debug.GC(true);" all over the place in rich quanities.
- NOT making small chunks of date to write, but puttin everything in one string!!!

I can make a small program with only read and write of the file, and it will usually work but as soon as I add other code to it, problems begin.

Erik

[JerseyTechGuy]

I am not sure if the same issue is occurring that I had on my project but I was getting the same error message writing to the SD card. In my project I have 6 sensors that are being polled up to 3 times a second then that data is written to 6 different log files using the same basic method as you. I was getting this same error and it was due to trying to write the data too fast (or I assume that was the case). So I put a few Thread.Sleep(1) or Thread.Sleep(10) in certain places to allow for catch up and completion of the file create/close and write/close. This worked and it has never thrown an error again after running hundreds of hours now.

[Mario Vernari]

CW2 brought us a great value added, as anyone else is able to modify the Netduino firmware, introducing new useful features. However, my viewpoint is toward the maintenance of the boards. If you need a special firmware for having a medium-usefulness feature, I'd rather avoid to detach a trunk from the standard firmware releases. I never used the one-wire protocol, because it's not not widely used as the SPI, UART or I2C. Okay, you save one wire, but within a small circuit wiring a couple (or more) is generally not a big issue, IMHO. If you take a look closer to the one-wire protocol, you could emulate without driving crazy by using the SPI. That's much like the IR-protocol I've created for the Netduino. Since this platform (.Net Micro Framework) is all-but-realtime, when you need something timing-reliable, the only decent way is seeking among the embedded peripherals of your board. The SPI (as well as many other parts) is very fast, and very reliable in terms of timing. When you send a stream, it is pushed out without any delay, at the SCLK bit-rate. The worst case is when you have an highly intensive-GC application and the SPI steream is pretty long. At that time you could have a brief delay breaking your message. That means a communication going wrong, and should be replicated. Not a big issue, though. About the N+, I own one and I'm happy with it. The real challenge is solving the hardest tasks such this one. That's exciting me a lot! Hope it helps. Cheers

[Valkyrie-MT]

Is the new support built into the NETMF 4.2 PK as good as your library? Do you think we should switch over to that version? I have heard that yours was a nicer implementation...

Chris,

I see your dilemma. On the one hand, you have this great implementation from CW2 that has a perfect track record IMHO, and a good API. But, on the other hand, if everyone starts to rely on that implementation, it would be a breaking change to switch later. But, I think that the breaking change is a red herring. Anyone can easily rewrite the impacted code and switch from one API to another within a few hours. I would go with the CW2 library.

By the way, I have been using the CW2 OneWire Library for a year now, with devices continuously running 24/7 with long wire runs of over 100 feet and has proven to be the most reliable part of my system. Also, I have used the OneWire implementation that comes with the Framework and although the API is clumsy, it does work.

So, I would go with the CW2 library exactly as it is in the old alpha. And don't be afraid to change later if you have to. Some people may whine, but they will get over it. Having the Capability and Reliability is the most important aspect. Don't lose the forest through the trees.

Also, while we're on the subject of breaking changes, I would prefer not "reserving" memory for possible future expansion as may be done today. These are Micro devices, let's have all the memory possible and if a new firmware reduces the amount of memory people can weigh the pros/cons themselves and stick with the old or move to the new... 2 cents.

-Valkyrie-MT

[Mario Vernari]

By the way, I have been using the CW2 OneWire Library for a year now, with devices continuously running 24/7 with long wire runs of over 100 feet and has proven to be the most reliable part of my system. Also, I have used the OneWire implementation that comes with the Framework and although the API is clumsy, it does work.

Please, could you describe how is the 100ft wiring so that the OneWire (as-is?) is working reliably? I'm having hard time believing it's working without a *GOOD* impedance adaption, on both sides.
Thanks and cheers

[OZ8ET]

I find CW2's implementation very reliable. I use a digital port directly with a 1K8 resister to +5V - it drives about 5 meter with many drops and no problems. Implementing One-wire devices is not dificult. Erik

[Mario Vernari]

I find CW2's implementation very reliable. I use a digital port directly with a 1K8 resister to +5V - it drives about 5 meter with many drops and no problems.
Implementing One-wire devices is not dificult.

Erik

I have no doubt about the good realization of CW2, nor in your bona-fide...the problem is exactly what you write: the impedance is not balanced, thus the "reliability" is just a statistical performance of your implementation.
Basically, you have just one (?) resistor as pull-up by the Netduino side (or the other).
First off, when the line is pulled down the impedance is almost zero Ohms, but when the line is left floating the actual impedance is 1.8k.
Secondly, probably your 5mt wiring is short enough to avoid reflections, otherwise an high-impedance (by the device side) would have a mirror-effect for the high frequencies. You know, any edgy wave is composed as very high frequencies.
Thirdly, I suppose your wiring is a shielded cable, or either your wires run along a noiseless environment. If not, your signal would be plenty of undesired noise, spikes, and whatever else.

It's just a clarification, because many users are asking that, but the long wiring is often an hard task to solve.
Cheers

[OZ8ET]

I am not sure if the same issue is occurring that I had on my project but I was getting the same error message writing to the SD card.

In my project I have 6 sensors that are being polled up to 3 times a second then that data is written to 6 different log files using the same basic method as you.

I was getting this same error and it was due to trying to write the data too fast (or I assume that was the case). So I put a few Thread.Sleep(1) or Thread.Sleep(10) in certain places to allow for catch up and completion of the file create/close and write/close. This worked and it has never thrown an error again after running hundreds of hours now.

Thanks Dave - I tried this but with no luck.

Erik

[OZ8ET]

I have no doubt about the good realization of CW2, nor in your bona-fide...the problem is exactly what you write: the impedance is not balanced, thus the "reliability" is just a statistical performance of your implementation.
Basically, you have just one (?) resistor as pull-up by the Netduino side (or the other).
First off, when the line is pulled down the impedance is almost zero Ohms, but when the line is left floating the actual impedance is 1.8k.
Secondly, probably your 5mt wiring is short enough to avoid reflections, otherwise an high-impedance (by the device side) would have a mirror-effect for the high frequencies. You know, any edgy wave is composed as very high frequencies.
Thirdly, I suppose your wiring is a shielded cable, or either your wires run along a noiseless environment. If not, your signal would be plenty of undesired noise, spikes, and whatever else.

It's just a clarification, because many users are asking that, but the long wiring is often an hard task to solve.
Cheers

Sorring - the correcte lenet is 50 meters (150ft). It was an erfor in writing

[Mario Vernari]

sorry,but I can't believe that a simple port connection with a pull up is reliably running a communication over 50 m. Have a look here: http://www.maxim-ic....ndex.mvp/id/148

[OZ8ET]

One thing is theory - annoter practise. anyway - the issues were onewire support ón 4.2 and OutOfMemoryExeption with streamwriter!

[Valkyrie-MT]

sorry,but I can't believe that a simple port connection with a pull up is reliably running a communication over 50 m.

Why not? I have read that document and MANY others on this. But, the one you reference specifically states "A simple resistor pullup has a weight limitation of about 200m. "

I will say though that I do sometimes get a bad read from a sensor. The frequency seems to be about 1 per thousand. But is easily detected and discarded with the CRC check. Also, I have tested 5 sensors on 500 feet of unshielded wire and saw little to no increase in the bad reads. Also, I don't even use the suggested FET or diode. It was never necessary.

-Valkyrie-MT

[Mario Vernari]

Well, guys: I may believe on your words, but I still don't believe unless I have a look at some network topology and its waveforms. I guess your own "lucky" case is working pretty well, but I wouldn't rely on such a weak system. BTW, the same specs clearly states that the 1-wire is designed for short wiring. We're developing hard/heavy-noisy cabling for plants, and even RS485 (opto-coupled and coax cable) has sometime trouble. Automotive uses CAN: they're desperately seeking to save cable length, so why don't use one-wire for so short distances? Useless going further. Cheers

[nunya]

I am a .net developer and have played around with arduinos a little. I was very excited to see .net micro and the netduino. However, I got OneWire working in about 5 minutes on an atmega328. I give the credit to excellent libraries and a large active community. With the netduino plus and v4.2 I have wasted 4 hours to find that there is yet no support for OneWire. With that, I am returning to the arduino. Netduino has wasted too much of my time and caused too much frustration.

[nakchak]

Why use 4.2? It's not even out of beta yet for the nd By all accounts the one wire firmware for nd (based on 4.1) is excellent... Nak.