How to implement some arduino patterns

1

How would you deal with some common Arduino coding patterns when writing native XOD patches/libraries?

Many libraries have an object that manages the interface. Serial/Serial1/Serial2, for example, or the Adafruit neopixel library, MIDI libraries, or most of the xod/hardware nodes.

  1. How do you associate nodes with the instance? Because you have to construct the instance, yet you may want several different nodes that use it (like Serial.read() and Serial.write()). Who constructs it?
  2. If you want more than one instance (e.g. neopixels on 2 different pins), how would you relate the constructor to a XOD node, and then associate nodes with that instance? So a serial-read node could work on Serial2 and Serial1.
  3. The MIDI library I’m playing with needs a heartbeat to handle i/o. It just wants a method called everytime through the loop. What’s a good way of implementing that? Again, there are multiple nodes that use the midi stuff (note-on, channel-change, etc.). A floating ‘continous pulse’ node seems annoying, and it requires the user to remember to make the node.

A good example showing the above issues is: DualMerger.ino

2

You’ve touched a weak point of XOD. Currently, there is no established pattern to manage interfaces effectively. A hack’ish workaround is having a number-type pin to select the interface desired: 0 — Serial, 1 — Serial1, 2 — Serial2, etc.

Let me try to explain how it could be done in future. A node (midi-thing) that works with Serial would expose UART pin. There will be nodes like default-serial, serial-1, serial-2, software-serial. All these nodes have a single output named UART that a xoder would feed to the midi-thing/UART input. Inputs depend on the node: baud rate, parity check, pins (in case of software serial), etc. Those nodes are responsible to properly construct themselves, i.e. initialize MCU hardware peripherals.

To make it possible several core improvements have to be done: custom data types, generic inputs/outputs, parametric polymorphism. Once we implement it, such cases should become very expressive in XOD.

Using continuously is the right thing to do. To avoid annoyance you can set “Continuously” as a default value for an input of the heartbeat node which delivers the pulses. That way a node user has not to remember to add his own continuously node and if he knows what he does, to override the behavior, e.g. suspend the process.