firmata-devel

[Firmata-devel] Bickering about Firmata...

[Tim B. <a28...@gm...>]

Hi,

I've been trying to port firmata to Anykey (www.anykey0x.de) and I've been
running into a couple of problems, that mainly deal with the protocol
description on the wiki that I wanted to share. I assume the wiki page is
supposed to be a "definitive" page and don't feel comfortable changing it.
(Don't worry, won't argue about the PROs and CONs of MIDI ... :)

Hope I don't come across as too negative, I'll be as constructive as
possible and am happy to help implementing suggestions I make ...

* in general, the protocol description in the wiki describes the syntax of
all the messages, but it's not clear what the messages actually mean, and
what the are meant to do. It may help to just add an introductory section
that explains the purpose of the protocol.

* SET_PIN_MODE : there's no real indication of what any of the modes
actually mean, e.g. SERVO? PWM? what sort of values would these modes be
expected to handle?

* PULL_UP: apparently writing a bitmasked one to a pin configured as INPUT
sets the internal pull up, but this isn't mentioned anywhere in the
protocol description. Also, it's very Arduino specific (e.g. the LPC1343 we
use supports PULL_DOWN and REPEAT as well)

* protocol flow: there's no indication of the expected flow of the protocol:
   - apparently, the embedded client is supposed to wake up and send a
REPORT VERSION and REPORT FIRMWARE message, but this isn't specified.
   - generally: who's in charge? What messages can be sent from which side
in response to which other messages or in response to some event.
   - the client is supposed to send a continuous stream of ANALOG_IO,
 DIGITAL_IO messages (anything else?), but this isn't specified, also not
the rate at which the sampling should take place. (StandardFirmata does
19ms ...) There's a message to configure the sampling interval... Should
the client wait until such a message is received?

* firmata-test UI : since this is kind of the "reference implementation" at
least on the host side, or at least is featured as such, it would be nice
if it could be better maintained, or at least be more accessible: make it a
project on github. It's fairly buggy, and it doesn't have a good build
setup (lots of values are just hard coded in the makefile) I couldn't get
it to build at all on OSX... It would be nice to expand the client to have
some sort of debug view, where one could see the bytes being sent and
received.

* no central point of discussion, this mailing list doesn't seem very
active, but sourceforge mailing lists are not that great from the interface
and don't really invite interaction (this may be a good thing!)

Thanks for listening!
   -tim

Re: [Firmata-devel] Bickering about Firmata...

[Hans-Christoph S. <ha...@at...>]

Yes, the docs could be better, and yes, they are quite Arduino centric.  No
one wants them to stay that way, its just a matter of someone doing the work :)

If you want to understand the meaning of the messages, check out the Arduino
programming reference.  The messages were modeled after those functions.  The
pinMode message is a good example.  The SERVO pinMode does what you'd expect
it to: it sends out the servo PWM signal based on the message data.  PWM does

I think you're best bet is to look at examples of how everything is used.
There are lots of different Firmata implementations, so you should be able to
find one in a language your comfortable in.

.hc

On 07/09/2013 07:07 AM, Tim Becker wrote:
> Hi,
> 
> I've been trying to port firmata to Anykey (www.anykey0x.de) and I've been
> running into a couple of problems, that mainly deal with the protocol
> description on the wiki that I wanted to share. I assume the wiki page is
> supposed to be a "definitive" page and don't feel comfortable changing it.
> (Don't worry, won't argue about the PROs and CONs of MIDI ... :)
> 
> Hope I don't come across as too negative, I'll be as constructive as
> possible and am happy to help implementing suggestions I make ...
> 
> * in general, the protocol description in the wiki describes the syntax of
> all the messages, but it's not clear what the messages actually mean, and
> what the are meant to do. It may help to just add an introductory section
> that explains the purpose of the protocol.
> 
> * SET_PIN_MODE : there's no real indication of what any of the modes
> actually mean, e.g. SERVO? PWM? what sort of values would these modes be
> expected to handle?
> 
> * PULL_UP: apparently writing a bitmasked one to a pin configured as INPUT
> sets the internal pull up, but this isn't mentioned anywhere in the
> protocol description. Also, it's very Arduino specific (e.g. the LPC1343 we
> use supports PULL_DOWN and REPEAT as well)
> 
> * protocol flow: there's no indication of the expected flow of the protocol:
>    - apparently, the embedded client is supposed to wake up and send a
> REPORT VERSION and REPORT FIRMWARE message, but this isn't specified.
>    - generally: who's in charge? What messages can be sent from which side
> in response to which other messages or in response to some event.
>    - the client is supposed to send a continuous stream of ANALOG_IO,
>  DIGITAL_IO messages (anything else?), but this isn't specified, also not
> the rate at which the sampling should take place. (StandardFirmata does
> 19ms ...) There's a message to configure the sampling interval... Should
> the client wait until such a message is received?
> 
> * firmata-test UI : since this is kind of the "reference implementation" at
> least on the host side, or at least is featured as such, it would be nice
> if it could be better maintained, or at least be more accessible: make it a
> project on github. It's fairly buggy, and it doesn't have a good build
> setup (lots of values are just hard coded in the makefile) I couldn't get
> it to build at all on OSX... It would be nice to expand the client to have
> some sort of debug view, where one could see the bytes being sent and
> received.
> 
> * no central point of discussion, this mailing list doesn't seem very
> active, but sourceforge mailing lists are not that great from the interface
> and don't really invite interaction (this may be a good thing!)
> 
> Thanks for listening!
>    -tim
> 
> 
> 
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> 
> 
> 
> _______________________________________________
> Firmata-devel mailing list
> Fir...@li...
> https://lists.sourceforge.net/lists/listinfo/firmata-devel
>