run_modes absent from API spec?

[G33kDude]

It seems really inconsistent which of the "mode" attributes get a "modes". Motors get stop_modes, but no run_modes, regulation_modes or position_modes, and Sensors get both mode and modes.

Is there a reason for this? Is it seen that stop_modes is necessary but other "modes" aren't?

[WasabiFan]

Any omissions were not intentional; were those added recently? Either way, I'll add those properties (and make sure that there aren't any more that I missed) tonight. Thanks for the tip!

[dlech]

You can find the kernel changelog here.

Applicable changes to this repo are:

linux-source-3.16.1-7-ev3dev (1) testing; urgency=medium
* Add new command and commands attributes to msensor class. This replaces
modes in some cases.
* [rhemel]: Rename dc-motor duty_cycle attribute to duty_cycle_sp and add new
duty_cycle attribute that returns current duty cycle.

linux-source-3.16.1-6-ev3dev (1) testing; urgency=medium
* tacho-motor class device are now named `motor<N>` instead of
`tacho-motor<N>`.

linux-source-3.16.1-5-ev3dev (1) testing; urgency=medium
* [rhempel] Fixed a number of tacho motor bugs

I think the new tacho-motor attributes were lumped into this last one. https://github.com/ev3dev/ev3dev-kernel/commit/1a43723a0ad42d42d02af9a44309bc70e944dc0e

And of course, there are the driver doc pages as well. tacho-motor, servo-motor, dc-motor, msensor.

[WasabiFan]

@dlech I'll read through the changelog to make sure that there isn't anything else that I missed to include in my updates tonight.

[WasabiFan]

@G33kDude Thanks for the tip on those missing properties. I added them to our JSON spec, so they should show up for our next release once we get the libraries working off of it.