Chris, please count me in for the Gadgeteer shield!

The processor itself is surely fast enough for 1-Wire, at this time the problem is with native (C++) code generated by GCC, but it works.

It works on Arduino so it would be weird if Netduino's much superior CPU couldn't handle it :-)

Just thought of something else I'd love to see - a couple of power pins for the netduino itself. I'd like to be able to power it with LiPo batteries using a JST connector, but just a a couple of power input pins I can work with.

(no, I don't want to have to hook a barrel connector up to the battery if possible).

If I understand you are thinking about something like with Arduino Pro?
http://www.sparkfun....roducts_id=9221

And similar with Arduino Fio (it even has LiPo charger built-in):
http://www.sparkfun....roducts_id=9712

Give my new library a try.

Use it to control Allegro A6281 based RGB LED boards (Brilldea PolkaDOT and various from Macetech.)
I have a daisy chain of 8 running off my Netduino (only USB power so far.)
It is a little light on documentation, but the sample application should get you going.

Let me know what you think.

uA6281 on Codeplex.com

Hi SupraBitKid,
You beat me to it! I have my lib for already working with ShiftBrites and was ready to publish it soon :-)
Now I guess I will look at yours to see if I can contribute anything.

Great work. Thanks for posting!

If you can afford it, I suggest the Rigol DS1052E. It has the bandwidth and sampling rate needed for most microcontroller project.

There was some hack to double the sampling rate to 100Mhz (but it no longer works with new firmware)
http://www.eevblog.c...100mhz-ds1102e/

I found it on http://www.dealextre...ls.dx/sku.30573

But what you think about this one? http://www.dealextre...ls.dx/sku.36153

If you are just going to look at digital signals, you can consider USB logic analyzer. There are a few companies that makes them.

I was thinking to buy this one http://www.saleae.com/logic/features/. Is it good enough?

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/

Take a look here: http://blog.makezine..._gadgeteer.html Gadgeteer is very interesting project for rapid prototyping of embedded devices built by Microsoft Research team in Cambridge. Of course .NET MF is heart of a project. http://research.micr...er/default.aspx Not much information on the project page right now but I hope we can find out more soon. In particular it would be interesting to learn what board they use, and if it can be made compatible with Netduino (maybe via a dedicated component shield).

It's using GHI's EM module on the back, so i wouldn't be surprised. Is it just me, or did just about everything he tried to show working... not?

Oh, I haven't noticed the GHI EM module on video but indeed this looks similar to FEZ components. Anyway, I think the software side of this might be interesting as well. I hope they will release the code as open source so we can get a good library of drivers for bunch of cool modules.

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

That would be realy cool. Would even do greater distances and could use a switch for connecting them..

In the meantime I recommend reading the "Making Things Talk" book that dicusses many other communication technologies.
http://oreilly.com/c...g/9780596510510

Maybe it will give you some ideas. In any case let us know what you came up with.

I've played around with microcontollers here and there, but now I have a project that I must work out. I'm trying to figure out the best way to tackle this new project. What my goal is to control a high powered LED and stepper motor using DMX-512. I'm not sure how to approach this but I could use some help getting pointed in the right direction. Is the netduino a good choice or is there something that would be better.

This sounds similar to one of the projects I want to implement myself. Could you provide more detail on what you are going to build?

-Szymon

Would we get any notification (event) when card is inserted or removed?

I think the point that he was making is that the company who makes that board is holding back their actual NETMF source which enables the board's peripheral features (ADC, PWM, etc.)--so if you want to flash your own NETMF firmware you have to start from the more barebones implementation that Microsoft provides in the porting kit (and you're on your own--they won't let you flash the original closed-source firmware back onto it).

Actually according to this post http://www.tinyclr.com/forum/14/875/ this time they are going to release the firmware source code for this board. If thats true I really like the change of direction.

Whats more Guss Issa writes a new ebook about the porting kit. You can download it here http://www.tinyclr.c...rting NETMF.pdf

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

Totally agree Chris - it just came up as a big stink on the Fez boards so I figured I'd post here to try to remind folks that not all code is free (as in beer).

Actually that was the main reason I wrote my own version of LCD library from scratch (and the Wii Nunchuck as well). They are based on open source Arduino libraries and I attributed the creators in source code header or in the coresponding blog post so I hope everything is fine from legal perspective there.

That's a great point. And one of the beauties of open source: we can build off each other's work, and people get credit and kudos for what they've done. It's really a fantastic system in many ways.

Please note that if the source you're building off of is GPL or otherwise share-alike that you'll need to note that in your derivative code. Share-alike code is fantastic, but businesses will often stay away from it due to legal concerns (founded or unfounded).

Chris

I couldn't find what license is covering Arduino libraries. From the Arduino FAQ I understand that the Arduino environment is covered by GPL but this doesn't prevent it's use in comercial products: http://arduino.cc/en/Main/FAQ

The footer on the LiquidCrystal library page says about "Creative Commons Attribution-ShareAlike 3.0 License" but I think this applies to documentation. http://arduino.cc/en...e/LiquidCrystal

I'm not sure how this applies to the code that was ported to different language or platform so if anyone can clarify this I'll be happy to change the licensing or take any other actions as appropriate.

Maybe this is another good reason to publish the project on CodePlex, because it ensures that users accept the license for each download.

Chris, The project looks super cool! Please keep posting about your progress. I'm busy now with some other things but would like to follow along and build one later too.

Alright so I run a little home server that I can set-up a website in and My radio station so on...
Could I set it up as a 'middle man' [middle computer in this case ] so one Netduino can talk to the other using ethernet shields? I would love to set up a thing where you get a account # and password and it allows you to send info back and forth! FREE of course.

OMG 'Netduino IM' LOL how funny would that be!?!?!

I think what you are talking about is called Machine-to-Machine communication (M2M) http://en.wikipedia....hine-to-Machine

Incidently recently I came across an OS platform that can handle this called Mango M2M http://mango.serotoninsoftware.com/

Slightly different angle would be the notion of Sensor Web. One example would be the OGC Sensor Web Eneblement initiative http://www.opengeosp...echnologies/swe and example implementation is here http://52north.org/S...oxf/index.html. Another popular example is http://www.pachube.com/

I'm interested in these topics myself so please let us know if you make any progress with this.

I have to agree with CW2 that exposing all registers my lead to unexpected errors. I was also thinking that it will be better to expose the wrapper for the timer/counter function alone. Very similar as we have managed wrappers for PWM and analog ports now. Maybe it should be Microsoft team responsibility to implement this in next release of .NET Micro Framework.

This should really be a firmware extension. If you have the knowledge to write the registers correctly then you can extend the firmware.

This is much simpler then the port of the CLR since all it really needs is a managed class for the .NET side with the stubs produced for the native functions.

All the nasty driver work and HAL/PAL work just isn't needed here. That just gets compiled in as a black box. As a reference point, how many people actually know how the c-runtime gets started up when they run a program they wrote in C?

The rest of the firmware just gets treated the same way, as kind of a c-runtime, for most people.

So perhaps what we really need is a simple sample that shows how to do this.

I'm afraid writing a native driver is still way out of my reach. I don't know that much about microcontrollers and was hoping that .NET MF will shield me from this ;-)

Sample showing where to begin with would be great!

PS: all about timers I learned here http://www.avrfreaks...ewtopic&t=50106

Hi,
I'm working on a project that will allow to control RGB LEDs using Netduino. I planned to use the TI TLC5940NT LED driver chip that has 16 channels with 12-bit PWM, and is quite popular with Arduino. Here are some resources for anyone interested:
Arduino library
Demystifying the TLC5940 ebook

I started writing the .NET MF driver for this chip with a reference implementation as described in the above ebook. However the pure managed code is too slow to drive chip's clock signals. So the next step is to use the hardware functions.

This chip uses SPI to receive the grayscale values from microcontroler, and moving this to hardware SPI was easy. However this chip also requires a clock signal for PWM outputs. Whats more the new SPI values should be latched preciesly at the end of each PWM cycle, that is every 4096 clock sygnals.

Now the Arduino library uses the hardware timer counter with interrupt to achieve this. Here is the corresponding code to set this (from the "Demystifying the TLC5940" ebook):

// CTC with OCR0A as TOP
TCCR0A = (1 << WGM01);
// clk_io/1024 (From prescaler)
TCCR0B = ((1 << CS02) | (1 << CS00));
// Generate an interrupt every 4096 clock cycles
OCR0A = 3;
// Enable Timer/Counter0 Compare Match A interrupt
TIMSK0 |= (1 << OCIE0A);

Would something similar be possible on Netduino? I admit I got stuck on this so all suggestions how to best convert this to .NET MF would be welcome :-)