# How to implement some arduino patterns

**URL:** <https://forum.xod.io/t/how-to-implement-some-arduino-patterns/220>\
**Category:** Uncategorized\
**Created:** [November 28, 2017, 4:52am UTC](https://forum.xod.io/t/how-to-implement-some-arduino-patterns/220 "2017-11-28T04:52:57Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![awgrover](https://avatars.discourse-cdn.com/v4/letter/a/74df32/32.png) [@awgrover](https://forum.xod.io/u/awgrover)\
**Post date:** [November 28, 2017, 4:52am UTC](https://forum.xod.io/t/how-to-implement-some-arduino-patterns/220/1 "2017-11-28T04:52:57Z")

</div>

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](https://github.com/FortySevenEffects/arduino_midi_library/blob/master/examples/DualMerger/DualMerger.ino)

---

<div class="post-metadata">

**Author:** ![nkrkv](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.xod.io/nkrkv/32/8_2.png) [@nkrkv](https://forum.xod.io/u/nkrkv)\
**Post date:** [November 28, 2017, 9:11am UTC](https://forum.xod.io/t/how-to-implement-some-arduino-patterns/220/2 "2017-11-28T09:11:57Z")

</div>

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.

> [@awgrover](#):
>
> 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.

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.