Firmata Implementation (Nodes, Parser, API, VL, How, etc)

vvvv beta general
1

Disclaimer: This thread is sparked from this blog post, announcing the VL Firmata nodes; but we need a common place to discuss how to support the Firmata Protocol

Wrap up: New VL Firmata Nodes have been announced; @soundanalogous brought up the issue, that the strictly named nodes are masking the capabilities of the hardware Firmata supports; @robotanton suggested to comletely remove the Arduino-Nodes and replace them with a generic Firmata-Device node.

I agree with @soundanalogous. Nevertheless, the current, as well as the new VL nodes, do support the use of plain Firmata, regardless ofg the board. Just not in a nicely, conveniently wrapped up node such as the named [Arduino (....)] ones. That was an important part for the second C# implentation.
This, I also always show in any Firmata Workshop I do, so people understand, that it a mere issue of transport, not a product of some sort. It is easy to use, but can be powerful, when used standalone as well.

Regarding the Capability Report: It works with the StandardFirmata, which is the only default firmware I am aware of, which reports this back. Used as transport, it does not and is unneccessary overhead, when one knows, what the capabilities are. So we are maybe talking about a StandardFirmata wrapper node? That sounds as a good idea to me.

I don’t agree with deleting the Arduino-nodes. As beginner one will search for this term, not Firmata. I#d rather suggest, we find a way of generating the nodes, either from the Boards.h file (considered this in the past, but is one more dependency to track, touches the complex packaging topic).

A two layered wrapping then?

I would like to keep it very very simple, as the protocol is so simple.

2

Hi @jens.a.e and @soundanalogous,

here is our proposal:

We’ll have two nodes:
FirmataBoard (Devices)
tags: [arduino, teensy, …]
Help: Communicates with a board using the StandardFirmata protocol.

FirmataBoard (Devices Custom)
tags: [arduino, teensy, …]
Help: Communicates with a board using a customized version of the Firmata protocol.

For the FirmataBoard (Devices Custom) user will supply a BoardConfig (Firmata) to define the pin mapping.

All the Arduino (Devices ...) nodes are no longer necessary and will be removed.
Still when typing Arduino in the NodeBrowser, the first Node that shows up will be the “correct” one: FirmataBoard (Devices).

Of course, the underlying nodes, like FirmataEncoder (Firmata), FirmataDecoder (Firmata) will be still available for advanced users, when looking up Firmata in the NodeBrowser.

What do you think?

3

One clarification is that StandardFirmata is not a protocol so I wouldn’t recommend building a node around it. StandardFirmata is simply a partial implementation of the Firmata protocol that is specific to boards that can be compiled with the Arduino IDE. We have also recently extracted the Firmata parsing logic into a separate, general-purpose C++ class so that may be useful to directly include in your project (see FimataParser, FirmataMarshaller and FirmataConstants).

You may want to look into building a node around the “core” firmata features. See documentation here: https://github.com/firmata/protocol/blob/master/feature-registry.md#core-feature-set. This is the direction Firmata is going - as set of core features and a set of optional features (some bundled and some contributed).

4

Hello @soundanalogous and @jens.a.e,

it was our misunderstanding about the StandardFirmata name, we didn’t know it is only Arduino IDE related.
So here is our further simplification.
We’ll have only one node:

FirmataBoard (Devices) tags: [arduino, teensy, ...] help: Communicates with a board using the Firmata protocol.

By default the node sends the ANALOG_MAPPING_QUERY on Connect and waits for the RESPONSE.
If the user has his highly customized Firmata firmware which is not replying to the mapping query then the BoardConfig node has to be provided to set the configuration manually (the corresponding pin is hidden by default).

There will be Query/Response pair of nodes for the features.
And ...Decoder nodes for the messages like STRING_DATA.

See the screenshot.

Thank you for pointing to the general-purpose C++ classes, but we’ve implemented the Firmata protocol completely in VL.

Best,
Anton

5

@soundanalogous and @jens.a.e thanks for your feedback so far. this is a last call for further comments on our latest proposal as lined out above. we’ll then go ahead and realize it like that.

6

I have some more comments; can only respond later though.

7

Sorry for the delay; busy days.

Sending ANALOG_MAPPING_QUERY upfront is a good idea, but should be optional, if one would like to use the internal nodes standalone - only sending or only receiving data.

I am not sure about the BoardConfig node being separate; is their a particular reason, why it is not inside the module? The pins can be on the outside.

@soundanalogous good to see the Firmata lib going into a more generic direction! Unfortunate though that it is impossible (?) to merge/load a compiled DLL into the VL code. But that is another thread on its own. It would make the maintenance easier though. We dould use symbols from their. @joreg any kind of FFI planned?

The StandardFirmata misunderstanding was also a thing in the first rewrite, when I versioned the nodes :)

Yes, the StandardFirmata is one use; I strongly support using more generic names as suggested. Nevertheless, I also recommend to have pre-cofigured Arduino Nodes of some kind, because users, especially new to field, will search for this term. But they can be easily wrapped. Tags help, but nodes would be good too IMHO.

I still think, that the internal design of a encoder and decoder is a suffcient abstraction and we could shape the board nodes arround the notion of the transport they are wrapping, such as RS232, UDP, TCP, etc. As suggested in earlier discussions, an annotated Stream - e.g. a FirmataStream seems logical to me.

The new nodes for reading and writing proved to be a good decision!

8

hei jens,

just to clarify again 3 scenarios:

  1. default arduino scenario
  • user wants to work with arduino in vvvv
  • types “arduino” in the nodebrowser
  • only one node will show up: FirmataBoard (Devices) [arduino,…]
  • user takes that node, chooses com-port and is ready to go
  1. more advanced firmata scenario:
  • user types “firmata” in the nodebrowser
  • the first node that shows up is FirmataBoard (Devices) [arduino,…]
  • user takes that node
  • now also needs the BoardConfig (Firmata) node (as explained in the FirmataBoard node’s helppatch) to specify the boards config that was not automatically reported
  1. even more advanced manual firmata scenario:
  • user sits in a workshop of jens.a.e and is introduced to the innards of firmata and how one can make most use of it
  • creates FirmataEncoder, FirmataDecoder, RS232 nodes, configures and links them manually

regarding the BoardConfig node: since for scenario 1) it is not needed at all we thought we just put this in an extra node. now i see that for scenario 2) it would be an alternative to have the pins of the board-config right in the FirmataBoard node, hidden by default. so for scenario 2) instead of creating the boardconfig node you’d go to the inspektor and enable the pins. hm…i still somehow feel the extra node is more clear here?! thoughts?

true, a node named Arduino in the patch looks good, but really only from the Arduino-brand view. now that we understand that firmata is really much more than arduino it doesn’t make so much sense any more. it is more educational to show that arduino and teensy are just brands, so you can still look for them, since they are set as tags, but you’ll then have nodes that are called after what they actually do: ie, talk to a board via the firmata protocol. then yes, Arduino nodes can easily be wrapped, but as @soundanalogous pointed out in his initial post that will require quite some manual maintanance (unless we have some auto-gen tool) that is simply not necessary now that we understand that standardfirmata will work with all devices anyway.

have we talked about this before? can you elaborate on this? would that mean we should have a FirmataBoard (Devices RS232) and a FirmataBoard (Devices TCP)?

unrelated:[quote=“jens.a.e, post:7, topic:14336”]
Unfortunate though that it is impossible (?) to merge/load a compiled DLL into the VL code. But that is another thread on its own. It would make the maintenance easier though. We dould use symbols from their. @joreg any kind of FFI planned?
[/quote]
not sure what you mean with FFI but of course with VL you can import managed (ie. .net) dlls. an absolutely viable alternative would be to write a simple .net-wrapper for the firmata.dll and import that into VL. only us being the more sporty type thought it would be nicer to have completely visual implementation. not least for a proof of concept that VL is capable of doing such things natively.

9

I know it was a sporty challenge :) good sports knows it limits!?

Very well summed up in the 3 scenarios! Yes. I don’t like the branding either at all, but it is what new users look for. A tag would do it, right? It wouldn’t be too terrible, if more than one related node showed up. Last point: absolutely.

FirmataBoard isn’t the right name imho though. It will resemble more of a StandardFirmata-Client, right? Can we name it StandardFirmata? I find that a good way also, because it makes it easier and better to understand, what the node is doing, resp. for us, what it must be able to do. As the StandardFirmata is composed of Firmata capabilities, it will be build with them, ergo scenario 3 is also covered.

Yes, we have on side notes, but not to any concern to be particularly implemented; I’m repeatingly poting this out, to make clear, that Firmata is not exactly RS232. One could send Firmata encoded stuff from one patch on machine A to another patch in machine B. The protocol is not bound to the transport, e.g. serial communication at 57600 buad. Firmata has at one point moved from a strong binding to the Serial transport to a Stream (Arduino/C++ terms!). This enables any Stream to serve as a transport for the messages. Even despite the implementation detail, the current FirmataEncoder/-Decoder nodes allow the use of any Raw based transport, e.g. TCP from/to e.g. a WiFly-Shield, which offers a serial console on a TCP port. I used this successfully. If the firmware one writes plugs into another transport, one can still use the same semantics on either side. It also shows, that the notion of a FirmataBoard must not neccessarly be bound to RS232. With the encode/decoder nodes, that was simple to do and explain - think OSC nodes. The feedback with the capability report makes it a bit more complicated.

Foreign Function Interfaces (Foreign function interface - Wikipedia) would make up a convenience too call, e.g. C or C++, unmanaged code; I thought maybe there are plans to provide something directly in the VL spec rather than having another wrapper layer of .NET in between. But that is different discussion. The C# Wrapper would need maintainence as well.

10

thanks,
so you bring up the naming “StandardFirmata” vs. “FirmataBoard” again… regarding which we found the explanation by @soundanalogous above convincing that “StandardFirmata” is an arduino-related term which is not what we need to emphazise here. to my understanding e.g. a Teensy is another board that can load firmata and then will be working with our FirmataBoard node, right?

regarding tcp…your point is very well understood and absolutely supported by the modularization into FirmataEncoder and FirmataDecoder. so: check!

regarding FFI for VL: VL is .net, so there wouldn’t be much difference in the way you’d access the unmanaged firmata.dll from c# to how you’d access it from VL. both would need that wrapper.

11

little OT regarding VL:
adding P/Invoke (and maybe Marshalling) as a language-feature would be an even sportier task, i guess.
Is something like that somewhere on the roadmap for the brightest of all futures?

12

@soundanalogous and @jens.a.e:
The FirmataBoard (Devices) is now in the Alphas.
See Firmata Second Service.

13

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.