demonGeek

The scope of his using is the entire while statement that follows it. (The indentation may have been misleading in this case.) "using" is like "if" or "while" in the sense that it can be used without braces, though just as with if and while I would encourage the style of always using braces.

Yes, I realized that. My point was that without explicitly defining the scope the object isn't going to get disposed any sooner than the end of the method. He mentions in his post that he's a C# newbie so I think it's quite possible that he wasn't even aware of the scope issue and I figured it was worth pointing it out.

I'd like to vote against this advice for a variety of reasons. The StreamWriter object is not guaranteed to be collected at any particular time such as the end of the method (in fact, there's no particular guarantee that it will ever be collected), and even when it is collected, because StreamWriter has no finalizer, the Dispose() method won't be called anyway. As a programming practice I'd like to encourage you keep using 'using'.

What advice? I explicitly stated: "you should really define the scope for the using statement".

I wasn't advising against the use of using at all, I was simply pointing out why a scope is necessary. My entire point was to encourage the correct and explicit use of the using statement.

Apologies if that didn't come across clearly in the original post.

I am new to electronics also.

From what I have read, the analog input can only accept up to 3.3v (5v would be bad?). So if I connect a temp sensor to analog, should I use the 3.3v connection on the same side as the analog input, or use the AREF on the digital io side?


Thanks!

I think it's 5V tolerant but you won't get any useful readings from it at 5V.

You shouldn't need to worry about AREF. The AREF pin is usually connected to the same power supply that you are using to power the device so that the onboard A/D converter has the same frame of reference as the device that's generating the analog signals. If you have a Rev B board and you're powering the device from a Netduino 3.3V pin you shouldn't need to connect the AREF at all because the Netduino has an internal AREF that is on by default. If you have an earlier board then you should also connect the 3.3V line to the AREF.

I get more or less the same result, it might take a bit longer (it is hard to say) but still runs out of memory at aprox the same pace.



I am pretty sure I am getting much more data than what I am consuming -through serialport.read-. I assumed it would be stored in the serial chip's memory and when full it would just drop new data. I'd make sense that, if an internal buffer expands with arriving data it would end up too big... I'll give that a shot and report back

Try hooking the ErrorReceived event on the SerialPort and see if that provides more information. If you are overflowing the internal buffer it will generate an exception with the event type of RXOver.

Hi Albert,

You should always .Close() the stream to ensure that all the writes are completed. Modify the loop to collect a finite number of samples and then close the stream when the loop is done. Flushing will push the buffer to the stream but not the underlying encoder which may still contain data.

See if that cures the problem.

Also, you should really define the scope for the using statement otherwise there's no point in having it:

using (StreamWriter w = new StreamWriter("abc.txt"))
{
    ....
}

With your code structured the way it is, the using statement is redundant anyway, you may as well just declare the StreamWriter without it and let the GC take care of it when it gets disposed at the end of the method.

Hope that helps.

- Adam

Hi demonGeek,

Certainly possible. Nothing supported today, but if the USB host enabled it...

Chris

Thanks Chris. Certainly something to think about.

I'm looking for a good fast way for two or more Netduino's to communicate without the memory overhead of a network stack and without using the I/O pins if possible. USB might be a good way to go.

- Adam