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

IMUSerial = new SerialPort("COM1", 9600, Parity.None, 8, StopBits.One);
IMUSerial.DataReceived += new SerialDataReceivedEventHandler(IMUSerial_DataReceived);
IMUSerial.Open();

//write IMU code
Debug.Print("Serial is " + (IMUSerial.IsOpen? "open" : "not opened"));
byte[] pip = System.Text.Encoding.UTF8.GetBytes("r");

Debug.GC(true);
while (true)
{
	IMUSerial.Write(pip, 0, 1);
	Thread.Sleep(100);
	
}

static void IMUSerial_DataReceived(object sender, SerialDataReceivedEventArgs e)
{
	byte[] buffer = new byte[10];
	IMUSerial.Read(buffer, 0, 10);
	String message = new String(System.Text.Encoding.UTF8.GetChars(buffer));
	Debug.Print(message);
}

What happens if you move the buffer array up to the class level rather than creating a new instance each time the event fires?

With 4.1.2 already offering early USB client support, will USB communication between two Netduino's become a possibility?

Perhaps using a USB Host Shield like this one.

Thanks.

- Adam

Confirmed. I see the same behaviour in NETMF but not in the full framework. -0.1 to -0.9 are parsed as positive values.

The garbage collector in .NET Micro Framework is a simple mark-and-sweep.

So do you think that it is a good strategy to avoid long-term objects as much as possible in NETMF code?

Just came across this post by JonnyBoats which is relevant to the discussion.

If the Micro Framework GC works in the same way as the Compact Framework (only one-generation GC), then your choice of design pattern may well have an impact on the GC and therefore overall performance of the application. Something like MVC with long-term objects may not provide the best performance.

Of course this is going to vary from one application to the next - if you're not pushing the processing/memory limits of the device then GC probably isn't going to be a big deal anyway. Just something else to consider ;-)

- Adam

Interesting video. Given that the Compact Framework only implements one-generation GC, I wouldn't imagine that the Micro Framework is any different. Which leads to an equally interesting observation: In a one-generation GC, every live object on the heap must be considered during each garbage collection. Therefore, the more long-term objects in a NETMF application, the slower the GC cycle. Reducing the number of long-term objects should improve overall GC performance. If correct, that observation will certainly have a bearing on the way I code my NETMF apps. - Adam

Am I nuts to head this route in the .NETMF? I'd love to find some good reading on strengths and weaknesses of the .NETFM

There's nothing wrong with using design patterns but I would caution that you should be very aware of the memory restrictions imposed by this type of platform.

I have used MVC to great effect in regular Windows GUI apps, it really makes the code manageable but then I'm not particularly worried about the size of the executable in that environment.

If the framework brings a lot of extra overhead - either in processing time or memory footprint - you will notice it a lot sooner on the Netduino and then you may be forced to decide between form and function.

Also, as Corey mentioned, some of the things that can make a design pattern a joy to use are missing from NETMF - generics is a good example.

- Adam

And I am right in assuming that the FLASH memory access is automatic ? or do we need to do some special access to read/write to it ?

Yes, that's right (assuming your SD Card is compatible). Just prefix the path with \SD like this:

File.OpenRead(@"\SD\myfile.txt");

Hi Michel,

There are a lot of ways to do file I/O depending on what you need to do. Here's some code that I'm using to read/write to the SD card on the Netduino:

using System.IO;

public byte[] Read(string fileName)
{
	byte[] buffer;
	using (FileStream file = File.OpenRead(fileName))
	{
		buffer = new byte[file.Length];
		int bytesToRead = (int)file.Length;
		int bytesRead = 0;

		while (bytesToRead > 0)
			if (file.Read(buffer, bytesRead, bytesToRead) == 0) break;

		file.Close();
	}

	return (buffer);
}

public void Write(string fileName, byte[] data)
{
	using (FileStream file = File.Open(fileName, FileMode.Append))
	{
		file.Write(data, 0, data.Length);
		file.Flush();
		file.Close();
	}
}

The only word of warning would be that the read buffer in the above code could overflow on a platform with limited memory such as the Netduino. The code really needs to check the file size before allocating the buffer and then chunk the data if necessary.

Conversion.ErrorToString()

I Think I can replace the last one with a catch (Exception e) in a try catch and using e.Message ... I am right ?

Yes, you're right, use a try...catch and parse the exception like this:

try
{
	// something...
}
catch (IOException ex)
{
	// Catch a specific type of exception
	Debug.Print(ex.ToString());
}
catch (Exception ex)
{
	// Catch any exception
	Debug.Print(ex.ToString());
}
finally
{
	// clean up here, if necsessary
}

Hope that helps.

- Adam

Ryan,

The code you posted to create the port should work. I tried it and it works for me - at least I was able to create the port and execute the DisableInterrupt call.

So it seems likely that some of your other code might be affecting this code. I would suggest much the same thing as vernarim: Take out as much other code as possible to prove that you can create the port and then gradually add back in the other code until you discover what's causing this code to break. Then, if the answer still isn't clear, you can post all the relevant code and get some more help.

- Adam

There doesn't seem to be support for multiple SPI devices on the same SPI interface in this framework.
It is possible to do your own CS (chip select) managing, but i prefer the way the SPI class manages this.
So i've made a little factory for making it easy to switch between spi devices.

The SPI class represents the master device (the Netduino).

Each slave device on the SPI bus is represented by a separate SPI.Configuration and since you can only have one active device at a time, you simply need to switch the configuration when you want to select a different device:

SPI.Configuration slaveDevice1 = new SPI.Configuration(Pins.GPIO_PIN_D10, false, 0, 0, true, true, 500, SPI_Devices.SPI1);
SPI.Configuration slaveDevice2 = new SPI.Configuration(Pins.GPIO_PIN_D9, false, 0, 0, true, true, 500, SPI_Devices.SPI1);

SPI spi = new SPI(slaveDevice1);

spi.Config = slaveDevice2;

I think that the NETMF terminology is a bit confusing in this regard. I would have preferred something like SPI.SlaveConfiguration which makes the relationship a bit clearer. It would also have been nice to have a Configuration collection within the SPI class itself.

- Adam

I just started to learn .Net (I know so many languages ... and yeah, I know, late learning) so give me time.

If I wait long enough, we probably could have it in VB.Net on .Net MF lol (I'm a VB fanatic, so easy to program) but I'll try it in C# ...

One word of advice, since you're just starting out with .NET - make sure you develop the code in a .NETMF (Netduino) project and not a regular .NET project. NETMF is a subset of the full framework and I'm continually running into things that I can do in one but not the other.

VB.NET and C#.NET are much more closely related than VB is to VB.NET. I found the transition from VB to VB.NET to be hard work mostly because of the effort required to learn the framework. The syntactic differences between all three are not particularly significant.

- Adam

I'd be interested in that - I don't know anything about it but I'm slowly progressing towards building an autonomous robot and it sounds like this could be really useful. - Adam

I know this is an old thread but I came across it just now as I was trying to get RS232 up and running on my Netduino.

If you're looking for a really cheap board to do the conversion from TTL (3V) to RS232 you could try this one from Futurlec which is only $4.90 and is working fine with my Netduino.

- Adam

I use RC grade Lipos/NiMhs.

Check this sorta stuff out: http://www.hobbyking...?idProduct=8935

Thanks Chris.

Looks like a good way to go.

I was looking over the firmware source briefly and I didn't see any obvious reasons why it couldn't be modified to work the way you want. (famous last words.. to be clear I only looked at the firmware for about 30 seconds)

As for why the methods are there in the first place, it's a sad casualty of the inheritance hierarchy: TristatePort inherits from OutputPort which in turn inherits from Port which in turn inherits from NativeEventDispatcher, which introduces the event.

Well, I'm giving up on this one. I can make it work with interrupts by using two ports as you suggested but I don't think it's worth the effort. It's simpler just to use one TristatePort for everything and perhaps run it on its own thread when I want to read the sensor.

Personally I think it makes sense to have a working interrupt on a TriState port, I find events more intuitive for this kind of thing.

Thanks for your help.

- Adam

OK, so this is a real noob question, what terminal emulator (free) are people using on Windows 7 64 bit to talk to the Netduino now that Hyperterm no longer comes with Windows?

TeraTerm on Windows7 x64.

Old and ugly but still works great. A bit like me really.

- Adam

If you want to use floating point division, at least one operand as to be a float.

Tecchie is absolutely correct. I should have mentioned that I modified your original code to explicitly type the variables.

Personally I dislike using var unless there's no other choice. I prefer to make my code as explicit as possible because it leaves less room for mistakes.

As far as the AREF is concerned, I don't know how the Fez Panda works but the Netduino has an internal AREF (on by default) and an external AREF pin. It seemed to me that I got better results using the external AREF but I didn't really test that much so it might not be the case. Either way, you need to understand how the Fez Panda's AREF works otherwise the A/D conversion will be off.

- Adam

I'm not 100% sure, but I think this is not supported. I think you'll have to tie two pins together, configuring one as a TriStatePort and the other as an InterruptPort. You'll (hopefully) see two pulses on the InterruptPort: your own outgoing pulse and then later the reply from the PING)))

Hey Corey,

That's what I was thinking too but I was hoping it wouldn't be the case - it seems like a waste of resources to use two pins.

I don't understand why there's an OnInterrupt event on the TristatePort if you can't use it. It makes sense that event wouldn't fire unless the port was set for input but it seems I can't hook the event at all.

The obvious option is to abandon interrupts and just go with the TristatePort for everything but an interrupt seems tailor-made for this type of operation...

- Adam

I'm just starting to think about powering my projects from batteries.

I got this 2000mAh Polymer Lithium Ion Battery and this converter so I think I have the Netduino and sensors covered but I'm wondering about devices, such as motors, that require a bit more power.

I know there are a ton of options out there but I wanted to find out what people here are using and what works well.

Thanks in advance.

- Adam