Things to do to catch up with boostc

[ddemidov]

• Implement device_index property for Device class.
• Implement platform-specific Led instances and color functions.
• Implement measured_amps and measured_volts properties for PowerSupply class (the names in the generated doc seem to be messed up).
• Implement Button class for ev3 buttons.
• Implement Sound class.
• Implement LCD class.
• Implement RemoteControl class.
• Implement bin_data_format and bin_data for Sensor.
• Implement steering function.

[antonvh]

What would you like me to do? Where would you like help? Apart from the steering function I'd like to make a MotorPair class, so you can m_pair.run_forever(direction=-50, speed_sp=75)

[ddemidov]

All of these are pretty straightforward to implement except for Button and LCD class. Both of these need low-level access to input/output devices, and both of them probably belong to EV3 platform (are there any buttons on RPI except for full-sized USB keyboard? Is there an LCD screen on RPI? Does it work through framebuffer?).

I was going to try and finish Led class later this week. Feel free to choose any other task. By the way, since you are running RPI, can you please show the contents of /sys/class/leds folder?

[antonvh]

Will do. I'm still unclear on how exactly you want to divide the work.

[rhempel]

I think @ddemidov is going to work on the LED class implementation we talked about. @antonvh, could you send him the contents of your rPi /sys/class/led directory please?
@antonvh - would you like to try to fill out the Button or Sound classes?
Coming from the Lua world, I am in favour of "mechisms, not policy" - what that means for us is implementing a minimal feature set for each class that allows users to build what they need on top of it.
For Sound, let's consider starting with a basic tone API (frequency, duration, volume as kwargs) and then maybe add specific sound file support as an add-in. We may want to also consider being able to send a sequence of tones as a list of tuples and playing to completion. Do we wait for the tone to complete before returning, do we add a function to tell us if the tone is playing or the driver is idle? etc...
You could also work on the power supply or remote control API. I might give the remote control API a try since I used it for the DrawString bot :-)

[ddemidov]

Note that the Sound class has just a handful of methods in C++/boostc bindings.

Sound::beep() is an alias for Sound::tone(1000, 100), Sound::tone(freq, dur) makes a noise on the given frequency for the given duration (and it uses sysfs file, so should be simple to implement). Both of the methods are asynchronous.

Sound::play() is just a wrapper around system call to aplay utility (I think patched by @dlech to better work in ev3 system). It may be synchronous or asynchronous depending on user flag.

[rhempel]

Just to be clear, it would be best if we can minimize the functions in each class, and specify them in spec.json so that bindings for other languages can be scored against how much of the spec they implement.

[ddemidov]

What do you suggest to put into spec.json, except for may be list of method names (and may be parameters)? I don't think the methods for, say, Sound or LCD could be completely autogenerated in each of the bindings from a universal spec.
There is also wrapper-specification.md, which is partly generated from spec.json, but also contains some human-parseable statements (like description of the above methods).

[antonvh]

I will work on the Button first and later try Sound. I couldn't find any specs. I will try to emulate boostc as well as possible.

[ddemidov]

Found @dlech's comment about framebuffer implementation in python: ev3dev/ev3dev#404 (comment)

[antonvh]

anton@ev3dev-rpi1:~$ ls /sys/class/leds
brickpi1:blue:ev3dev brickpi2:blue:ev3dev led0 led1

anton@ev3dev-rpi1:~$ ls /sys/class/leds/brickpi1:blue:ev3dev/
brightness device max_brightness subsystem trigger uevent

anton@ev3dev-rpi1:~$ cat /sys/class/leds/brickpi1:blue:ev3dev/brightness
255

On 19 Oct 2015, at 11:21, Denis Demidov notifications@github.com wrote:

/sys/class/leds

[ddemidov]

I've already implemented brickpi leds (@dlech sent me the info yesterday). Thanks anyway!

[ensonic]

FYI: The APIs are realative easy to compare by doing a pprint(dir(ev3dev)) with the respective import:
here is the pure one: https://gist.github.com/ensonic/2f00834f8213ae2df81b
and the boost one: https://gist.github.com/ensonic/331f0f57c10abe33cf4c

I'll start a sed script that will rewrite the api.

[ddemidov]

Thanks, there is a lot of noise in boostc version (due to the need to work around fixed c++ interface), but this is very helpful.

@ensonic, since you are going to work on sed script, I could push changes to boostc version tonight with renamed classes. Would that be ok?