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 the Salae too, it works very well and I like the user interface.

Anyone got any thoughts on the Parallax PropScope?

It's not particularly cheap at $200 so would it be better to simply spend the extra on a dedicated scope instead?

- Adam

I'm playing with I2C and a serial EEPROM (24LC32A) on my N+.

I have it working but I've run into a couple of issues that - I think - require more granular I2C control than I can get through the I2CDevice in Microsoft.SPOT.Hardware.

Here are a couple of examples from the 24LC32A datasheet:

• The datasheet describes an 'Acknowledge Polling Flow' which allows the code to loop while waiting for a write operation on the device to complete. You create a loop to send a control byte to the device and then parse the ACK looking for a zero at which point the device is ready to accept a new operation.
  
• The 'Random Read Sequence' which allows a byte to be read from a specified address requires a control sequence that includes a start signal (high to low transition on the SDA line while SCL is high) in the middle like this: START + CONTROL-BYTE + ADDR-HI + ADDR-LO + START + CONTROL-BYTE...STOP

Since the I2CDevice class seems to wrap everything up in an I2CTransaction, it seems that I don't have control over when the start signal gets sent or even the ability to parse the ACK.

Any thoughts/suggestions would be most welcome.

Having got this to work I thought it might be useful to post the test code I'm using so that others might benefit from it too:

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

The fix does exactly that (I know this for sure, because I have developed it and I have two working 24LCxx EEPROMs right in front of me ;- ). In order to generate the above sequence, call CreateReadTransaction(..., address, 2) from Chris' example. The address will be written onto the bus as ADDR-HI and ADDR-LO.


Could you please share the logic analyzer output? (Please note that Start condition is just High -> Low transition on SDA while SCL is High, it is not a bit with duration of the clock signal period).

Yeah, sorry CW2 - I misunderstood the internalAddress param on CreateReadTransaction (I thought it was the device address) so the extra Start wasn't getting generated. I fixed up the code and now it works perfectly - the logic analyzer output looks exactly like the datasheet.

Many thanks for your help - I still have a lot to learn but getting great help like this is always appreciated!

You'd need 4.1.1 alpha firmware for that (Repeated Start condition support).

Thanks CW2, I have 4.1.1 firmware and the code from this post.

Please correct me if I'm wrong here but I don't think that's what I need. The repeated start condition fix seems to just be adding extra bytes immediately after the initial start signal. I don't see how that lets me generate this control sequence:

START + CONTROL-BYTE + ADDR-HI + ADDR-LO + START + CONTROL-BYTE...STOP

The problem is the (highlighted) start signal in the middle of the sequence - there's no preceding stop so I have to be able to generate a start signal in the middle of the control sequence (transaction). The relevant information from the datasheet is as follows:

To perform a random read operation, first the word address must be set. This is done by sending the word address to the 24LC32A as part of a write operation (R/W bit set to zero). After the word address is sent, the master generates a start condition following the acknowledge. This terminates the write operation, but not before the internal address pointer is set. Then the master issues the control byte again but with the R/W bit set to a one. The 24LC32A will then issue an acknowledge and transmit the 8-bit data word.

Here's the diagram from the datasheet:



I'm an experienced programmer but new to the whole electronics thing so I might have this all wrong - I just got my N+ and wanted to play with I2C; this EEPROM was the only I2C device I had lying around...

When I tested with the 4.1.1 firmware and revised I2C Transaction code I could see the extra bytes on the logic analyzer but I didn't see any extra start signals being generated.

demonGeek,

The "internalAddress" from the code you downloaded is the key here. Pass in the address [((0x100 * addressHigh) + addressLow), 2 bytes] as the internalAddress parameter and you should be good to go.

Chris

Thanks Chris, that was the bit I was missing!

I totally misunderstood what that address was - I thought it was the device address.

It's working fine now.

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

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?

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 believe that 3.3V is the maximum on the analog pins so 5V is going to max out the reading at 1023 all the time and skew the results.

When I tested at 3.3V I was getting much better data but there was still a wide variance so I hooked up an external AREF (connect the 3.3V line to the AREF pin) and switched on the external AREF in the code. I also averaged out the result and found that after a dozen or so samples it stabilized at close to the right value. Here's the code:

// Rev B boards use internal AREF by default: switch to external AREF
OutputPort arefSelect = new OutputPort((Cpu.Pin)56, false);

AnalogInput A0 = new AnalogInput(Pins.GPIO_PIN_A0);

const float vIn = 3.3F;
const float rKnown = 10000;
float rTotal = 0;
int samples = 0;

while (true)
{
	float vRead = ((vIn / 1024) * (float)A0.Read());
	rTotal += (rKnown * ((vIn / vRead) - 1));
	samples++;
	Debug.Print("Resistance: " + System.Math.Round(rTotal / samples));
	Thread.Sleep(1000);
}

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

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

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

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.

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");

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

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

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

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

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]}