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"?
=====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