Do you know the part/model # or where I could buy one? It's nice!

It's just regular potentiomater that I got from a local hobby electronics store in my town.
Looks exactly like this one: http://www.oreind.co...products_id=859

I only put a platics knob on it :-)

Ok, think this should be stickied, the problem is that VS2010 will AUTOMATICALLY put the microsoft default PINS in there, which do not map up to the Netduino pins. That was my problem. Thank you so much!!!!

I think you are right. The classes from SecretLabs.NETMF.Hardware.Netduino namespace should be actually declared as internal classes on Netduino class. Then it would be clear that you have to write for example Netduino.Pins.GPIO_PIN_D3. Currently this code is invalid. If I remmember ut is done this way in GHI and DeviceSolutions SDKs.

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

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 :-)

I change the jumper for Vref to the 5 V source. This did a find job of centering the signal, but the max values were very unstable. I guess I was over driving the A/D. So I cut the trace from 5 V to the joystick and added a wire from 3.3 to the joystick and Vref. Now every thing works just fine. See the attachment.

Thanks for sharing your findings.

Looks like the fact that Vref is not connected on Netduino causes troubles with some shields, and also is bit confusing for people comming from arduino. Maybe Chris could explain why it was done this way and if there is any technical difficulty to make it connected by default to 3V3 in future revisions.

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

I'm going to try to fit Netduino in Adafruit's Arduino Enclosure http://www.adafruit....products_id=271 I think it would fit nicely and only need to do one more cut out for micro USB. And I plan to add LCD display and buttons for debugging of my device.

Here is one more LCD interface that might work. It runs on 3.3V but uses I2C instead of Serial. http://shop.jeelabs....oducts/lcd-plug

Hi Stacy, Recenty there was a series of posts on the Make Blog about using Arduino to control aNerf Sentry Gun. Maybe this will give you some ideas to start with: Here are few of the posts in this series: http://blog.makezine...uild_wirin.html http://blog.makezine...emassembly.html http://blog.makezine...uild_prima.html http://blog.makezine...denclosure.html http://blog.makezine...king_stand.html http://blog.makezine...uild_motor.html They apparently used relays for this project: http://blog.makezine...olderrelay.html

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

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

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.

I received my frist Netduino that I ordered on August 4 from Proto Advantage and it was shiped next day via Air Mail from Canada. Arrived today so it took 2 weeks to get it to Poland. Thanks god we have European resellers now :-) Small box looks cool and I got the USB cable inside the envelope. Anyone can tell me what was the motivation to use micro USB instead of more common mini USB ? The board itself loosk little empty when you compare it to regular Arduino - I guess if you'd trim all the empty space you could put it on a board half that size (Netduino Nano parhaps?). But overall it looks great. Nice work guys!

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.

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.

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?

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 :-)

I have added both as product change proposals on community site: http://www.netmf.com...02-a0462ba8340c http://www.netmf.com...4e-7cf309a9f296

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

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.

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