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.

OK, I finally got this working. As usual it was stupidity on my part. When I reversed the wiring between the shift register & the lcd I missed Qa (pin 15 on the 74HC595). If anyone is interested I have attached an updated wiring diagram (I am new to fritzing so please forgive the quality). Thanks everyone for your help. --Jim

Great news that it works for you and nice work on documenting the diagram!

Thanks,
-Szymon

Ah so that's you! We should chat some day I made my own LCD Transfer Provider based on your class as concept at the moment. I did this so it can use multiple 74HC595 IC's with the same latch pin. With my provider it's also possible to link multiple LCD's to the same SPI-pins as well If you like, I can send you my code, so you can take a look at it?

That would be great extension! If you'd like to join the project just send me your login at CodePlex.

Thanks!
-Szymon

Hi Rob, I wrote a library that simplifies connecting with various types of LCDs. You can read about it on my blog http://geekswithblog...id_crystal.aspx The library is hosted on CodePlex: http://microliquidcr...l.codeplex.com/

Chris, please count me in for the Gadgeteer shield!

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

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

I unfortunately haven't been able to test out the IO Sample stuff because my Router API Xbee crapped out on me... Got a thread started at on the Digi support forum, but I don't know how long it will take (if at all) for someone to help me out. I can't even reload firmware at this point and may be forced to purchase some new Xbees :-\ Not good.

This happened to me as well during one of the firmware updates. Fortunatelly I found that there is a way to do factory reset on XBee.
First you need to get X-CTU to prompt you for additional action, and then short couple of pins on XBee. Read here for instructions:
http://forum.sparkfu...ad0f7115f82a106
(find replies from artcar12 and heathkit).

Yes, you are right that MF Toolkit implementation is more comprehensive. However as you pointed most people would only use the common functions most of the time. I think at minimum this includes: - initialize xbee module - read module configuration - discover other nodes in network (in order to map node id's to short address) - send and received binary data For this I think Grommet does a good job. I especially like that the API is focused on executing these higher level operations rather than exposing the entire XBee API. When I started exploring MF Toolkit it was hard to guess how I'm supposed to use it to execute these functions. IMO if we want the library simple to use it should hide the technical details of XBee protocol and instead expose easy to use functions. Another reason is the size. I plan to use Netduino Plus as a gateway passing web requests to other nodes connected via XBee. Because Netduino Plus has limited memory it is important to make the libraries as small as possible. I did a quick comparision of the PE files (not the dlls) and Grommet is about 4 times smaller then Grommet. Unfortunatelly MF doesn't trim the code that is not used by application during deploymnet so we should minimize the code ourselves. I have managed to trim the Grommet library to about 9K (the PE file again). Right now I'm reviewing the code in Grommet. One think that I liked in particular in MF toolkit was the usage of ByteReader\ByteWriter classes. This greatly streamlines the code for parsing and serializing the API Frames. Right now I'm trying to bring them to Grommet replacing calls like Utility.InsertValueIntoArray or Utility.CombineArrays. This also replaces calls to BigEndianConverter.

I like the library - its alot more thorough (albeit more heavy) implementation of the XBee API. The method the Grommet library uses for reading in frames (use of a FrameBuilder class) does feel more elegant and is a little easier to follow for me than the code in the XBee.cs "ReceiveData" class, but your implementation seems like it should work really great. I might have to give it a try (and perhaps make a switch). It's actually very similar to the classes I wrote in VB a year or so ago...

Just to make it clear: I'm not the author of MFToolkit - it was written a while ago by Michael Schwarz, and he recently updated it to MF 4.1. Michael is active on this forum so I hope he can join our conversation.

What I was suggesting is to take a look at both XBee libraries and maybe try to decide which one is more complete, and see if we can merge them and move forward as single code base. I will be happy to help with this effort. For now I will look at the FrameBuilder class in Grommet and see if this can be migrated to MFToolkit. What do you mean by seaing that MFToolkit implementation is "more heavy" ?

Thanks,
-Szymon

GDSever, I've seen the Grommet project, but decided to use the XBee classes from MFToolkit (http://mftoolkit.codeplex.com/) because I also want to use the HTTP server implementation. Did you see it as well? I'm curious if you have compared them and it there is any reason to choose one over another. If there is anything missing I guess it would be better to pull the resources together and maintain single library rather than split into two. I will give Gromet another look too. Thanks, -Szymon

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.

Edit: The strange things appearing seems to be intermittent, it happened when I first turned it on this morning. Here is a picture...

Spike,
Looking at the photo I can't see exactly how you connected wires to the LCD. Did you solder them directly or added header pins?

In any case make sure they are connected firmly. If any of the wires gets disconnected the LCD can't interpret the commands and thus you might get the garbage flickering on screen as you are seeing now.

Well I keep finding cool stuff and get sidetracked from current projects, but this has gone to the top of my list.

http://www.adafruit....products_id=285

Can I use that with the netduino? It would be extremely awesome if I could stick it to some clothing and make cool paterns.

Yes, but you will need externall power supply, because most of these RGB strips require 12V. And to control brightness of individual RGB channels the LED driver chip will be best. There is already library for the Allegro A6281 based boards:

http://forums.netdui...-a6281-library/

Secondly the Fritzing wiring diagram on Szymon's blog page is slightly incorrect w.r.t. the SPI port:

SHCP = PIN 13 (not 12)
STCP = PIN 10
DS = PIN 11

Thanks for spoting this. In earlier version I sent data to shift register all in managed code, but later I switched to hardware SPI and thus had to move clock input pin to SPCK (pin 13).

Edit: I have updated the diagram in the blog post.

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

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.

Hi Syzmon,

Building off what Chris said, you might want to compile your own HTTP library. I highly suggest you use code from the .NET MF Toolkit (http://mftoolkit.codeplex.com/). Michael Schwarz is the creator of that project. The .NET MF Toolkit contains a library for HTTP. Download the latest changeset from the source code, change the project references from .NET MF 3.0 to version .NET MF 4.1, and lastly compile. You will be using the dll's built from the MicroHttp project.

You can easily remove classes and what not from the project that you won't use to reduce the amount of space the assemblies take up.

Hi,
I already started triming down the MicroHTTP project. Initially it consumed 37KB because it also used the security libraries, but after commenting out SSL support and removing few other classes I got it down to 26K.

However this implementation is targeting scenario where .NET MF device acts as HTTP server (accept requests and sends responses). For current project I need it to act as a client and connect to remote HTTP server. So I was planing to add these functions to the library.

Chris mentionsed another way - to take the existing System.Http.dll appart and try to trim it down (I forgot it has Appache license and we can do this). If I can get it down to 30KB it should be fine.

-Szymon

Hi,
I'm working on a larger project for Netduino Plus. I was hoping to use System.Http.dll but it turns out that I'm running out of memory when I try to deploy the whole project. So I started looking how the memory is allocated.

First here are the assemblies that are included wiht the Netduino Plus firmware:

mscorlib (4.1.2821.0) (3880 RAM - 33236 ROM - 19134 METADATA)
Microsoft.SPOT.Native (4.1.2821.0) (1144 RAM - 6516 ROM - 4479 METADATA)
Microsoft.SPOT.Hardware (4.1.2821.0) (1752 RAM - 11440 ROM - 7371 METADATA)
Microsoft.SPOT.Net (4.1.2821.0) (704 RAM - 5060 ROM - 2452 METADATA)
System (4.1.2821.0) (872 RAM - 5992 ROM - 3206 METADATA
Microsoft.SPOT.IO (4.1.2821.0) (740 RAM - 4620 ROM - 2522 METADATA)
System.IO (4.1.2821.0) (1548 RAM - 13292 ROM - 5862 METADATA)
Microsoft.SPOT.Hardware.SerialPort (4.1.2821.0) (508 RAM - 3440 ROM - 1527 METADATA)
Microsoft.SPOT.Hardware.Usb (4.1.2821.0) (580 RAM - 3740 ROM - 1844 METADATA)
SecretLabs.NETMF.Hardware (4.1.0.0) (256 RAM - 1108 ROM - 491 METADATA)
Total: (10320 RAM - 88444 ROM - 48888 METADATA)

As you can see in total it consumes about 88KB of RAM and I think most of these libraries are essential for any project. Well maybe apart from Microsoft.SPOT.Hardware.Usb - I guess most of network devices won't need ot connect as USB client. But it gains us only about 4KB.

When I add System.Http to blank project I can deploy it but it leaves very little ROM left. Here are the additional assemblies:

Microsoft.SPOT.Net.Security (4.1.2821.0) (264 RAM - 1220 ROM - 606 METADATA)
System.Net.Security (4.1.2821.0) (664 RAM - 4544 ROM - 1943 METADATA)
System.Http (4.1.2821.0) (2976 RAM - 38160 ROM - 12831 METADATA)

So in total it will add almost 44KB ROM. Of this about 6KB is used for the security assemblies. I guess this is requried to support HTTPS. I don't need it for my project at the moment so it would be cool to turn it off. (Again, I wish .NET MF had a post compile linker like MonoTouch to strip the code that is not executed in the project).

According to the tech spec Netduino Plus has only 48KB ROM left for our code. So with System.Http it leaves us with only about 4KB. It's really not enough for anything beyond a most basic project. For example for my project I estimate at least 15KB be needed.

So for now System.Http is no go, and I will try to implement basic HTTP functions on my own. But I hope there is a way to reduce the size of these libraries somehow so we get at least 15-20KB ROM more.

Sorry! I'll keep quiet until I've actually used my Netduino Plus and know what I'm talking about.

No worries. Maybe what you had in mind was using DHCP insteado of static IP configuration, which Chris warned that its not officially supported yet.

DNS is definitely supported in the Netduino Plus.

The optional TimeService component is not included in the Netduino Plus firmware (to free more flash/RAM for apps)--but it would certainly be possible to add on such functionality...

Chris

Indeed DNS is supported and works fine for me.

I think for network connected data logger or similar web enabled scenario it would be beneficial to synchronize to proper local time. Even more because Netduino board doesn't include Real Time Clock so the time needs to be set after each reset.

Michael Schwarz shows how to query the NTP server in managed code and this doesn't look overly complex (I will try it today): http://weblogs.asp.n...rk-devices.aspx

If this is not adding much to the firmware size it would be good to have it implemented.

I don't know, don't have my Netduino Plus yet but maybe try the IP address of the NTP server, maybe DNS is not implemented yet, or what you said maybe NTP is not fully ready yet.

I have tried the same code with the Tahoe II board and in the emulator. Both work fine so I guess this is simply not implemented in the Netduino Plus firmware.

Hi,
I'm trying to use the TimeService class (from Microsoft.SPOT.Time assembly) to synchronize time on Netduino with NTP server. Here is my code:

  var timeServer = "time.nist.org";
  IPHostEntry timeServerHostEntry = Dns.GetHostEntry(timeServer);

  var status = TimeService.UpdateNow(timeServerHostEntry.AddressList[0].GetAddressBytes(), 200);
  Debug.Print("Current time UTC"+status.CurrentTimeUTC);

But I get this exception when calling any method on TimeService:

    #### Exception System.NotSupportedException - CLR_E_NOT_SUPPORTED (1) ####
    #### Message: 
    #### Microsoft.SPOT.Time.TimeService::UpdateNow [IP: 000a] ####
    #### NetworkTest.Program::Main [IP: 0044] ####
A first chance exception of type 'System.NotSupportedException' occurred in Microsoft.SPOT.Time.dll
An unhandled exception of type 'System.NotSupportedException' occurred in Microsoft.SPOT.Time.dll

Is this function implemented in Netduino Plus firmware?