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

Anyone here have any experience with magnetometers?

Which one(s) have you used? What interface? How easy is it to work with? How well did the tilt-compensation (if any) work?

I'm not very experienced with them but I did just get one working with my Netduino so I thought I'd share that with you ;-)

I've had a Sure Electronics Dual-axis Magnetic Sensor Module (DC-SS503) sitting around for a while and wanted to experiment with the I²C interface. It turns out to be a really simple interface and I'd recommend it not just because it's simple but also because you can chain a bunch of I²C devices on a bus which avoids using all your Netduino pins driving multiple sensors.

Anyway, like I said, I'm not an expert but I hooked it up and got some data back which changes as I rotate the device in the X or Y axes. What that data means is my next task to figure out.

This is the test code I used to initiate a measurement and read the results:

byte[] buffer = new byte[5];
int bytesWritten = 0;

// Create the I2C device (device address: 0x30, clock rate: 400Khz)
I2CDevice.Configuration i2cConfig = new I2CDevice.Configuration(0x30, 400);
I2CDevice device = new I2CDevice(i2cConfig);

// Send command to take measurements (0x00) followed by (0x01)
I2CDevice.I2CTransaction[] writeTx = new I2CDevice.I2CTransaction[] { I2CDevice.CreateWriteTransaction(new byte[] { 0x00, 0x01 }) };
bytesWritten = device.Execute(writeTx, 1000);

// Pause for (minimum) 5ms as device completes data acquisition
Thread.Sleep(10);

// Read the 5-byte response from the device
I2CDevice.I2CTransaction[] readTx = new I2CDevice.I2CTransaction[] { I2CDevice.CreateReadTransaction(buffer) };
bytesWritten = device.Execute(readTx, 1000);

Debug.Print("Internal Register: " + buffer[0].ToString());
Debug.Print("X-Axis: " + ((buffer[1] * 0x100) + buffer[2]).ToString());
Debug.Print("Y-Axis: " + ((buffer[3] * 0x100) + buffer[4]).ToString());

Make sure you have the 4.1.1 ALPHA 7 firmware.

Hope that helps.

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

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.

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

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

Have you thought about using a queue and a timer?

Have a class which holds the data and the timer. Provide an add method which adds data to the queue and starts the timer. The timer event takes data out of the queue and writes the data. If the queue is not empty it restarts the 80ms timer.

Regards,
Mark

Thanks Mark, that would certainly work.

I've also been wondering about some kind of thread blocking mechanism.

The Sparkfun serial backpack has an on-board buffer and the timing issues seem to be centred around marshalling the data to that buffer.

I'll have to play with it some more.

- Adam

I believe the problem you are seeing is because the code doesn't actually do what you want it to do. You want an 80 ms delay between writes, however in this code the writes can all end up stacked on top of each other. If this doesn't make sense, consider this example:

You're absolutely right, that's exactly what's happening.

Thanks for the help.

- Adam

I'm playing with some code to drive a Sparkfun Serial LCD and ran into some timing issues which caused a garbled display unless I put an 80ms delay (Thread.Sleep) between each write operation.

This was fine for testing but with the delay on the main thread it slows everything down whenever I write to the LCD. So I thought it might be a good idea to put the write operation on its own thread like this:

private void Write(byte[] data)
{
	new Thread(delegate { this._Write(data); }).Start();
}

private void _Write(byte[] data)
{
	this.port.Write(data, 0, data.Length);
	Thread.Sleep(80);
}

This code works fine as long as the debugger is attached but as soon as I deploy and reset the Netduino, the display ceases to function. The code itself is still operational (no exceptions, as far as I can tell) but the display thread doesn't seem to be doing anything. If I remove the threading and write to the device directly everything is fine again.

Is this expected behaviour? Is there some better way of doing this that I don't know about?

- Adam

_{[N+ firmware v4.1.1.0 ALPHA7]}

I have used the i2cmaster.h when i was working with arduino. Now i try to convert it to C# but i dont understand it.
Can some pleas help me convert this code to c#.

Having just figured out I²C myself, I can tell you that you don't have the same (low) level of control over I²C in C# (NETMF). The I2CTransaction wraps the complexities of the protocol and handles the start/stop/acks for you.

Here's some basic test code that I used to read/write a 24LC32A serial EEPROM:

public static void Main()
{
	byte[] buffer = new byte[1];
	int bytesWritten = 0;

	// Create the I2C device (device address: 0x54, clock rate: 50Khz)
	I2CDevice.Configuration i2cConfig = new I2CDevice.Configuration(0x54, 50);
	I2CDevice eeprom = new I2CDevice(i2cConfig);
			
	// Write the letter 'A' (0x41) to address 0x0000 on the eeprom
	I2CDevice.I2CTransaction[] writeTx = new I2CDevice.I2CTransaction[] { CreateWriteTransaction(new byte[] { 0x00, 0x00, 0x41 }, 0, 0) };
	bytesWritten = eeprom.Execute(writeTx, 1000);

	// Read the byte at address 0x0000 on the eeprom
	I2CDevice.I2CTransaction[]  readTx = new I2CDevice.I2CTransaction[] { CreateReadTransaction(buffer, 0x0000, 2) };
	do { bytesWritten = eeprom.Execute(readTx, 1000); } while (bytesWritten == 0);

	Debug.Print(buffer[0].ToString());

	Thread.Sleep(Timeout.Infinite);
}

#region see: http://forums.netduino.com/index.php?/topic/944-i2c-internaladdress-repeated-start-bit-support/

static I2CDevice.I2CWriteTransaction CreateWriteTransaction(byte[] buffer, uint internalAddress, byte internalAddressSize)
{
	I2CDevice.I2CWriteTransaction writeTransaction = I2CDevice.CreateWriteTransaction(buffer);
	Type writeTransactionType = typeof(I2CDevice.I2CWriteTransaction);

	FieldInfo fieldInfo = writeTransactionType.GetField("Custom_InternalAddress", BindingFlags.NonPublic | BindingFlags.Instance);
	fieldInfo.SetValue(writeTransaction, internalAddress);

	fieldInfo = writeTransactionType.GetField("Custom_InternalAddressSize", BindingFlags.NonPublic | BindingFlags.Instance);
	fieldInfo.SetValue(writeTransaction, internalAddressSize);

	return writeTransaction;
}

static I2CDevice.I2CReadTransaction CreateReadTransaction(byte[] buffer, uint internalAddress, byte internalAddressSize)
{
	I2CDevice.I2CReadTransaction readTransaction = I2CDevice.CreateReadTransaction(buffer);
	Type readTransactionType = typeof(I2CDevice.I2CReadTransaction);

	FieldInfo fieldInfo = readTransactionType.GetField("Custom_InternalAddress", BindingFlags.NonPublic | BindingFlags.Instance);
	fieldInfo.SetValue(readTransaction, internalAddress);

	fieldInfo = readTransactionType.GetField("Custom_InternalAddressSize", BindingFlags.NonPublic | BindingFlags.Instance);
	fieldInfo.SetValue(readTransaction, internalAddressSize);

	return readTransaction;
}

#endregion

Make sure you have the 4.1.1 ALPHA 7 firmware.

Hope that helps.

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.

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?

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

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

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

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

This code works as I can see data being written to the controller using a spi bus monitor

This is the only way I can get the spi to work. The code will not work if the SPI.Configuration is placed like this SPI.Configuration SPIConfig = new SPI.Configuration. It creates the exception as you described above. I don't understand why

Hope this helps

George

Hi George

You're right, that makes no sense but I tried it anyway: still doesn't work for me though.

I think this exception is a catch-all for just about any unexpected condition and as such isn't very useful.

If you have SPI working with that code then I think I can rule out my code which leaves either the connections or the device itself. Unfortunately I don't have another SPI device to test with at the moment, I think I'll have to order something and then test against that.

Thanks for your help.

- Adam

I just want to instantiate an SPI object but I keep getting this:

An unhandled exception of type 'System.InvalidOperationException' occurred in Microsoft.SPOT.Hardware.dll

Here's the code:

SPI.Configuration spiConfig = new SPI.Configuration(Pins.GPIO_PIN_D8, false, 250, 250, true, true, 1000, SPI.SPI_module.SPI1);
SPI spi = new SPI(spiConfig);

What am I doing wrong?

 
EDIT:
I've been looking at this for a while now and I'm beginning to wonder if this error might indicate that there's a problem with the connection to the SPI device (or the device itself). The device is this flash memory board connected as follows:

CS# <-----> D8
SCK <-----> D13
SDI <-----> D12
SDO <-----> D11


I've also tried (unsuccessfully) connecting the BUSY# pin on the board to D7 and then specifying that in the other constructor overload:

SPI.Configuration spiConfig = new SPI.Configuration(Pins.GPIO_PIN_D8, false, 250, 250, true, true, 1000, SPI.SPI_module.SPI1, Pins.GPIO_PIN_D7, false);
SPI spi = new SPI(spiConfig);

_{[N+ firmware v4.1.1.0 ALPHA7]}

**bump** Anyone have any ideas? I'm completely stuck on this one - I don't know if it's the code, the connections or the device itself. Any thoughts would be appreciated.

Here is another idea to try. Since spi is basically a shift register, what you write you should be able to read. You can test the spi controller
and your code by connecting MOSI and MISO (11 and 12)on the Netduino+ together. This removes the slave device from the loop. The clock line and the device
won't matter, but disconnect them from the device anyway. Try this code:

George

Thank you very much! Your loopback idea put me on the right track to solve the problem.

I had been playing with a motor controller last week which was using a static singleton class that locked D12 before my SPI code ran. When I first tried your code it didn't work so out of desperation I created a completely new project and suddenly the code started working. After that it was just a process of elimination to find the offending code.

- Adam

I'm playing with a Parallax Ping))) Sensor and was wondering what would be the best way to interface it to my Netduino.

I've found some code samples that are based on a TriStatePort but it seems to me that an InterruptPort might be a better way of doing things. The trouble is that I'm not very experienced with either of those types of port so I'm looking for some help and advice.

I tried to set an interrupt event handler on a Tristate port like this:

TristatePort tristatePort.OnInterrupt += new NativeEventHandler(Port_OnInterrupt);

but that produces a System.InvalidOperationException. No idea why...

I then tried creating an Interrupt port and event handler which seems to be fine but I don't see how to send the trigger pulse in that situation so the interrupt never occurs.

Thanks.

- Adam

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

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 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'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