zajda:

Welcome. You can find a good review of bread boarding here:Bread Board They will also cover your question about LEDs. The wires used for bread boards will work nicely to connect to your Netduino.

Good luck and have fun.

Can you post a schematic?

 

I2C is sensitive to the pullup resistor values used on the SDA SCL wires.

All of my ND and ND+ gen 1 and gen 2 are flashed to the latest firmware and everything running under 4.2 NETMF.

 

ND gen 1: 4.2.0.1

ND+ gen 1 4.2.0.1

ND+ gen 2 4.2.2.2

 

All the gen 1s are running WINUSB and gen 2 MFUSB on the latest  VM Player 5.0 Win7 ultimate 64 bit.

 

I can get all my gen 1 running OK together.  I have to reconnect them often in order to deploy and get into debug, but it is workable.

 

For the most part when running the gen 2 alone, deploying and debugging works OK.  If the gen 2 stops responding and needs to be disconnected; I will 100% of the time get a BSOD.  (It's not always fun having the ND+2 act as a hardware reset button in the middle of coding a project )

Doe anyone have experience running a development environment with two Netduinos?  Specifically one ND+ and one ND+2?

 

I was getting BSOD and decided to rebuild my environment and now I can't seem to communicate with two NDs.  It will recognize one or the other but not both.

 

I can use ND and ND+ without a problem, it's only when I plus in the ND2...

Hear, Hear...

Sometimes, Socket.Accept will throw an Exception. It's only sometimes, and it's immediately after the program starts.

I do have a busy loop in to wait for an IP to be assigned, but otherwise I can't figure out what going on here. Ideas?

Chris:
The only way I can get Sockets to work is to catch the 10053 exception, sleep for 100ms and immediately try again. Sometimes it works on second or third try; sometimes more. I am not sure you are getting the same error code; can you post the debug?

These XBee drivers are great.

 

Grommet

 

As well as this one:

 

GBee

Thanks for this reply. Could you explain what is meant by a "locking scheme"?

Sure:

In my code I open the Filestream once and keep it open.  It would be a bad thing if multiple threads interacted with the the stream at "the same time".  I therefore create an object to lock it (private object LockMe = new object() and any time I am reading or writing to the filestream I make sure the code holds a lock on this object (lock(LockMe) { //Code here } )

 

This way, you can ensure only one thread is interacting with the filestream at any given time.  Just make sure the scope of LockMe is shared between all threads.

 

I hope this helps.  You can google "C# lock()"  for more reference.

lol, doing the same with my 2012 Hemi Charger....

Dave:

Thanks for the reply.  We did, and actually still are considering that option. Longer term we want to use the larger 100 pin STM chip to take advantage of extra IO.

 

We also wanted the first generation to tap into SPI3 for the onboard SD card: but I can always mount the SD on SPI1 with ND2.

 

One factor is having a real-time CAN bus capturing OBD data.  Still have not decided on the best approach; but it would be nice not having to add a lot of hardware to do that.

 

Cost is not the only factor; total size is also a design factor, which is why we jettisoned the Ethernet.  There are several add-on devices needed to fit into a total footprint < 3" X 3"

 

As always, thanks for the insight!

I have been asked to help with a project to build a device based on the Netduino framework and the STM32F405 family of processors.

 

We expect to use the same processor as the Plus 2, but leave off the ethernet hardware (we need the flash, not the ethernet)  There is also a possibility of going to a larger package in the future to expose more peripherals; like a CAN bus.

 

I have two questions for anyone with experience building their own device.

 

1) For the first revision I would like to avoid having to recompile the ND firmware and just flash the current build to the new device.  Is there any problem flashing the ND 4.2 build on a chip that has not implemented the ethernet hardware?

 

2) I would like to get a second set of eyes on the schematics before I build a prototype board. Is there someone interested in reading the schematic to catch my mistakes?

I have written a couple applications that have multiple threads accessing the SD card at the same time; it works but you need to be careful with a couple things.  You hit on the first one; one thread per file (reading and writing).  If you need two threads, simple locking mechanism can ensure read/seek/write transactions remain pure.  Since each thread keeps their own file structures (Assuming you are not sharing them!); mostly you are OK.

 

I have also found that dealing with the SD card is quite resource intensive; especially when mixed with time-sensitive sensor reading.  It is easy to create bottlenecks in the code that create data flow problems. Multi-threading on the netduino is not parallel processing; it just allows you to branch execution into separate places in your code - processor time is shared between the threads so only one instruction is running at a time.  The right locking scheme can make all of the difference.

 

SD cards also use SPI.  This is another area to make sure you code is aware there are multiple SPI devices.

I've attached the project. Any help much appreciated.

My ND+ is in use, so I could not run this code. Reading it, I suspect this {below} part of the code might be causing your trouble. From what I can gather in reading the source, this code gets called once to start flashing, and then again to stop flashing. That will create two threads for blinky: once when it gets the "on" command, and then creates a new thread when it gets the "off" command. I suspect that the "off" command does kill the thread started by the "off" command, but the "on" command thread is still running. If you look at the debugger output, you can see when the threads terminate to verify; compare that to when new threads start.

Look for something like the following: "The thread '<No Name>' (0x14) has exited with code 0 (0x0)." in your debug output.

One way to deal with this is to use managed threads and then you can tell which threads are running. {great way to learn about thread pools!} An alternative is to store the state of blinky in a static variable in main() so you can do two things: 1) make sure two "on" commands are not called without first calling an "off", 2) verify blinky is running before you try and kill it. (This will also require that blinkyobject be declared as static in main() as well so you can kill in one thread what was started in another)

[Disclaimer: There will be various opinions as to the best solution; I am just suggesting a couple that come to mind at the moment ]

Happy blinking! I hope this blurb helps get this solved for you.

               case "flashled":
                    {
                        
                        bool state = (e.Command.Arguments[0].Equals("on") ? true : false);
                        {
                            blinky blinkyobject = new blinky();
                            Thread blinkythread = new Thread(blinkyobject.blinkygo);

                            if (state == true)
                            {
                                Debug.Print("blinky start");
                                blinkythread.Start();
                                e.ReturnString = "<html><body>You called FlashLed with argument: " + e.Command.Arguments[0].ToString() + "</body></hmtl>";

                            }
                            if (state == false)
                            {
                                //Debug.Print("blinky stop");
                                blinkyobject.RequestStop();
                                Thread.Sleep(500);
                                blinkythread.Join();
                                Debug.Print("main thread: Worker thread has terminated.");
                                e.ReturnString = "<html><body>You called FlashLed with argument: " + e.Command.Arguments[0].ToString() + "</body></hmtl>";
                            }
                        }

... So I did. But when I run blinkythread.abort

it throws an exception. Maybe I'm going about it all the wrong way. What I'm hoping to achieve is to be able to send a get

request through a browser like http://ipaddress/setbath/36 .

Hi Grant:
Maybe instead of just aborting the thread you could signal the Blinky thread to shutdown more gracefully. One way is to set up a simple event and trigger that event from your main code. This way the Blinky thread will close and perform any cleanup. You could put a timeout waiting for that thread to end before forcing the abort. Also, make sure the thread is still alive before calling the abort.

This tutorial may be helpful: Events
And this one on threading: Threading

Both of these helped me understand .NET threads and events.

I have an extra board;happy to send it along... Just PM me.

I have designs and plans to build a hardware watchdog you can use on a breadboard.  It is based on the MAX6373 chip.

 

I have posted the designs in another thread, or I can build one for you if you are interested.

Update went well, but now I am seeing a quirky problem reading from the SD card.  The following code hangs on the "while (reader.Peak())" line.  Stepping through the debugger looks like it is stuck in a loop...  Here is the code.  The file on the SD card has 10 lines of ascii data.

 

            ArrayList PortList = new ArrayList();            using (StreamReader reader = new StreamReader(PortFileName))            {                while (reader.Peek() > 0)                {                    HoldPort = new MCUPort(reader.ReadLine());                    HoldPort.State = 1;                    HoldPort.LastState = DateTime.Now;                    PortList.Add(HoldPort);                }            }

Thanks to Lunddahl and T!!

 

 

i also found that EndOfStream property is not set until AFTER the first access!!!  Before that it always reads "true".  If I use Peak() after opening the stream, and then change my while loop looking at EndOfStream it seems to work.

 

I will try looking at the solution T provided.  Thanks for your help!!

Ok! Thank

I can confirm that these drivers work very well. Easy to use and bug free (so far ) I trimmed them up a bit as I did not need all of the features written in the driver. Took me about a hour to get everything hooked up and running.

You must also have a ND with a SD card to use the drivers. That means either a ND+ or ND flashed to 4.2 and a SD shield of some kind. If you use the latter, you will have to add the mount and unmount commands to the driver.

Hope you enjoy; I know I did!

I have NGO and no SD card yet

Maybe you could update the driver to send data out a serial port to some receiving system as it is read from the camera. You could get fancy and maybe perform a post to a waiting web server; assuming you have an Ethernet or wifi shield.

You have 2 projects and the ND startup is 'referencing' your library?

Yes, one project is what you have today (Production) and one new one (debug) that just references the library as a standard .dll

Your deployment grabs the library project and loads it to the flash chip? How are you referencing the library at this point? Standard reference or reflection?

Standard reference, just like any other .dll you include. Yes, at deploy time the .dll will be sent to the flash at the same time as your exe because it is just another .dll.

(At the risk of confusing the issue: an alternative approach might be..)
To make it easier to code, another alternative is to add a "library" subdirectory in this new (call it debug) project and add your library source as links into this subdirectory. That way the compiler knows to recompile the changed "library" code along with your program on any changes at build time. This way you are not dealing with two projects (one to build the dll and one to build your debug program) The downside is that you have to manage "who is calling who" to make sure you don't break your dll by referencing something that will become out of scope in your production build.

What exactly are you doing here differently in your calling startup assembly?

Nothing different. I am sure you are doing this now. I just load the assembly and call the starting method.

I use Windows 7 Ultimate hosted on a local VM through VMWare Player as my dev environment and had the same issue until I re-flashed my Netduino BIOS. There was an issue with the earlier version of SAM-BA 2.11 that had a problem with slow deployments that may be related to this. Using the new 2.12 version of SAM-BA and flashing the latest 4.2 firmware solved the problem for me. (I do, however, still get BSOD if I hit the reset button on the ND during deployment)

Great News! I was able up update my ND/ND+ and everything went really well! Easy.... Thanks for the updates!

The BSOD is in the VM. My host is fine. The Service reads "WinUsb" and the Hardware ID is "USB\VID_22B1&PID_1001&REV_0100"

I may not understand the question, but I have done this in the past to help debug: I create a simple program that includes the .dll as a library. I then flash this to the ND as a single program (no loading assemblies from sd) I do all of my debugging there as normal. When I am ready to deploy in Production, I just deploy the obj/Release/le/*.pe (Associated to my .dll) to SD and load my "bootloader" program through regular deployment. There is about 3k to 4k of overhead for doing it this way (including a .dll with your main program) until you load your final assembly. Maybe?