5 replies to this topic

[Big Bear Brian]

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

[Paul Newton]

Hi BB Brian,

 

I wanted to link a Netduino with a Raspberry Pi, and I also felt TCP/IP was over the top.

It took quite a while to work out how to just use UDP as most examples are TCP.

 

Anyway I managed it and created a multi-threaded program that can send and receive really simple UDP "messages" to/from another ethernet device (such as a Raspberry Pi, Netduino or PC). Be assured that my initial work was Netduino to Netduino, then Netduino to PC running Python, then finally the Pi.

 

Anyway I created a cut down example project and zipped it on this forum page, with a you tube video of it in action.

 

If I recall it correctly, I send messages from point to point rather than broadcast, but I think you can open a socket to receive messages sent to any address.

 

Hope this sparks some ideas - Paul

[Big Bear Brian]

Paul,

 

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

 

            // Loop forever

            while (true)

 

I'll have to go back to my code, BUT... allowing for six+ months of not working on this, my recollection is that I wanted to do this in INTERRUPTS, not a loop/polling. The idea is, why have a thread that's constantly spinning, doing nothing, while other threads could be delayed.

 

I'm looking more for something in which, during initialization in Main, I would do something on the order of the following pseudo-code:

 

     InterruptPort ethernetListener = new InterruptPort(EthernetPin);

     ethernetListener+= EthernetDataReceivedHandler;

 

And the method EthernetDataReceivedHander would process the data coming in across the wire.

 

Honestly, right now, I can't remember if I had some PARTICULAR reasoning for wanting to do it in Interrupts, or just aesthetic. :-) I DID get code working that used polling, and had my UDP broadcasts going out (as well as a Windows-based test harness that listened for the packets and could send its own arbitrary UDP packets.)

 

I KNOW that I've read a number of comments on Arduino forums regarding the W5100 that it "can be more efficient to use Interrupts". You have to bridge one set of solder connections on most of the W5100-based shields I've seen, but it's do-able. You then initialize your Arduino equivalent of InterruptPort, using the pins of the shield which it communicates back to the board (varies by manufacturer, IIRC). Does the built-in Ethernet on the Netduino Plus have equivalent capabilities?

[Paul Newton]

Hi again,

 

The whole point of what I was doing with this code was to split up the functionality into multiple threads which would work together similar to a main thread with interrupts.

This was to allow the main code to sleep and be woken up when a button was pressed or a message arrived. I did not want the main thread to have to poll anything where it might get stuck and not be able to respond to other stuff.

 

I have just gone back over the listener "UdpRxThread" class, yes it has a while(true), because I want it to keep checking for messages. I understand however that when the code calls the receive method on the socket, it would sleep until it got some data or an error occured.

"bytes = listener.Receive(rxBuff);"

I think this text from the MSDN site confirms my understanding:

"If no data is available for reading, the Receive method will block until data is available, unless a time-out value was set by using Socket.ReceiveTimeout."

 

In summary I think the UdpRxThread will wake up when it gets a UDP message, it will then post it to the main thread causing the main main thread to wake up just like an interrupt being received. The UDP thread will then go back round and wait for another message.

 

Have a quick look at the readme in the C sharp folder of the zip, it gives a bit more background than I have written here.

 

Since I posted the zip file, my code has moved on, I made it a lot more robust regarding problems such as network cable not connected, or remote devoces not being present. I will have to create a new zip at some stage.

 

Have fun - Paul (who also has plans to automate an N-guage railway)

[Big Bear Brian]

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

 

 

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.

I have been playing with some tiny RC servos to motorise my points (turn outs).

The board I have fits into the skirt under our living room table. The board has to be flush underneath - e.g. no solenoids or wires can stick out because people sitting at the table will hurt their legs!

I have located some very thin servos and found that I can use a router / multitool to cut a blind hole in the board under the points that the servo sits in. I added some folded aluminium to allow me to adjust the position of the servo and nail it in place when the point works well.

I found that using servos was actually cheaper than any thing else I could buy to achieve the same job. Now I need to actully fit to the board and work out how to route all the wires!

Paul