As part of my work for brewpi, I created a framework for the Arduino/Spark that is basically a object container that you dynamically configure at runtime ithings you want it to manage. Ok, that sounds pretty abstract - so, what does it do?
For example, you can set up various types of sensors (temp, humidity, pressure etc.), actuators (e.g. digital pin, OneWire 2413 etc…) and various local control loops (e.g. keep this temp sensor in range by activating these head/cool actuators.) The key thing is that this setup happens at runtime - you don’t have to write code to make this happen.
The key motivation is flexibility - rather than having to write code and upload a sketch to instantiate the sensors you want and configure the pins etc…, then log data at a set interval etc., all of this is managed at runtime using the same standard sketch. Since the device is configured at runtime, we could have a webapp that allows you to click “add temp sensor” - you then plug in a new temp sensor to the bus and it then added to the managed devices.
Some other highlights of this framework:
- small - the core framework is around 12K of flash on an arduino, and can be made smaller with removal of optional features (e.g. system profiles, multiple control loops.)
- supports regular logging of data - the value of each object can be logged at regular intervals.
- all configuration data is persisted, so once configured, the system continues behaving that way until you change it, even after power off.
- easy to add new types of objects - there is a simple API your object needs to implement to fit in with the system.
- supports multiple control loops, with each loop executing with the specified period (e.g. every second)
- supports system profiles: the same device can be put to use in different ways by storing each configuration as a profile. The profiles to run can selected and changed at runtime.
My goal is to put an end to the need to write code when wanting to configure a spark/arduino for monitoring and control tasks - so that non-programmers don’t have to get involved compiling and uploading firmware. With this framework uploaded to the spark, users could then forget about coding and focus on connecting and configuring the devices they want to control. For example, when paired with Temboo, there would be no need to upload the sketch - the Temboo webapp could configure the spark directly, and changes would not need to interrupt monitoring, as would be the case with flashing new firmware for each change.
I hope I explained this well enough. How does this sound? Let me know if this sounds interesting to you