firmata / protocol Goto Github PK

It looks to me as if extended analog only covers analog write (PWM). How do you query or REPORT_ANALOG on pins greater than 15?

Also, the PIN_TO_ANALOG(p) macro is architecture dependent and not portable. It would be nice to have a generic way for it to do its job.

On the other hand, much of this complexity could be eliminated altogether if there were an extended analog reporting scheme and 0xC0 was deprecated in its favor.

Hello.
I've problem with FirmataStandard sketch. I've just upload the newest firmata version to my Arduino Lenardo on /dev/ttyACM0 port. Upload completed.

My host is: Linux Ubuntu 18.0.4 LTS 4.15.0-42-generic (with Lenardo on board - LattePanda).

Previously uploaded another sketchs (like blink, switiching and others without any problems).

For now my Arduino with Firmata I can't send and receive msg with baud 57600 (default), 9600 and others...

wk@WKALPHA:~$ ls -l /dev/ttyACM0
crw-rw---- 1 root dialout 166, 0 gru 19 16:26 /dev/ttyACM0

Mu user is in lock and dialout group but I can't send and receive msg to arduino.
There is no answer from Arduino using for example:
screen, tty, cu, tail on above port.
The same issue has Arduino IDE on serial monitor.
NodeRed also can't connect to Firmata on /dev/ttyACM0.

By the way Arduino IDE successfully founds my Arduino Leonardo on /dev/ttyACM0 port without any SN.

What is wrong with communication?

Wrote this out here as a wiki proposal, posted it to the devel list in Nov as well, but I'd like to get some conversation here where this might be more possible:

With the current digital message port, the host needs to reset or query pin state, then keep state in sync.

However with new implementations, like my BLE implementation, I dont want to force a reset on connect as BLE connects and disconnects possibly often. Instead Id have to do ~29 pin state queries to build an internal data structure, but thats hugely wasteful on an RF connection!

It also seems odd, anyway, to keep state which could get out of sync, when the board is already keeping state-- It can read its register settings any time!

I understand why the digitalmessage port was implemented like it was, it is clever to send 8 pins for 3 bytes. But in this scenario it can be equally or more efficient to send 4 bytes for 1 pin if it means we dodge ~29 pin state queries and config writes.
It seems like its time to have a digital message pin command in addition to the digitalMessagePort which could just move a single pin when state is unknown, or when you don't want to hold state in the host program.

We would have use up a sysex command

/* set digital pin
 * 0  START_SYSEX (0xF0)
 * 1  digital write pin (0x??)
 * 2  high/low (0x01)
 * 3  END_SYSEX (0xF7) (MIDI End of SysEx - EOX)
 */

Another option actually, is to put optional on digital message port

/* two byte digital data format, second nibble of byte 0 gives the port number (e.g. 0x92 is the third port, port 2)
 * 0  digital data, 0x90-0x9F, (MIDI NoteOn, but different data format)
 * 1  digital pins 0-6 bitmask port values
 * 2  digital pin 7 bitmask port values
 * 3  digital pins 0-6 bitmask pins you want to effect
 * 4  digital pin 7 bitmask pins you want to effect
 */

http://firmata.org/wiki/Proposals#Digital_write_pin_alongside_of_digital_message_port

http://sourceforge.net/mailarchive/forum.php?thread_name=1384757311.2919.16.camel%40norbert-ThinkPad-X61s&forum_name=firmata-devel

There are some filters / functions that operate on multiple samples of an analog input and that aren't really feasible to run on the host / computer side. For example, taking the amplitude of the audio signal coming in from a microphone, or the average of multiple samples of a noisy input, or taking the derivative of a quickly changing signal. It would be useful to have a way to process these functions on the microcontroller side.

I'm imagining that the host would specify a function (from a fixed set) and either a number of samples or a total time interval over which to take the samples. Then, I'm imagining that the data would be sent to the computer repeatedly, on the same interval used to report analog input values, until the function was turned off by the host computer.

What do you think? Is it worth trying to flesh this out in a proper protocol proposal?

Serial 1.0 does not scale well. Update to Serial 2.0 but with a different ID and this time allocate separate bytes for command and port.

Current:

0  START_SYSEX      (0xF0)
1  SERIAL_DATA      (0x60)  // command byte
2  SERIAL_CONFIG    (0x10)  // OR with port (0x11 = SERIAL_CONFIG | HW_SERIAL1)
3  baud             (bits 0 - 6)
4  baud             (bits 7 - 13)
5  baud             (bits 14 - 20) // need to send 3 bytes for baud even if value is < 14 bits
6  rxPin            (0-127) [optional] // only set if platform requires RX pin number
7  txPin            (0-127) [optional] // only set if platform requires TX pin number
6|8 END_SYSEX       (0xF7)

Updated:

0  START_SYSEX      (0xF0)
1  SERIAL2_DATA     (0x64)  // command byte
2  SERIAL_CONFIG    (0x00)
3  port             (HW_SERIALn OR SW_SERIALn)
4  baud             (bits 0 - 6)
5  baud             (bits 7 - 13)
6  baud             (bits 14 - 20) // need to send 3 bytes for baud even if value is < 14 bits
7  rxPin            (0-127) [optional] // only set if platform requires RX pin number
8  txPin            (0-127) [optional] // only set if platform requires TX pin number
7|9 END_SYSEX       (0xF7)

Firmata client authors should be able to implement this change without breaking APIs.

i'm having this issue in Node-Red both with the arduino node and the contrib-gpio node wich use firmata, and a raspberry pi. Tried also with Node-red on a pc and on an orange pi, same result.

Here's the thing:

I have a digital only board filled with RC circuits on every inputs. (12 of them on an Uno) and if i switch, say input 4, the GPIO node 4 gives "0" (true), that's normal, BUT, EVERY other GPIO nodes give 1 (false, wich is their actual state) so all the pins are reporting their state on state change of one pin.

the node says "It only outputs on a change of value", is this a bug or i'm doing something wrong here?

Thanks.

Over the past few days I've been implementing a node.js midi parser with the idea that it would serve as the firmata/midi parsing guts of another project I'm working on. I've noticed that the protocol version request is a system realtime command. Which is great, however, it seems the version report is the same command except with 2 data bytes?

This only concerns me because it seems none of the other midi realtime commands have any data bytes and that parsers will have to special case this on the host side. (We're calling the two sides, host and device, right?)

I'm aware 0xF9 is undefined in the midi spec so it can technically can do anything we want.

I just want to make sure my assumptions are correct.

Thanks!

In order to support a change from defaulting all pins to OUTPUT on startup, to defaulting to INPUT, we will need the ability to enable individual digital pins rather than entire digital ports.

0  START_SYSEX            (0xF0)
1  REPORT_DIGITAL_PIN     (0x63)
2  pinNumber              (0 - 127)
3  reportingEnabled       (0 | 1)
4  END_SYSEX              (0xF7)

Once this is in place, digital port reporting (0xD0) should be deprecated. The reason is that when the pin mode is set to INPUT (electrically much safer and should also fix issues users have with relays) rather than OUTPUT by default, non grounded pins (or pins without pull-ups enabled) will report stray voltages and DIGITAL_MESSAGE would report these as pin changes. When REPORT_DIGITAL_PIN is added, Firmata should not report a pin value for any pin that is not enabled (much like how analog pin reporting currently works). This will prevent reporting stray voltages as input pin state changes.

It should also use a single command ID. A new command ID can be allocated so the old I2C version can be safely deprecated.

Add a proposal to set the value of a single pin. This will only allow setting a single pin. It will not support reading a single pin because all pin changes are reported on each iteration of Arduino's loop function so it would be redundant.

// set the value of a single pin
0: 0xF5 (SET_PIN_VALUE)
1: pin number (0 - 127)
2: pin value (0 | 1)  

Proposal should be added to protocol.md.

It would be the responsibility of the firmware implementation to also update the port value and ensure that the correct pin mode is set (or no-op and report an error if the pin mode is incorrect).

Hoping someone who knows the protocols better can answer this because I could not find hte answer documented here: https://github.com/firmata/protocol/blob/master/stepper-1.0.md.

The max number of steps is recorded in the protocol (3 bytes send, only 21 bits used). Since there are only two bytes sent for speed/accel/decel, does this mean the max speed/accel/decel values are 16-bit or less?

There already exists the Pin State Query which reports the output state (which is also the value) of a specified pin. There is also a use case for querying input values - especially when using non-serial transports. The Pin State Query is also inefficient when reporting several pins since the query is on a per pin basis.

The following proposal adds the ability to query the values of a range of pins including all pins, all input, all output, all digital input, all analog input, all digital output and all analog/pwm output.

Reporting of input pins would simply report the input pin value via the existing DIGITAL_MESSAGE or ANALOG_MESSAGE commands immediately upon receipt of the query. This is already done per pin (or port) when analog or digital pin reporting is enabled, but this proposal extends the ability to report at any time the user requests it - especially useful in the event that the transport connection was reestablished.

Reporting of output pins could use the Pin State Query Response, iterating over the output pins and sending the response for each pin.

0  START_SYSEX        (0xF0)
1  PIN_VALUE_QUERY    (0x68)
2  type                0 = all pins, 1 = all input, 2 = digital input, 3 = analog input,
                       4 = all output, 5 = digital output, 6 = analog output / pwm
3  END_SYSEX

Some additional types could be pin (input & output), pin_input, pin_output and then the following byte would be the pin number. Not sure if this would actually be useful, but it could be added later if a use case arises.

Update the descriptions for enabling digital and analog reporting in the Control Message Expansion section of protocol.md to include a note the when reporting is enabled that corresponding port (digital) or pin (analog) value should immediately be sent to the client application.

Presently, the only way to get the value of a digital port or analog pin is by setting it to report. This is very efficient, but in several cases this constant flow of data may be more of a hindrance than a help. For example, here is a large discussion on this: firmata/firmata.js#127

I propose a new set of commands to handle a single read of a pin/port. The microcontroller could report the data in the same format that it presently does, using the 0xE0 and the 0x90 blocks. For the host, I have two potential commands in mind:

1. Using a single byte. This would implement the 0xA0 and 0xB0 blocks to request an analog pin or digital port, respectively. For example, to request the value of analog pin 2 the host would send 0xA2, with no additional byte.
2. Using two bytes. This would use 0xF2 for an analog read and 0xF3 for a digital read. The second byte would specify the desired port/pin. For example, to request the value of digital port 1 the host would send 0xF3 0x01

I already have working code with StandardFirmata.ino for testing. This was a quick port, so it uses the 0xA0 and 0xB0 blocks but then requires an additional byte (it can be anything). That pull request can be found here: firmata/arduino#377
This was tested using a small python script. I can upload and maintain that as well if anybody requests it.

The current version of Stepper has a number of limitations. It should be updated to better meet common uses cases. A separate command byte (TBD) can be used to safely deprecate the old version.

• Remove speed params in step
• Remove speed params in to
• Change set maxSpeed to speed (Stepper2 will figure out wether to use AccelStepper's setSpeed or setMaxSpeed command automatically, based on the current acceleration value)

I believe speed will rarely need to be passed in a step or to call and probably should be done in a separate command. I had put it in to match the existing stepper_step command, but given that this is a complete rewrite I think it's okay to drop it.

It would be helpful to have a way to query the transport buffer size. This is typically 64 bytes for Serial, but can vary based on board architecture. The buffer size for other transports such as BLE and TCP may vary as well. The size is typically exposed as a constant in firmware so it should be possible to provide a Firmata message to query the size. This will be helpful for client libraries in determining where to break up large data buffers prior to transmission.

Szenario to be addressed:
Arduino is connected by other means than serial and connection drops and reconnects. There's no way to know whether firmata did reset while being disconnected. To ensure synchronized state between firmata and host the host has to reinitialize all pins and features.

What is needed is some kind of session-token that can be both used to query whether firmata has been resetted (which would invalidate the session-token on firmata-side) and to signal firmata became uninitialized (either by physical reset or other means like watchdog).

This is related to:
#3
firmata/arduino#102

Yesterday we were trying to perform an I²C read request with @bhagman and we couldn't find the way to specify a register.

As specified in the protocol:

0  START_SYSEX (0xF0)
1  I2C_REQUEST (0x76)
2  slave address (LSB)
3  slave address (MSB) + read/write and address mode bits
     {bit 7: always 0}
     {bit 6: auto restart transmission, 0 = stop (default), 1 = restart}
     {bit 5: address mode, 1 = 10-bit mode}
     {bits 4-3: read/write, 00 = write, 01 = read once, 10 = read continuously, 11 = stop reading}
     {bits 2-0: slave address MSB in 10-bit mode, not used in 7-bit mode}
4  data 0 (LSB)
5  data 0 (MSB)
6  data 1 (LSB)
7  data 1 (MSB)
...
n  END_SYSEX (0xF7)

Are we missing something or is the protocol lacking a register field?

SAMPLING_INTERVAL?

Although not strictly limited by the Firmata protocol, currently Firmata implementations allow writing values to analog pins > 15 or analog (pwm) values > 14 bits using the EXTEND_ANALOG message. Reading analog input pins > 15 and/or analog input values > 14 bits should also be enabled.

There are a couple of options:

1. Use EXTENDED_ANALOG to report both analog input and analog output values:

0  START_SYSEX              (0xF0)
1  extended analog message  (0x6F)
2  pin                      (0-127)
3  bits 0-6                 (least significant byte)
4  bits 7-13                (most significant byte)
... additional bytes may be sent if more bits are needed
N  END_SYSEX                (0xF7)

2. Create a separate message for reporting analog input values and repurpose EXTENDED_ANALOG to only report analog output (pwm) values (as it has traditionally been used):

0  START_SYSEX              (0xF0)
1  extended analog write    (0x6F)
2  pin                      (0-127)
3  bits 0-6                 (least significant byte)
4  bits 7-13                (most significant byte)
... additional bytes may be sent if more bits are needed
N  END_SYSEX                (0xF7)

0  START_SYSEX              (0xF0)
1  extended analog read     (0x66)
2  pin                      (0-127)
3  bits 0-6                 (least significant byte)
4  bits 7-13                (most significant byte)
... additional bytes may be sent if more bits are needed
N  END_SYSEX                (0xF7)

In either case, this would be accompanied by the ability to enable analog input reporting on pins > 15: #68 (comment)

Hello, I'm implementing Firmata parser and have some questions regarding extending sysex format:

1. Which byte order is assumed?
   In (00 12 34), (12) is low 7 bits of ID or high?
2. What if extended ID matches one-byte ID?
   Assuming low-byte-first, consider (69) vs (00 69 00).
   Is it same ID? Should such duplicates be forbidden or allowed?

BTW in feature-registry.md sysex extended ID bytes 2..n described as

EXTENDED_ID (00H 00H - 7FH 7FH) + PAYLOAD

I think it should be

EXTENDED_ID (00H - 7FH 00H - 7FH) + PAYLOAD

Best wishes.

Based on my particular use case - using moisture sensors (see this Soil Moisture Sensor Hookup Guide) - and some other issues opened here and at firmata.js, I propose we enable the possibility of individual reporting intervals for each analog pin being reported. The current behavior (reporting all at the sampling interval) can still be the default and even simultaneously present, which means that some pins may have separate (longer) reporting intervals and some may be reported in the main loop at the global sampling interval.

For that to happen, a new message is required. I can see 3 alternatives, which I open here for discussion:

1- Updating report analog pin (0xC0) to use the first and second byte to pass the reporting interval;
2- Piggyback on the proposed EXTENDED_REPORT_ANALOG (SYSEX 64H) and use the bytes after the pin number to set the reporting interval;
3- Create a new SYSEX feature used specifically for this, maybe called ANALOG_REPORT_CONFIG.

1 is simple but a breaking change that would have to wait for v3.0.

2 seems to be a good balance, but I'm not sure why EXTENDED_REPORT_ANALOG and what are the challenges there, so could be a blocker. Also, I only have Unos and Nanos, so I wouldn't be able to test the extended port range.

3 is fine too and could be expanded to include more settings, like a linked digital pin to power the analog sensor only when the reading is done and/or a custom delay (see this thread).

We currently have the capability query to return pin-based capabilities that sorta serves this function. An improvement however would be to add a separate query that returns the features supported by the firmware. This would open up the ability to version features separately.

Of the existing pin modes, I'd consider the following as "features" since they require multiple pins in some cases and/or represent a feature that is not integral to the microcontroller HW:

• SERVO
• I2C
• ONEWIRE
• STEPPER
• ENCODER
• MODE_SERIAL
• SHIFT (even though it has never been implemented)

And the following as "pin modes" since the represent supported modes of a given pin:

• INPUT
• MODE_INPUT_PULLUP (new)
• OUTPUT
• ANALOG
• PWM

Adding the ability to version features separately would enable updating features without requiring a bump to the protocol version. For example if the Firmata I2C implementation needed to change in a backwards compatible way (to support multiple I2C ports for example). Otherwise the protocol major version would need to be incremented each time a feature is changed in a non-backwards compatible way. It would also enable adding new features that are sysex-based without needing to update the protocol version since the new features would report their own versions. This creates a separation from the higher level Firmata core protocol and the extended feature-level protocols.

A major change (Firmata 3.0) would be to create a separation between "pin modes" and "features". But even before 3.0 it would be possible to start reporting Features and their versions separately via a new feature query. This also enables versioning of features without needing to add anything new (to query version) to existing implementation of existing features.

Here's an initial proposal:

0  START_SYSEX                (0xF0)
1  REPORT_FEATURES            (0x62)
2  1st FEATURE_ID LSB         either a "pin mode" or the subcommand byte
3  1st FEATURE_ID MSB         use 2 bytes to ensure scalability
4  1st FEATURE_MAJOR_VERSION  (0-127)
5  1st FEATURE_MINOR_VERSION  (0-127)
6  2nd FEATURE_ID LSB
7  2nd FEATURE_ID MSB
8  2nd FEATURE_MAJOR_VERSION  (0-127)
9  2nd FEATURE_MINOR_VERSION  (0-127)
... for all supported features
n  END_SYSEX                  (0xF7)

For StandardFirmata this would return the following features:

• SERVO
• I2C

For StandardFirmataPlus it would return the following features:

• SERVO
• I2C
• MODE_SERIAL

For ConfigurableFIrmata it could return any variation, same for other "firmatas".

Currently Firmata uses string messages to report errors. This is not efficient in that strings consume precious RAM and has thus limited the amount of error reporting that is possible. There have been discussions around this in the past: firmata/arduino#80

I think the best approach is an enumeration of error codes such as used in the Linux/c errno.h and errno-base.h files: http://www.virtsync.com/c-error-codes-include-errno

The task here is to define a similar file for use in Firmata that covers Firmata-specific error cases as well as general error cases (the general error codes could even be copied from the errno.h and errno.base.h files where appropriate).

The Arduino Zero has 1 10-bit DAC pin. Draft a protocol to add DAC support to Firmata.

The current Servo interface uses the Firmata Analog message to set it's value. This creates tight coupling between ServoFirmata and AnalogWrite and AnalogOutputFirmata.

We need a new Servo interface that uses Sysex. Does anyone have an opinion on changes to the existing firmata servo interface?

On both the www.Firmata.org wiki and this documentation, I can not find what the different pinModes are.
The closest I can find is at the bottom of the Firmata.org wiki where it says:

/* set digital pin mode
* --------------------
* 1  set digital pin mode (0xF4) (MIDI Undefined)
* 2  pin number (0-127)
* 3  state (INPUT/OUTPUT/ANALOG/PWM/SERVO, 0/1/2/3/4)

However, looking at my responses I see a 6. I also know there are other pinModes supported, such as 1-Wire.

As a more general issue I can't tell where I should go to find good documentation. Here, which looks "fresher" or www.Firmata.org which looks more complete. Is there a plan in mind to move the documentation here?

https://github.com/firmata/protocol/blob/master/i2c.md#i2c-config

My use case it to control a Dynamixel servo which uses Half Duplex Serial. The solutions I've found online use a tri-state octal buffer and a single digital pin to control data direction. I can add an expander in Johnny-Five that adds the direction pin and wraps existing serial but I want to make sure that direction pin doesn't belong in firmata.

Thoughts?

http://firmata.org/wiki/Proposals

This was a proposal I had made in a thread a while back. Copying it here so it doesn't get lost.

0  START_SYSEX
1  SEND_PULSE (command ID TBD)
2  pin (0 - 127)
3  units (ms | us) | (start high | start low)
4  pulse1 length (bits 0 - 6)
5  pulse1 length (bits 7 - 13)
6  pulse1 length (bits 14 - 16)
7  pulse2 length (bits 0 - 6)
8  pulse2 length (bits 7 - 13)
9  pulse2 length (bits 14 - 16)
... as many pulses as necessary up to MAX_DATA_BYTES
N  END_SYSEX

Something like this could be useful where precise pulse widths are needed on the microcontroller side (something impossible to do purely from the client side). However this proposal needs more thought. Could specify varying high and low pulse, number of times to repeat, etc.

Currently, there is no way of knowing whether the system received or performed the requested reset.

Are there protocol.md files for Firmata Protocol versions greater than 2.4?

Thinking it would be cool if we kept some documentation around of SYSEX commands people are using. Things such as the codes for neopixel interaction in node-pixel or the accelerometers in playground-io.

No set in stone registry, just documentation on what's being used to help avoid collisions or give guidance on implementation for new hardware.

This is different from the rest of your calls, because it puts the same key that was used to invoke it back on the wire. Same goes for protocol versioning.

It's possible to work around, but it tripped me up, so I thought I would call it out.

based on this discussion: firmata/arduino#257 (comment)

Would it make sense to use the otherwise unused (in most firmata devices) EEPROM as a simple key-value store?

I had augmented the Interface byte a while ago in the FirmataStepper implementation to allow the user to specify an alternative step delay interval (2us rather than the default 1us interval). However I never updated the Stepper protocol to reflect this... doh! This is the code that was added to FirmataStepper:

https://github.com/soundanalogous/AdvancedFirmata/blob/master/FirmataStepper.cpp#L88-L97

There is in existence sets of intelligent LEDs known commonly as NeoPixels but more properly as WS2812 and similar numbered devices. These LEDs have extremely intricate timing requirements and can not be natively driven by OS's that have pre-emption capabilities such as Windows and Linux. The Raspberry Pi for example can not drive them directly. There are Arduino and ESP8266 libraries that can.

What this issue suggests is the creation of a new protocol extension to be able to drive these LEDs. To set the color of an LED, we send in 24 bits of information. 8 bits for the red, 8 for the green and 8 for the blue. Since one can daisy chain these LEDs together, the suggestion is for the protocol to take as data the following:

2 bytes - count of LEDs - allowing up to 65535 (we do have chains > 255 so 1 byte is insufficient)
3 bytes of RGB data * count of LEDs

If we believe that this notion has merit and would notionally be accepted as a submission ... then I for one will be happy to go to the next level and write up a detailed neopixel-proposal.md file. However, before I spend time on that, I wanted to get a "pulse" on the acceptability of such a submission. If it holds no merit or is otherwise outside the strategy of Firmata then that will be that.

Neil

via conversation with @ajfisher on gitter:

There was a pull-request for SPI opened a while back: firmata/arduino#135. However, it's going to be more complex than just wrapping the Arduino SPI api (since that would be inefficient). Lets start by drafting a protocol here: https://github.com/firmata/protocol.

My initial thoughts are that it should have a SPI_CONFIG message (like I2C and many other features in Firmata). The config message should let the user specify the following:

CS/SS pin (this is also how you'll keep track of multiple SPI devices)
bit order (LSB or MSB first)
data mode (see the 4 modes defined here)
clock divider? (I'm not sure how this would work in Firmata or if it even applies... I think it depends on if a hardware enabled SS pin is selected on the board)
We'll need a way to call SPI.begin and SPI.end. I'm not sure if it's better to call begin when the config message is received or if there is any advantage in having it be a separate command. SPI_END can be a simple message to call SPI.end, perhaps also specifying the CS pin to be compliant with Arduino Due's extended SPI protocol (for other boards this parameter would simply be ignored in the implementation).

We'll need a SPI_REQUEST message. It should contain the CS/SS pin number and the data to be sent via SPI.transfer(val) on the board. It will be more efficient to send multiple bytes rather than a single byte (this likely also depends on the particular device) - so in the implementation you'd call SPI.transfer(val) multiple times for a single SPI_REQUEST rather than sending a separate Request for each byte). We'll need a strategy around buffering as well (more for the implementation than the protocol). It will be helpful to look across a variety of SPI devices to see what what type of data is sent... what would constitute a "packet". Be aware however of the 64 byte serial data buffer on Arduino since this will likely come into play. It would also be helpful to support a READ_CONTINUOUSLY mode like I2C Firmata (this is especially useful for SPI-based sensors).

And we need a SPI_REPLY message to send data back the the Firmata client. This should include the CS pin, maybe the number of bytes in the reply and whether or not this is the full packet (or if it's broken up into multiple packets). Perhaps this is as simple as indicating if this is the LAST set of data.

Also try to support Arduino Due's extended SPI feature as an option. You'd add this to the protocol for SPI_END and SPI_REQUEST (although I'm not sure how beneficial this extended set would be in a Firmata client library... may add more complexity than it's worth). This is lower priority.

Hello!

I recently became aware of Firmata and have been enjoying using it for Raspberry Pi 3 <-> Arduino* communication over the past couple of months. [* Ether10s and EtherMegas, firmata.js on the Pi's ]

In an effort to reduce power consumption I would like to replace the Ethernet transport layer (and related router/shield infrastructure) with CAN infrastructure. I'm happy to develop that software component for the Arduino and NodeJS stacks; just curious if anyone else has already explored/implemented it or has tips to offer.

Relatedly, is there already existing or is there any interest in using a Firmata Slack group? .. or perhaps just a channel in the NodeJS group ( joined via http://www.nodeslackers.com/ ).

Thanks!

Feel free to close this, or I shall, once most of the active Firmata developers/enthusiasts have a chance to chime in on CAN thoughts.

Out of curiosity, I am wondering why midi message format has been chosen for communication. What are the advantages of using it and is there any limitations ?

Regards.

for some reason the string message was never documented in protocol.md

The firmata should have a China name? Why ?

• Firmata is so good for mcu.
• In the future China, MCU chip should do with knitting socks almost universal :).
• I want introduce the protocol to China maker community and MCU Factory.
• The firmata should have a China name.冷杉脉络, 符合信、达、雅.

Other Examples

• Exam1: The arduino to now there is no Chinese name, so many people do not know arduino.
• Exam2: The android's Chinese name is the name of 安卓, was also called early 安智, 安致, etc., with the Chinese name before lets more people know.
• the git Chinese Name: 改塔、吉塔、鬼塔 . https://github.com/osokay/gitDialect

proposed:

// query
0  START_SYSEX              (0xF0)
1  SAMPLING_INTERVAL_QUERY  (0x7C)
2  END_SYSEX                (0xF7)

// response
// same command (0x7A) as setting the sampling interval but this is ok because
// the following is sent to client rather than sent from client
0  START_SYSEX        (0xF0)
1  SAMPLING_INTERVAL  (0x7A)
2  sampling interval on the millisecond time scale (LSB)
3  sampling interval on the millisecond time scale (MSB)
4  END_SYSEX          (0xF7)

Because Firmata and ConfigurableFirmata diverged a few years ago, they have different version numbers. However as far as the protocol is concerned they should be equal (in that both versions of Firmata are based on the same protocol - it just so happens that ConfigurableFirmata supports more features). I'm not sure how to fix this mess other than maintaining separate versioning for the protocol, the StandardFirmata implementation and the ConfigurableFirmata implementation.

The issue is that features may be added to the protocol and an implementation in ConfigurableFirmata but not implemented in StandardFirmata, this the need to bump the version in the protocol and ConfigurableFirmata but not StandardFirmata.

Open to ideas here if anyone has any.

Greeting. I detected a problem when trying to sweep all posible angles in servo mode. The problem is that, for extended analog, the value 128 is wrong.
I'll attach a file with the values received in the client when gently moving the slider to obtain all the values in the range (and i did it several times to verify that it was no coincidence). I used Device Monitoring Studio to sniff the port.
servo message analysis.txt

So, i used pin 16 (0x10) to test the mode and when i went from 127 to 128 i got:
F0 6F 10 7F F7 (message for 127)
F0 6F 10 00 F7 (message for 128) <-- this should be F0 6F 10 00 01 F7

Snap solves this problem by sending a fixed lenght message for each value:
F0 6F 10 7F 00 F7 (message for 127)
F0 6F 10 00 01 F7 (message for 128)

I hope this helps, and any query is welcome.

I have a NEMA 17 step motor. The motor moves quickly when I use a 50µs step delay using a standard arduino IDE step motor sketch (aka turn pins on and off with a microseconddelay()). However when I use configurable firmata (with Digital Inputs, Digital Outputs, Analog Inputs, Analog Outputs, Stepper, Serial, Encoder, and Reporting) with the default 1µs delay, the step motor moves relatively slowly.

I believe that this is probably due to the time required for Firmata to go through one loop. Am I correct in thinking that the "real step delay" = "default 1µs delay" + "time required to complete one loop"? And if so, is there any way to decrease this delay to make it closer to 1µs.

It would be nice to have a Firmata host side implementation for Linux. There are plenty of SBCs running Linux that could benefit from it. Few immediate ones that come to mind:

Raspberry Pi
CHIP
VoCore2

By leveraging GPIO and Device Tree facilities the host can probably even auto configure itself.