Linux ELC & OpenIoT Report

Linux ELC & OpenIoT Report

[Alison Schofield]

Hi IIO Community,

I attended the Linux Foundation's Embedded Linux and OpenIoT Summit in
Portland, Oregon recently.

I've appended a few excerpts from my blog write-up below and the full
text of my report is available here:
https://outreachyiio.blogspot.com/2017/03/embedded-linux-conference-openiot.html

alisons


2 Things that made me go hmmm:

1) There are developers who believe that user space drivers are more
efficient than kernel drivers. They don't mean more efficient as in they
don't want to bother upstreaming the driver. They actually mean more
efficient in that they think the user space driver performs better.  I
didn't meet one of those developers...they were only whispered about ;)

2) Android Things (Intel & Google product) will not use our lovely IIO
drivers. They will not include any non-essential drivers in the kernel
image and there will not be a way to rebuild it. They have set up a git
repository for the world to share user space drivers for sensors. 

IIO Community Sightings: Matt Ranostay 
Matt gave a great IIO Subsystem presentation!!! It contained a live demo
of one of his more recent driver additions: heart rate and pulse
oximeter. When Matt's hear rate only measured 42, he wrote it off to a
loose connection, but I'm not convinced. I may go look for a bug in that
driver ;)

IIO Community Hindsight: David Lechner 
When I met David displaying his ev3 devices at the technical showcase, I
didn't know of him from the IIO community. David has some drivers he
wants upstreamed to IIO.  Potential Outreachy projects?  I'm fuzzy on
this. Can we add support for sensors that basically have no datasheet,
but that David has reverse engineered?

IIO Community Hindsight: Jason Kridner 
Jason gave a presentation and also showed off some beaglebone devices at
the technical showcase. Jason noted in his presentation that he'd like
to see additional sensor support in IIO.

Re: Linux ELC & OpenIoT Report

[Matt Ranostay]

On Sun, Mar 5, 2017 at 3:52 PM, Alison Schofield <amsfield22@gmail.com> wrote:
> Hi IIO Community,
>
> I attended the Linux Foundation's Embedded Linux and OpenIoT Summit in
> Portland, Oregon recently.
>
> I've appended a few excerpts from my blog write-up below and the full
> text of my report is available here:
> https://outreachyiio.blogspot.com/2017/03/embedded-linux-conference-openiot.html
>
> alisons
>
>
> 2 Things that made me go hmmm:
>
> 1) There are developers who believe that user space drivers are more
> efficient than kernel drivers. They don't mean more efficient as in they
> don't want to bother upstreaming the driver. They actually mean more
> efficient in that they think the user space driver performs better.  I
> didn't meet one of those developers...they were only whispered about ;)
>
> 2) Android Things (Intel & Google product) will not use our lovely IIO
> drivers. They will not include any non-essential drivers in the kernel
> image and there will not be a way to rebuild it. They have set up a git
> repository for the world to share user space drivers for sensors.
>
> IIO Community Sightings: Matt Ranostay
> Matt gave a great IIO Subsystem presentation!!! It contained a live demo
> of one of his more recent driver additions: heart rate and pulse
> oximeter. When Matt's hear rate only measured 42, he wrote it off to a
> loose connection, but I'm not convinced. I may go look for a bug in that
> driver ;)

Actually it was because I was talking it was at 42.. it did go back to
~90 in the demo which is more sane
when I stop talking for a few seconds. There is a reason the doctors
tell you to breathe normally and not
talk when taking your blood pressure. Not exactly what you are doing
in a talk though :).

Not doubt there are bugs... but more likely in the oximeter processing
script since there is a lot of peak detection
magic I'm not sure is 100% accurate :).

>
> IIO Community Hindsight: David Lechner
> When I met David displaying his ev3 devices at the technical showcase, I
> didn't know of him from the IIO community. David has some drivers he
> wants upstreamed to IIO.  Potential Outreachy projects?  I'm fuzzy on
> this. Can we add support for sensors that basically have no datasheet,
> but that David has reverse engineered?
>
> IIO Community Hindsight: Jason Kridner
> Jason gave a presentation and also showed off some beaglebone devices at
> the technical showcase. Jason noted in his presentation that he'd like
> to see additional sensor support in IIO.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux ELC & OpenIoT Report

[Jonathan Cameron]

On 5 March 2017 23:52:04 GMT+00:00, Alison Schofield <amsfield22@gmail.com> wrote:
>Hi IIO Community,
>
>I attended the Linux Foundation's Embedded Linux and OpenIoT Summit in
>Portland, Oregon recently.
>
>I've appended a few excerpts from my blog write-up below and the full
>text of my report is available here:
>https://outreachyiio.blogspot.com/2017/03/embedded-linux-conference-openiot.html
>
>alisons
>
>
>2 Things that made me go hmmm:
>
>1) There are developers who believe that user space drivers are more
>efficient than kernel drivers. They don't mean more efficient as in
>they
>don't want to bother upstreaming the driver. They actually mean more
>efficient in that they think the user space driver performs better.  I
>didn't meet one of those developers...they were only whispered about ;)

There are circumstances in which they are right.
Often it is because they don't have to play nice
 with other elements of the system and can burn CPU cycles.

It's the same stuff that the networking lot have had arguements about for years.  Userspace
 drivers often have the flexibility to do nasty stuff to lower latency.  What we need to do is an
 exercise in pinning down the size of the various causes of latency and what we can do to
 reduce them. If anyone wants to do an analysis of a typical userspace driver for these apps
that might be very useful.

Jason's thoughts on control loops in the kernel using bpf might be the ultimate answer, who
 knows! I haven't dug through all that would be involved with that yet... Idea seems interesting
 though.
>
>2) Android Things (Intel & Google product) will not use our lovely IIO
>drivers. They will not include any non-essential drivers in the kernel
>image and there will not be a way to rebuild it. They have set up a git
>repository for the world to share user space drivers for sensors. 
Ah well.... 
>
>IIO Community Sightings: Matt Ranostay 
>Matt gave a great IIO Subsystem presentation!!! It contained a live
>demo
>of one of his more recent driver additions: heart rate and pulse
>oximeter. When Matt's hear rate only measured 42, he wrote it off to a
>loose connection, but I'm not convinced. I may go look for a bug in
>that
>driver ;)
>
>IIO Community Hindsight: David Lechner 
>When I met David displaying his ev3 devices at the technical showcase,
>I
>didn't know of him from the IIO community. David has some drivers he
>wants upstreamed to IIO.  Potential Outreachy projects?  I'm fuzzy on
>this. Can we add support for sensors that basically have no datasheet,
>but that David has reverse engineered?

Sure we can. Lots of drivers in the wider kernel are reverse engineered. A few in IIO may well have been.

Hmm would take a slightly brave outreach y candidate perhaps.

>
>IIO Community Hindsight: Jason Kridner 
>Jason gave a presentation and also showed off some beaglebone devices
>at
>the technical showcase. Jason noted in his presentation that he'd like
>to see additional sensor support in IIO.
Thanks for the update.

Jonathan
>--
>To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Linux ELC & OpenIoT Report

[Lars-Peter Clausen]

On 03/06/2017 09:04 AM, Jonathan Cameron wrote:
> 
> 
> On 5 March 2017 23:52:04 GMT+00:00, Alison Schofield <amsfield22@gmail.com> wrote:
>> Hi IIO Community,
>>
>> I attended the Linux Foundation's Embedded Linux and OpenIoT Summit in
>> Portland, Oregon recently.
>>
>> I've appended a few excerpts from my blog write-up below and the full
>> text of my report is available here:
>> https://outreachyiio.blogspot.com/2017/03/embedded-linux-conference-openiot.html
>>
>> alisons
>>
>>
>> 2 Things that made me go hmmm:
>>
>> 1) There are developers who believe that user space drivers are more
>> efficient than kernel drivers. They don't mean more efficient as in
>> they
>> don't want to bother upstreaming the driver. They actually mean more
>> efficient in that they think the user space driver performs better.  I
>> didn't meet one of those developers...they were only whispered about ;)
> 
> There are circumstances in which they are right.
> Often it is because they don't have to play nice
>  with other elements of the system and can burn CPU cycles.
> 
> It's the same stuff that the networking lot have had arguements about for years.  Userspace
>  drivers often have the flexibility to do nasty stuff to lower latency.  What we need to do is an
>  exercise in pinning down the size of the various causes of latency and what we can do to
>  reduce them. If anyone wants to do an analysis of a typical userspace driver for these apps
> that might be very useful.

I like to argue that we've reached the post-framework era. Hardware is
getting quite complex, on one extreme they are too versatile and on the
other extreme too specialized for it to be practical to create a generic driver.

To be able to accommodate this tje current trend is that all frameworks are
drifting to is to having a property system. A device has properties and each
property has a value that can be read or written. But the the semantics are
otherwise completely up to the driver (except for a set of baseline properties).

A framework always introduces additional overhead by having indirection, so
to offset this overhead the framework needs to offer something in return.
For hardware abstraction layers this promise has often been that you can
write generic applications, that if they use the framework's API, can work
with any hardware for which a framework driver exists. Now with the property
approach this promise is gone. Each driver has custom semantics all that is
generic is the marshaling and unmarshaling of the data structures that are
used to communicate between the driver and the application.

This means and application needs to be aware of the specifics of the
hardware anyway. So why go through the hassle of using the framework and
introducing additional overhead if there are no gains.

So what we are seeing instead are application specific drivers. A piece of
software (driver, library, application whatever you want to call it) that is
aware of the intrinsics of the hardware and configures the hardware for a
specific usecase. It can typically do this much more efficient than a
generic driver since it can completely ignore all other usecase, while a
generic driver needs to somehow try to balance between all possible usecases.

With these application specific drivers you are not limited to one driver
per device, but there are many drivers for the same device, they are just
not active at the same time or even on the same system since different
systems use the same hardware for different usecases.

Re: Linux ELC & OpenIoT Report

[Alison Schofield]

On Mon, Mar 06, 2017 at 08:04:21AM +0000, Jonathan Cameron wrote:
> 
> 
> On 5 March 2017 23:52:04 GMT+00:00, Alison Schofield <amsfield22@gmail.com> wrote:
> >Hi IIO Community,
> >
> >I attended the Linux Foundation's Embedded Linux and OpenIoT Summit in
> >Portland, Oregon recently.
> >
> >I've appended a few excerpts from my blog write-up below and the full
> >text of my report is available here:
> >https://outreachyiio.blogspot.com/2017/03/embedded-linux-conference-openiot.html
> >
> >alisons

8< ......... snipped a bunch to focus on the ev3 sensor ...............

> >IIO Community Hindsight: David Lechner 
> >When I met David displaying his ev3 devices at the technical showcase,
> >I
> >didn't know of him from the IIO community. David has some drivers he
> >wants upstreamed to IIO.  Potential Outreachy projects?  I'm fuzzy on
> >this. Can we add support for sensors that basically have no datasheet,
> >but that David has reverse engineered?
> 
> Sure we can. Lots of drivers in the wider kernel are reverse engineered. A few in IIO may well have been.
> 
> Hmm would take a slightly brave outreach y candidate perhaps.
>

I'm going to try to pull David in here, so he can fill in & correct me.

I think David has kernel drivers he has written (loadable kernel
modules - not user space drivers) that could be pushed upstream.
(still could take significant bravery I guess)

David, Am I getting anything right here?  And, are there any destined for IIO?

Thanks,
alisons

Re: Linux ELC & OpenIoT Report

[David Lechner]

On 03/06/2017 02:19 PM, Alison Schofield wrote:
> On Mon, Mar 06, 2017 at 08:04:21AM +0000, Jonathan Cameron wrote:
>>
>>
>> On 5 March 2017 23:52:04 GMT+00:00, Alison Schofield <amsfield22@gmail.com> wrote:
>>> Hi IIO Community,
>>>
>>> I attended the Linux Foundation's Embedded Linux and OpenIoT Summit in
>>> Portland, Oregon recently.
>>>
>>> I've appended a few excerpts from my blog write-up below and the full
>>> text of my report is available here:
>>> https://outreachyiio.blogspot.com/2017/03/embedded-linux-conference-openiot.html
>>>
>>> alisons
>
> 8< ......... snipped a bunch to focus on the ev3 sensor ...............
>
>>> IIO Community Hindsight: David Lechner
>>> When I met David displaying his ev3 devices at the technical showcase,
>>> I
>>> didn't know of him from the IIO community. David has some drivers he
>>> wants upstreamed to IIO.  Potential Outreachy projects?  I'm fuzzy on
>>> this. Can we add support for sensors that basically have no datasheet,
>>> but that David has reverse engineered?
>>
>> Sure we can. Lots of drivers in the wider kernel are reverse engineered. A few in IIO may well have been.
>>
>> Hmm would take a slightly brave outreach y candidate perhaps.
>>
>
> I'm going to try to pull David in here, so he can fill in & correct me.
>
> I think David has kernel drivers he has written (loadable kernel
> modules - not user space drivers) that could be pushed upstream.
> (still could take significant bravery I guess)
>
> David, Am I getting anything right here?  And, are there any destined for IIO?
>

Mostly right. ;-)

When I started hacking on LEGO Mindstorms, I didn't know about the IIO 
subsystem (or about Linux drivers in general). So, I create my own 
subsystem that is very similar to IIO. The TL;DR; is that these drivers 
need to be converted to the IIO subsystem. It is a bit more involved 
than just "cleaning it up".

If you want to learn more about what I have done so far you can find the 
code at 
<https://github.com/ev3dev/lego-linux-drivers/tree/master/sensors> and 
some documentation at <http://www.ev3dev.org/docs/sensors/>.

There are a couple of things needed that I don't think exist in the IIO 
subsystem yet though (I asked Matt during his talk and he didn't know of 
any).

These sensors have "modes". When you change the mode of a sensor, it 
changes the data being received. For example, there is a color sensor 
that can measure ambient light, reflected light or color. But it can't 
do all of these at the same time. You have to set the mode first and 
interpret the data received based on the mode. I have a hunch that if I 
dug into it some more, I could figure out a way to do this using the 
existing iio code though.

Some of these sensors also have "commands". Commands can do things like 
trigger a sensor calibration. This is the part I am not so sure about.

And, FYI, most of these sensors do have some sort of technical 
documentation from the manufacturer.

Re: Linux ELC & OpenIoT Report

[Jonathan Cameron]

On 06/03/17 21:29, David Lechner wrote:
> On 03/06/2017 02:19 PM, Alison Schofield wrote:
>> On Mon, Mar 06, 2017 at 08:04:21AM +0000, Jonathan Cameron wrote:
>>>
>>>
>>> On 5 March 2017 23:52:04 GMT+00:00, Alison Schofield <amsfield22@gmail.com> wrote:
>>>> Hi IIO Community,
>>>>
>>>> I attended the Linux Foundation's Embedded Linux and OpenIoT Summit in
>>>> Portland, Oregon recently.
>>>>
>>>> I've appended a few excerpts from my blog write-up below and the full
>>>> text of my report is available here:
>>>> https://outreachyiio.blogspot.com/2017/03/embedded-linux-conference-openiot.html
>>>>
>>>> alisons
>>
>> 8< ......... snipped a bunch to focus on the ev3 sensor ...............
>>
>>>> IIO Community Hindsight: David Lechner
>>>> When I met David displaying his ev3 devices at the technical showcase,
>>>> I
>>>> didn't know of him from the IIO community. David has some drivers he
>>>> wants upstreamed to IIO.  Potential Outreachy projects?  I'm fuzzy on
>>>> this. Can we add support for sensors that basically have no datasheet,
>>>> but that David has reverse engineered?
>>>
>>> Sure we can. Lots of drivers in the wider kernel are reverse engineered. A few in IIO may well have been.
>>>
>>> Hmm would take a slightly brave outreach y candidate perhaps.
>>>
>>
>> I'm going to try to pull David in here, so he can fill in & correct me.
>>
>> I think David has kernel drivers he has written (loadable kernel
>> modules - not user space drivers) that could be pushed upstream.
>> (still could take significant bravery I guess)
>>
>> David, Am I getting anything right here?  And, are there any destined for IIO?
>>
> 
> Mostly right. ;-)
> 
> When I started hacking on LEGO Mindstorms, I didn't know about the
> IIO subsystem (or about Linux drivers in general). So, I create my
> own subsystem that is very similar to IIO. The TL;DR; is that these
> drivers need to be converted to the IIO subsystem. It is a bit more
> involved than just "cleaning it up".
> 
> If you want to learn more about what I have done so far you can find
> the code at
> <https://github.com/ev3dev/lego-linux-drivers/tree/master/sensors>
> and some documentation at <http://www.ev3dev.org/docs/sensors/>.
> 
> There are a couple of things needed that I don't think exist in the
> IIO subsystem yet though (I asked Matt during his talk and he didn't
> know of any).
> 
> These sensors have "modes". When you change the mode of a sensor, it
> changes the data being received. For example, there is a color sensor
> that can measure ambient light, reflected light or color. But it
> can't do all of these at the same time. You have to set the mode
> first and interpret the data received based on the mode. I have a
> hunch that if I dug into it some more, I could figure out a way to do
> this using the existing iio code though.
Various elements for this:

Firstly, if simply doing direct sysfs type reads, thenwe'd  do it
on demand.  So switch mode, wait for data, then report.

If doing triggered (which is basically interrupt driven) capture
then you can use available_scan_masks to control which combinations
of channels can be enabled concurrently.  These combinations can get
very complex.   Userspace currently figures out valid combinations
by brute force trying them and seeing if they are allowed. 

There is also a function equivalent to verify if a particularly
combination is valid.  This covers the really nasty cases (or
funnily enough the simple ones, such as any single channel
(one_hot)
> 
> Some of these sensors also have "commands". Commands can do things
> like trigger a sensor calibration. This is the part I am not so sure
> about.
This is usually handled in a fairly device type, or device specific
way via custom sysfs attributes.  If the calibration doesn't require
external interaction, then usual convention is to do it on device
probe and assume stable for a reasonable amount of time.
> 
> And, FYI, most of these sensors do have some sort of technical
> documentation from the manufacturer.
That just makes life too easy ;)

Jonathan