Is this the end of NetduinoPlus?
#1
Posted 20 July 2012 - 06:31 AM
#2
Posted 20 July 2012 - 06:41 AM
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
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.OutOfMemoryExeption in Stremwriter
My .NETMF projects: .NETMF Toolbox / Gadgeteer Light / Some PCB designs
#3
Posted 20 July 2012 - 06:47 AM
#4
Posted 20 July 2012 - 07:08 AM
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.There is no OneWire support in NETMF
#5
Posted 20 July 2012 - 07:09 AM
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
#6
Posted 20 July 2012 - 07:15 AM
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
#7
Posted 20 July 2012 - 12:06 PM
#8
Posted 20 July 2012 - 12:34 PM
#9
Posted 20 July 2012 - 02:40 PM
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
#10
Posted 20 July 2012 - 03:23 PM
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
#11
Posted 20 July 2012 - 03:52 PM
#12
Posted 20 July 2012 - 04:16 PM
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
#13
Posted 20 July 2012 - 04:26 PM
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
#14
Posted 20 July 2012 - 05:03 PM
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
#15
Posted 20 July 2012 - 05:52 PM
#16
Posted 20 July 2012 - 06:58 PM
#17
Posted 20 July 2012 - 07:32 PM
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
#18
Posted 21 July 2012 - 04:54 AM
#19
Posted 28 July 2012 - 12:36 PM
#20
Posted 28 July 2012 - 01:21 PM
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users