Arduino Firmata

Does anyone have a working version of the Firmata Library for Spark Core? Serial/USB would be fine, but later TCP support would be awesome. If there isn’t a library yet, I might look at porting it over when I get a chance - but it might be a while.

http://firmata.org/wiki/Main_Page

1 Like

@Blake, I started porting the library to use I2C but lost interest when I saw this VoodooSpark library. :smile:

3 Likes

VoodooSpark looks great, but I really need something that is a bit more generic to all arduinos. I’m trying to collect data from running arduinos, and use it to visualise whats happening. So I really only need to receive data for now. I was hoping to get serial working, and then look at using TCP using Firmata.

@peekay123 How far did you get with porting it over? Did you manage to get the protocol to compile?

@Blake, I am not sure I understand. You want to run Firmata on your Arduinos and collect data on a Spark? If so, why do you need a port for the Spark?

I’d be collecting data locally (over usb, or lan/wifi), processing it, and then visualising it using javascript. Standard arduinos already work with the firmata library, but because the Spark Core has built in wifi it could collect the data cable free. I was hoping to pipe Firmata on the Spark Core over a TCP connection.

Something like this video would be the same idea Seeing Space

I have a mostly working port going. Mainly I was waiting for the memory patch and now Ive been waiting for the TI patch to get back to working on it.

2 Likes

I’ve ported Firmata 2.3, and have it compiling locally. Currently I only need access to the library (and not StandardFirmata), so I don’t plan to port the RPC examples.

Right now I have Firmata.begin(); and Firmata.sendString("Hello World"); working, and I’m sure a lot of the other commands should work fine (pending further testing). Once I’m able to play around with it a bit more, I’ll put it up on Github.

The code is now available on https://github.com/blakejakopovic/firmata-spark. You can use the same Firmata.cpp/h files for local compiling (but you’ll need to edit the build.mk file as well).

I’ve included examples (available https://github.com/blakejakopovic/firmata-spark/tree/master/firmware/examples) that work for Serial and TCP connections.

Please note that the port has not been tested extensively, and you may have problems. The example code for TCP can likely be significantly improved, and I am sure it will greatly benefit from the CC3200 deep patch coming soon.

I’ll make the library public in the Spark IDE after a bit more testing. Please give it a go if you’re keen and let me know how it goes. You can just copy and paste the firmata-spark.cpp/h files into the Spark IDE and remove the include path for the header file for testing.

What about a TCP Firmata TCP server? Well, I am working on getting support in the clj-firmata clojure library, and I’ve been testing it on a simple ruby TCP server (which I plan add to the repo soon).

3 Likes

@Blake
This is a great effort you’ve made with the firmata library. :smiley:

Just a heads-up that I’ve been developing a non-firmata solution to allow flexible configuration and control of the embedded devices: https://community.spark.io/t/flexible-sensors-actuators-and-controllers-application/5254

Compared to firmata, I think the key differences are:

  • higher-level - the device can be configured with device drivers (onewire temp sense, humidity etc. etc…) so reading is not limited to analog/digital pins
  • persisted configuration: the details of the setup are persisted so the device continues automatically
  • autonomous control: device can be configured to run various control loops

I’m sure you know firmata a lot better than I do (I’ve never used it, just glossed over the manual.) Do you think there is a point to being able to use my controller framework with firmata, say, by adding support for the firmata midi protocol?

(And by all means reply in the other thread, sorry for hijacking this one!)

1 Like

@mdma I’ve only been using Firmata for a couple weeks. When I started the project, I looked for other protocol implementations, and Firmata stood out as a clear winner. Mostly because it supports all standard Arduinos, is light weight, and easy to extend. I considered a custom protocol, but I didn’t see a need.

Firmata has a command type called sysex which allows custom messages of arbitrary length. This does come at the cost of having to pack data into 7 bit bytes of two parts (msb/lsb). But the flexibility is a huge win. Keep in mind custom commands require implementation on both side of the communication.

One more cool thing is that Firmata supports a Stream object on initialization, so you can communicate over serial, udp, tcp, bluetooth serial, XBee and even Websockets - with something like 3 lines of code.

I really can’t say if you’ll benefit, but I would take a closer look. It might help you to simplify your code, or make it easier to extend. Or you might get some ideas on how to improve your current design.


My primary goal is to create a real-time dashboard to help visualise/test/debug running Arduino code. The Firmata protocol is really great, and easy to extend with a simple API, so it fits my needs well.

With this in mind, I don’t really need to remotely control the arduino - as all data is sent from the Arduino to a collection device (likely a computer). I am very interested in the possibilities of adding remote control support later, as well as allowing the Arduino to receive simple commands.

As an example, here would be the code needed to show temperature and humidity data in a real-time dashboard. TestDrive is the codename of the library I’ve been writing that extends the Firmata protocol.

#include "TestDrive.h"

#include "DHT.h"
DHT dht(10, DHT22);

float temp;
float humidity;

void setup() {
  TestDrive.begin();       // using serial
  dht.begin();
}

void loop() {
  temp = dht.readTemperature();
  if (!isnan(temp)) {
      TestDrive.sendTemperature(temp);
  }

  humidity = dht.readHumidity();
  if (!isnan(humidity)) { 
      TestDrive.sendHumidity(humidity);
  }
  delay(1000);
}

Basically, you just need to add three lines of code to get it working.

#include "TestDrive.h"                          // top of sketch
TestDrive.begin();                              // in setup()
TestDrive.sendTemperature(temp);                // call whenever you need

And then you would automatically get a dashboard that shows live data; likely packaged into an app, but it would be using javascript and html internally. (Note that the image below is using simulated data)

1 Like

Thanks for the details. My key interest would be in leveraging the existing apps for the fermata UI, having a fermata protocol layer would allow me to do that. (Regarding the design, I’m already using streaming extensively - not only for external I/O over serial/tcp etc… but also internally - commands are executed form streams and also streamed to eeprom. Streaming keeps memory usage to a minimum.)

It seems our frameworks have similar goals - easy setup of sensors and devices with monitoring and control, although I’m aiming for users to not have to write any code for the common use cases, since the function is configured at runtime. At the minute it’s the firmware that is this flexible, but it will be extended out to the service layer and to the UI so the whole stack is completely pluggable, allowing non-programmers to build embedded-device solutions.

1 Like

@mdma I haven’t found any Firmata UI apps, other than a test application called Firmata Test (has screenshot). I think you might find benefit in the number of programming languages with Firmata libraries (see Firmata Host Support). This also helps other people extend your project and experiment more easily.

The problem I have with runtime configuration is that I want to allow people to embed this into their existing arduino projects. I hope to support runtime commands and configuration as well, but I also need to support the case where the arduino is not just a dumb terminal, but someones project. However, I do plan to create some kind of StandardTestDrive sketch that will allow runtime/remote commands to work.

What kind of UI were you hoping to include? Brewpi is nice real world application, so I’ll look into how it all works some more, and see what kind of things it could benefit from.


Depending on which experiments work while I am working on the dashboard (in javascript/clojurescript), you may be able to use certain parts in your project. I am looking to support the following kinds of sensor outputs

  • sendDigital(s)
  • sendAnolog(s)
  • sendTemperature(t)
  • sendHumidity(h)
  • sendPressure§
  • sendAnemometer(s) // wind speed
  • sendAltitude(a)
  • sendRelay(state)
  • sendRGB(r,g,b)
  • sendLux(l)
  • sendPWM(duty)
  • sendVector2d(x,y)
  • sendVector3d(x,y,z)
  • sendGyroscope(x,y,z)
  • sendCompass(x,y,z)
  • sendAcceleration(x,y,z)

A few other ideas are Time, Date, Datetime, Decibels, RGB Strips, Proximity, Voltage, Current, PPM (air quality), pH, Fan speed, etc. I plan to make it extensible, so people can customise and add their needs (and hopefully contribute back to the project). I might actually base it more closely off the Adafruit_Sensor library.

Each type would then have some custom widget that can appropriately display its current value, as well as historical data over time (often with graphs, and likely some basic min/max/mean stats). I see no reason (other then performance), that it can’t be used many in real applications, and not while just testing or debugging. And with a server logging all the data, it will allow long term statistics and analytics.

Just a heads up that my macbook is in for servicing, so any updates will be on hold for a week or so.

I’ve solved some of the problems on paper, and worked out my game plan going forward. I don’t see any major issues going forward for the initial release. Still no ETA.

1 Like

@Blake I found your work to be something of a re implementation than a port. I dont want to maintain firmata so my hope is to make as few changes as possible and push them back upstream to firmata. Because of this I have my fork up at

If you guys support the project feel free to say so in the pull request at firmata

@mdma Your work looks cool but it seems theres reason to do the asbtraction one layer up. Johnny five is doing exactly what you’re doing, but JS guys want the abstraction at their layer… Time will tell

1 Like

@jjrosent Nice. Pushing support upstream is by far the best outcome, so I’ll be sure to comment on the PR.

When I first started porting the Firmata library, SPARK was not yet defined in the release firmware, so I opted to just comment out #include "boards.h". I only ended up adding around 4 lines, and commented out a few. So it was actually a hack-ish port just to get it working, while waiting on dependencies to push required changes. I can see how it looked like a port; by converting it a Spark Web IDE Library format, I also broke git diffing.

The project I am working on extends the Firmata sysex commands, so I’ll be able to use your version. Thanks :smile:

Let me also say my goal will be to get firmata as a library in Spark but I need support on this pull request for that so we can port existing arduino repos to spark libraries

1 Like

@jjrosent Sounds good. I don’t think there’s much we can do on our side; the changes require the Spark team to add support to the Web IDE library.

We’ve been officially forked (for better or worse, id like to stay in main brach frankly) over to https://github.com/firmata/spark

Take a look and help test! :smile:

Todo

1 Like

Dose this work with photon and servos