I am starting to suspect that the mystery resistor might be the fix. I am going to send Szymon an email and ask what he used the resistor for (I will also ask what size) I'll let you know what he says.

It's a current limiting resistor for the LCD backlight LED. I used 220Ohm but this might vary depending on what LCD you use.

Chris,
Today I tried to run a very simple example. And following code works fine if I put it at the start of the program:

using (var fs = new FileStream(fileName, FileMode.OpenOrCreate, FileAccess.Write, FileShare.None, 512))
using (var sw = new StreamWriter(fs))
{
    sw.WriteLine("hello from netduino");
    sw.WriteLine("done.");
}

However if I try to iterate all files and display their content I immediately get an OutOfMemoryException. I use the same pattern to dispose FileStream and StreamReader in each iteration but this doesn't help. I only have 5 files with only few bytes of content so I think this is behavior is strange.

string[] files = Directory.GetFiles(@"\SD");
for (int i = 0; i < files.Length; i++)
{
    Debug.Print("filename: " + files[i]);

    using (var fs = new FileStream(files[i], FileMode.Open, FileAccess.Read, FileShare.None, 512))
    using (var sr = new StreamReader(fs))
    {
        Debug.Print("contents: ");
        Debug.Print(sr.ReadLine());
    }
}

Here is the exception:

Failed allocation for 685 blocks, 8220 bytes

Failed allocation for 685 blocks, 8220 bytes

    #### Exception System.OutOfMemoryException - CLR_E_OUT_OF_MEMORY (1) ####
    #### Message: 
    #### System.IO.StreamReader::ReadLine [IP: 000a] ####
    #### FileSystemTest.Program::Main [IP: 012b] ####
A first chance exception of type 'System.OutOfMemoryException' occurred in System.IO.dll
An unhandled exception of type 'System.OutOfMemoryException' occurred in System.IO.dll

Maybe the FileStream buffers dont get released properly ?

Can anyone else try to run this code and see if it works fine on their Netduino Plus?

P.S.

I am able to reproduce the behavior from your second post. Interesting. It does appear like buffers aren't getting cleaned up properly. We'll dig into the .NET MF SD SPI and System.IO code and see what's going on...

It appears to be the ReadLine() function that's causing the issue, interestingly enough... Take that out, and all is well. Curious.

Chris

Chris,
Thanks for looking into this. If you change to use ReadToEnd() the behavior is the same. So this might be memory leak inside the StreamReader itself.

On the memory issues:

1. We haven't found any memory leaks...this is good.
2. The FAT file system was creating up to about 8 2KB caches when data was read. We're tuning this down quite a bit. The memory was reclaimed when the SD card was unmounted--but a total cache size of 2KB is probably more appropriate for this type of device.
3. The StreamReader uses 4KB buffers by default; we're tuning these down to 512 bytes. ReadToEnd() and ReadLine() read data in chunks of 4KB -- and had to create new buffers of at least 8KB whenever they needed to read more data.

We'll post a beta update for the Netduino Plus firmware (v4.1.0.4 beta 1) with these changes by the end of the week.

Chris

Chris,
This is great news. Thanks for fixing this so quickly.

I'm trying to get the SD card working but get an error when closing the StreamWriter.

Here is the code:

var fs = new FileStream(fileName, FileMode.Append, FileAccess.Write, FileShare.None, 512);
var sw = new StreamWriter(fs);
sw.WriteLine("Hello Netduino");
sw.Close();

and this is the error:

    #### Exception System.IO.IOException - CLR_E_FILE_IO (4) ####
    #### Message: 
    #### Microsoft.SPOT.IO.NativeFileStream::Write [IP: 0000] ####
    #### System.IO.FileStream::Write [IP: 002a] ####
    #### System.IO.StreamWriter::Flush [IP: 0021] ####
    #### System.IO.StreamWriter::Dispose [IP: 0016] ####
    #### System.IO.TextWriter::Dispose [IP: 0005] ####
    #### System.IO.StreamWriter::Close [IP: 0004] ####
    #### RoomMonitor.Application::DataLogUpdate [IP: 0090] ####
A first chance exception of type 'System.IO.IOException' occurred in Microsoft.SPOT.IO.dll
    #### Exception System.IO.IOException - 0x00000000 (4) ####
    #### Message: StreamWriter Flush. 
    #### System.IO.StreamWriter::Flush [IP: 002b] ####
    #### System.IO.StreamWriter::Dispose [IP: 0016] ####
    #### System.IO.TextWriter::Dispose [IP: 0005] ####
    #### System.IO.StreamWriter::Close [IP: 0004] ####
    #### RoomMonitor.Application::DataLogUpdate [IP: 0090] ####
A first chance exception of type 'System.IO.IOException' occurred in System.IO.dll

Szymon, does this also happen on a regular Netduino with the v4.1.1 alpha firmware? I know that at least one user reported an issue with the order in which objects were closed/disposed.

Also, what happens if you don't do Append--but do open or create instead?

Chris

Chris,
I tried to close FileStream before StreamWriter and it didn't crash, but nothing was written to the file.
So then I tried to call Flush before closing and this crashes with similar exception.

I also changed FileMode to Open and OpenAndCrate and both don't work too.

But this is part of larger project so maybe there is some other dependency. Tomorrow I will try to test it with simple program.

Chris, please count me in for the Gadgeteer shield!

@segu & @dichotomousgal I'm working on my little tutorial right now, and it should be ready before weekend. I let you know here when it's published. Hope you like it :-)

With my oscilloscope I see that the period is 115.28 uS. So it take 115.28 / 2 = 57.64 uS to change Digital Port state. To slow for OneWire communication.

Hi Pascal,
Great that you confirmed this with the oscilloscope. I tried this myself and came to the same conlusion like you and Pavel. See here http://forums.netdui...ntation-needed/

@Segu,
I'm afraid that right now if you want to use any OneWire devices you will have to use FEZ boards.

Elze Kool has published Sensirion SHT11 classes (SHT1x series sensors differ only in precision).

Oh, thats right. I've seen it before but forgot about it. So I will just check how it works with netduino.

On arduino I used these two temperature sensors:
DS18S20 One Wire Digital Temperature Sensor
SHT15 Humidity and Temperature Sensor

Both are very easy to use and produce good results. Last year I've built several wireless units that were measuring temperature, humidity and light level around the house. I put them in the repurposed AirWick Mini automatic refreshners (so I also got a motion sensor as bounus). Here are some photos: http://cid-4c7ec0c21...tal electronics

Anyway, if anyone here is interested I can look into converting the drivers for these sensors to .NET MF.

I for one would definitely be interested!

Chris,
First I want to finish a little tutorial on using shift registers (74HC595) to extend number of outputs of netduino. I'm using 7 segment LEDs as example (this is actually one of basic tutorials for arduino too). I have all code working so hopefully it will be ready this week. Then I can add the temperature sensor so together it could make a digital termometer with LED display.

Oh, thats right. I've seen it before but forgot about it. So I will just check how it works with netduino.

I tested Elze Kool's SHT11 class and it works great on netduino. It compiled and run without any modifications (besides pin assignments in initialization). So this clearly demonstrates the power of .NET MF code portability (he was using Embedded Master in his demo).

Btw. Elze uses interesting convention to separate input providers from the driver code. I assume he did it in case the sensor would be attached on a different type of bus. For example via an I2C extender chip. I'm curious if you use similar pattern in your code? Are there any other best practices for .NET Micro Framework programming?

Szymon

Waiting for that, will help me a lot

Thanks

segu

I have published the article on my blog: http://forums.netdui...-blinking-leds/

Now I will look into writing the driver for one-wire DS18B20 sensor.

The wikipedia article on 1-wire talks about bridge chips. http://en.wikipedia.org/wiki/1-Wire
For example I found this one DS2482-800 that works over I2C. This might be a viable short term solution.

The same article also mentions that UART ports could be used:

If a parallel port is inconvenient or the operating system interferes with the timing, a UART running at 100 kbit/s with a few resistors and special software can produce and sense acceptable 1-wire pulses.

Does anyone you know how to make this work?

I would love to think up loud and test stuff when there's something read (I got the ENC28J60 myself). For development I have little time near my own projects, and I still lack knowledge on many grounds so there I can't help you out.

For a network stack, what I would love to see is a very simple implementation of socket listeners and outgoing sockets. When that's done I could write all kinds of daemons and networking clients in C#.

I just clicked the subscribe-button of this topic so I can follow the process closely

Hi Stefan,
Thanks for your feedback. Could you elaborate about "very simple implementation of socket listeners and outgoing sockets"? What would you like this APIs to look like? Should we make it close as possible to existing .NET Socket class or we should take different approach.
http://msdn.microsof...ets.socket.aspx

Any scenario in particular that you think we should address?

Best,
-Szymon

Hi all, I think we should start from the bottom and get the basic uIP stack modules running first. Applications can come later as I'm sure they will be useful for testing and as learning examples. But first we should look if any of the bottom level modules have any corresponding functions builtin in the .NET MF already. For example the "Memory block management functions" or "Timer library" I think would find replacements.

Please let me know who want's to joint the project. Just send me your CodePlex account name so I can add you to project members.

Hi, Few months ago there was discussion about 802.15.4 support in .NET MF core and according to the last entry it will be included in the next release after .NET MF 4.1: http://www.netmf.com...62-a93f5d3fc110 Can anyone confirm that .NET MF is in fact working on this? And if so I wonder what will be the relationship to uIP project? Personally I'm very interested in the 6lowPAN standard, but I guess this will require appropriate hardware as well. So if Secret Labs can add member to Netduino family with built in 802.15.4 radio this will be perfect. -Szymon

Hi Pascal, Thank you for detailed explanation. I would really love to have all devices communicate over IP. But as a short term goal with Netduino I agree that we should concentrate on the IPv4 stack first. I hope that you will manage to squeze it take less of Netduino ROM than implementation in current Netduino Plus firmware. Please keep us posted on your progress. -Szymon

Hi, In my third blog post I'm demonstrating how to connect an alpahnumeric 16x2 LCD display to the Netudino. I created a library based on Arduino LiquidCrystal lib and earlier work done by Pavel Bansky. The LCD can be connected both directly (in 4-bit and 8-bit modes) or via a 74HC595 shift register. Here is the blog post: http://geekswithblog...id_crystal.aspx The source code is here: http://cid-4c7ec0c21...l^_20100905.zip

This stuff is hard to debug if you get it wrong

What I did to verify it works correctly, was simply put LEDs to each output of the shift register instead of connecting it to LCD. Then I could step through the code and observe if they are light up in correct pattern. I think the backlight would be easiest to verify. Just make a loop to turn it on/off and see if the apropriate LED will blink.

Hi, The pin assignment looks exactly the same as one that I used. If you look at the diagram on my blog the pins on the LCD are numbered from right to left. Thus as you can see pin 3 is connected to potentiometer to adjust the display contrast. I use output pin 0 on shift register to turn backlight on or off so it should be reserved. Then pins 1,2,3 on shift register are connected to pins 4,5,6 on the display (rs, rw, enable). Finally pins 4 through 7 are connected to pins 11 to 14 on display. Because it uses 4-bit mode display pins 7 to 10 are not connected. I hope this helps. -Szymon

Hi all, Sorry for delayed response. I'm finally back home and could take close photos of my board for anyone who wants to take a look. My board is mounted with components facing the LCD thus I had to reverse the order of pins on the shift register. This is why I added the MSB/LSB option to the provider. In my case I use a 10K pot to adjust the contrast and backlight is turned on/off via the one remaining output of shift register.

I have updated the LCD library to support I2C port expanders. In particular this enables to use the library with the Adafruit's i2c/spi LCD backpack: http://www.adafruit....products_id=292 http://www.ladyada.n...spilcdbackpack/ Of course it already supported the SPI mode but now you can choose I2C as well (however I found that I2C is 2-3 times slower than SPI). Please see new example project HelloWorld_I2C for demonstration on how to use the new provider. This release also incorporates the ShifterSetup as sugested by sweetlilmre in this thread. This enables anyone to configure mapping of the shifter outputs to LCD pins. You can pass your setup via optional parameter to shifter constructors.