Given that there is no Reflection.Serialize in the stock firmware, or BitConverter classes in MF period, what's the best way to convert value types to arrays of bytes and vice versa?

I posted in the other thread, but I might as well post here too in case someone comes across it. The seeedstudio sd card shield works fine with the new firmware

I can confirm that I can run the sample sd card code (provided in the other thread) on the seeedstudio sd card shield. I tested it with the switch in the "3.3v" position.

Haven't had much chance to try anything beyond the sample code though.

I was unable to debug this firmware on my mac running parallels 5 + windows 7 64bit. When I tried to debug it would just reboot the netduino and stop. I had this issue with the shipped firmware, as well as the beta firmware, so it's not new. I'll just stick to pure windows for now i guess.

I have a microSD card shield from Sparkfun (http://www.sparkfun....roducts_id=9802) and a Sandisk 8GB microSD card and the code shown by Bob doesn't appear to work.

No, it doesn't support SDHC, so nothing over 2gb.

MicroSD is tricky, I've been reading the specs lately. All the other SD standards mandate SPI support, but Micro does not, so it might be hit or miss with getting micro cards working. Probably going to vary by make/model.

Awesome, I will try it out tonight and post the results. Based on the arduino code that's availible for it D10 should be the right pin for chip select.

Specifically I was interested in looking at what's going on with the spi/mmc/sd/fat drivers, which I know aren't ready for release, but I've been tinkering with my own implementation and I wanted to compare. I just wanted to raise the question and see if there were any plans to make it public.

Where is the source repository for the netduino firmware/tools etc? Is it out there somewhere and I'm just missing it? I know that source downloads for the official releases are made available on the website, but most open source projects I've worked with make their repository publicly read-able and browse-able for looking at history etc.

Using is quite nice to make sure you don't forget to call Dispose on anything that implements the IDisposable interface, but beyond that it isn't much different.

They're only the same if there's no exceptions and nothing calls "return"

With "using", if an exception occurs or if something inside the "using" calls "return", then the serial port would still be disposed properly.
if you do open.....dispose, and an exception occurs between them, it would leave the port active until it went out of scope and got gc'd (an unknown amount of time).

That's why "using" is considered the best practice instead of calling Dispose manually.

That said, I don't think this difference is what's causing your problem.

Ok I feel dumb now. I changed it over to Com2 and it works fine. It seems like maybe I messed up on some soldering then?

Here's the code I was using anyway (even though I got it working)

public static void Main()
    	{
        	SerialPort xbee = new SerialPort(SerialPorts.COM2,9600,Parity.None,8,StopBits.One);
        	xbee.Open();
        	xbee.DataReceived += new SerialDataReceivedEventHandler(XBeeDataReceived);

        	while (true)
        	{
            	string output = "Hello " + DateTime.Now.Ticks;
            	byte[] bytes = System.Text.Encoding.UTF8.GetBytes(output);
            	xbee.Write(bytes, 0, bytes.Length);
            	xbee.Flush();
            	Thread.Sleep(5000);
        	}

    	}

    	static void XBeeDataReceived(object sender, SerialDataReceivedEventArgs e)
    	{
        	int bytesReceived = ((SerialPort)sender).BytesToRead;
        	byte[] bytes = new byte[bytesReceived];
        	((SerialPort)sender).Read(bytes, 0, bytes.Length);
        	string received = new string(System.Text.Encoding.UTF8.GetChars(bytes));
        	Debug.Print(received);
    	}

I know nothing about that scope, but I was on the seeedstudio website the other day and it caught my eye.
http://www.seeedstud...l?cPath=104_108

It looks to me like the one you linked to on ebay is the older version. If it was me I'd probably try to get the newer one when it comes back in stock. If you do end up picking it up I'd be curious to hear feedback, it seems like a steal.

Are you using an XBee shield which "steps down" the voltage from 5V to 3.3V for the XBee module? If so, does it do a true 3.3V conversion--or is it just cutting the voltage? It's possible that the Netduino is getting 5V signals FROM the XBee module but that the accessory board is cutting the voltage on 3.3V signals coming from the Netduino.

If you can let us know which XBee hardware you're using (module and inteface/shield), that would be really helpful. We're making a list of compatible accessories...and it would be great to show which boards are designed to work with 3.3V signals...

Sorry, I meant to include the link on my first post (I even had it in the clipboard).
This is the kit for the xbee I'm using

http://www.sparkfun....roducts_id=9897

If data is getting from the XBee to the Netduino, there's only a very small chance that data is not getting from the Netduino to the XBee because of a hardware problem.

That's kind of what I thought. It seemed weird to me that it was working 1 way but not the other. I was going to give this lib a try thinking maybe I was missing something with the serial port commands, but it sounds like it ought to be working.

I will post my code when I get home tonight, although it's pretty trivial.

I just got the sparkfun xbee wireless kit and got it all soldered up and plugged in. I plugged in the xbee explorer to the PC, installed the x-ctu software from digi. I initialize the serial port in my application to 9600 speed, 8 bits, no parity, 1 stop bit , open the port, and wire up the DataReceived event. After that I put it into a loop where it just writes and flushes "Hello world" every 5 seconds. If i open the x-ctu terminal on my PC and type, it I can see the lights blinking on the xbee's, and the DataReceived event fires on the netduino, and a call to read returns my bytes. The problem i'm having is that "Hello world" isn't coming out on the PC end of things. I've tried flushing etc, but nothing. Could I possibly have a loose solder joint on the tx pin for the xbee shield? What's the best way to go about troubleshooting?

Duh, I was counting pins the wrong direction. For some reason I was thinking it wasn't plugging into 11-13 (so I didn't think it was spi). Thanks for the clarification. I'm starting to get the hang of this.

Nevermind I think I understand what they're saying now. You can power it either by the 3.3 (on if the netduino is on) or by turning on the GPIO on Pin 9. The communication is done via serial then right?

Wow, thanks for the quick response.

It sounds like I'd better just chill out and wait for the experts.

As for if it's 3.3/5v I'm not really sure. Like I said the documentation is somewhat lacking. There is a switch on it which says I can select 3.3 or IO port power, so it sounds like it's 3.3. The io port it's talking about is pin 9 so it looks like it's a PWM device? (Haven't gotten that far in the book yet:) )

I got my Netduino last week and have been playing around with it while reading through "Expert .Net Micro Framework". I'm an experienced .Net developer but very new to MF and embedded systems in general.

I got the SD Card Shield from MakerShed and I'm just trying to do some simple file IO.

When I try to enumerate volumes and file systems from Microsoft.SPOT.IO it doesn't find anything. I'm assuming this is because Netduino is missing a driver. I started looking at the Arduino Fat code to see about porting it, but I'm really not sure where to start. Honestly I'm not even sure how this shield works, the documentation for it leaves quite a bit to be desired. "You can select 3.3V or IO port power supply with the switch on board in order to work with different library."

Can anyone point me in the direction of some good resources? Am I just making this too hard (hopefully)?