This seemed to have solved my problem on my HP Touchsmart laptop... the Netduino wouldn't show up in VS.NET 2010, even though it was showing in MFDeploy. I changed the driver as described, and voila, it showed up.

Unfortunately, now, while the Netduino Plus DOES show up, when I attempt to deploy, I get: "Error    1    An error has occurred: please check your hardware."
 

Sigh.

A handful of users running under VMs have reported a preference for the legacy MFUSB drivers. Here's a quick set of instructions on how to force your 4.2 Netduino or Netduino Plus to use the MFUSB drivers.

To manually switch to MFUSB (SpotUSB) drivers -- for special cases

Well, I've been doing physical construction, rather than programming, so haven't checked the thread lately.

I'm not sure I would want to use Socket.Receive, both because it DOES block (that's the point of wanting to use Interrupts), and since if it doesn't receive any data within the timeout period, it throws an exception. In general, I try to avoid exceptions as a method of handling program flow.

OTOH, there is the following a couple of lines further down in the same link:

"You can use the Available property to determine if data is available for reading."

I suppose I can set this up as a loop that will poll the Socket.Available property, do the read if anything is found, then go back to sleep for, say, 100ms or so.

I've almost completed the motor mount for the stepper motor for the turntable (needed two unusual-sized drill bits which I picked up this morning). After it's mounted, I can get serious about the programming portion.

Paul,

I've already gotten versions of code that do polling, as you're doing starting in Program.cs at line 220:

Paul,

I've already gotten versions of code that do polling, as you're doing starting in Program.cs at line 220:

After a hiatus, I'm getting back to a project involving networking multiple Netduino Plus's together using Ethernet. The messages I'll be sending/receiving are VERY simple, to the point that I don't intend to use full TCP/IP, just broadcast packets. This is a general framework for managing a variety of inputs and responses to automate portions of a model railroad.*

Each Netduino could be a source and/or sink of "events"- a sensor on one (could be a button, a IR detector, or other Digital input on one of the IO lines, or the completion of some task like waiting 30 seconds, or turning a stepper 100 steps...) can trigger an action on one or more Netduinos (again, including possibly itself).

Most of the networking samples I've seen involve polling the Ethernet instead of interrupts. I see that at least SOME hardware (typically based on the W5100) can handle Interrupts, but I'm wondering if this can be done with the native Ethernet adapters on the Netduino Plus (currently flashed to .NET MF 4.2).

For example, if I wanted to generate an InterruptPort (or some other object) to which I could attach methods to respond to "Data Available" on the Ethernet, how would I declare it? I don't think it would be a Cpu.Pins object, for example (or is it?) like it would be for the external Shields.

Does anyone have sample, or suggestions where to start for libraries, or how to generate an Interrupt on "Data Available"?

Brian

=====Following Unnecessary to answer the question, only of interest if you're curious about what I'm doing=====

* Think of the architecture like this:

     - Every input, no matter what it is, can send an "Event". This could just be simple existence (button pressed, or Occupancy Detection, just "Event 25 happened"), or it could have a small payload (Rheostat value 0-255 changed - "Event 32 happened with value 216"). This "Event" gets sent as a broadcast throughout the (small) network.

     - Every Netduino has a list of Events which it's interested in. If it hears that Event, it takes some response. (Throw a turnout/move the turntable/turn on an LED, etc.)

Note that the entire system is solely event-driven, with (relatively) infrequent events and tiny data packets. The intention is to be fairly Idempotent... if one activates the same Event a second time, existing outputs shouldn't necessarily change if they "heard" the event the first time, but anything that missed the first could react.

Example of the Producer/Consumer architecture:

- I press a pushbutton on the control panel (Event 13, let's say)

- Event 13 is broadcast on the LAN

- Every Netduino connected to the LAN listens- if they are configured to react to Event 13, they do so, if not, they ignore the packet.

- Sample Reactions:

     * The Netduino inside the control panel sees that it is listening for Event 13, and the responses are two turn several LEDs to "On" (indicating the route through an Interchange)

     * The Netduino under the Interchange listens for Event 13, and the responses are to throw several turnouts (some may be to Normal, some to Reversed) to set that route.

     * The Netduinos under adjoining modules listen for Event 13, and set multiple colored LEDs respectively to represent Proceed Slow and Stop.

Some of these could be the same Netduino responding, some could be different. The point is that each Netduino only needs to known its own behavior, not that of the surroundings. It should make it simpler to add new features... Add a new Producer, and see if the events are being sent properly before adding new Consumers, add the Consumers one-at-a-time, etc.

The idea is to have basically the same code base running on ALL of the Netduinos. Upon start, they will load a configuration file from the SD Card which contains basically a list of

     * Producer: Pin X value Y generates Event Z

     * Consumer: Event A causes Pin B to set value C

Ok, using the HEX and BIN worked like a champ.  My program basically used the "Erase Firmware" from MFDeploy, then Uploaded the new HEX and BIN files, then verified the firmware version was different than the previous version.  Finally it sets the MAC address (as this gets erased) and reboots.  Everything comes up fine and it's showing version 4.2.2.2 and the Pandora's Box version 2.95 software was still on there and didn't need to be erased as it doesn't affect those sectors.

 

All in all, the process too about 2 minutes.  This is a great way to allow end users of my product to get firmware and software upgrades alike.

Would it be possible to elaborate on the steps to accomplish this? I've tried the "standard" upgrade method described at the beginning of the post (StDfu Tester doesn't seem to find the Netduino, whether I've connected it WHILE, or WHILE NOT pressing the button). I also tried your method, finding the Erase | Firmware (I included Deployment as well), then trying to upload the .HEX, followed by the .BIN files. All this resulted in was:

Tinybooter.hex:

Unable to deploy to device

 Invalid address 8000000 and range 9c04 Ram Start 0, Ram end 20000

or

TinyClr.hex files ("ER_CONFIG" "ER_FLASH"):

Unable to deploy to device

 Invalid address 800c000 and range 90c Ram Start 0, Ram end 20000