-
Notifications
You must be signed in to change notification settings - Fork 152
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Concept of FIRMWARE_RESPONSE
is not distinct from REPORT_FIRMWARE
#74
Comments
Yep, same issue with PROTOCOL_VERSION. These are things I intend to clean up in Firmata 3.0. |
Have you given thought to how you intend to handle it? I would like to program against it (roughly), if you have an idea. Will there be additional control byte(s), or will it follow the firmware sysex response model? |
I noticed it because the version callbacks only work well enough to preserve the original FirmataClass implementation, but are insufficient for a final solution. Since the request/response is ambiguous, the callback simply notifies that a version request has been made, but does not indicate any version information that may have been passed. Here are the response callback related signatures I had considered for my work: typedef void (*versionResponseCallbackFunction)(size_t major_version, size_t minor_version, char * name, void * context);
void attach(uint8_t command, versionResponseCallbackFunction newFunction, void * context); |
For the firmware protocol message, I could allocate a separate ID for query and response, keeping the existing ID for response and allocating 0x74 for the query. I had some thoughts regarding the protocol version here: #1. There is a separate issue there as well in which 0xF9 throws an error in webmidi since it's a reserved sysex command byte. |
TODO: add new |
@soundanalogous out of curiosity, why did you choose to use midi protocol and want to be compliant with it? |
Midi was chosen for simplicity. That was back in 2006 or 2005 when Firmata was initially created. I was not involved with the project at that time. The reason I've been maintaining midi compliance is so that Firmata client libraries can make use of existing midi parsing libraries as a convenience. In Firmata 3.0 we may break this rule. |
Fair enough. Is there a doc somewhere to see what's coming in Firmata 3.0? |
We need a doc. So far there are just some milestone tags, but it's not up to date and is spread across the firmata/protocol repo and the firmata/arduino repo: https://github.com/firmata/protocol/milestone/2 Not definite timeline yet either. The core contributors have been slammed with regular day-to-day work. Once we all find time to converge on a plan we'll have a better sense for a 3.0 timeline. |
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.
The text was updated successfully, but these errors were encountered: