> -----Original Message----- > From: linux-iio-owner@xxxxxxxxxxxxxxx [mailto:linux-iio-owner@xxxxxxxxxxxxxxx] On Behalf Of Jonathan Cameron > On October 6, 2014 2:50:13 PM GMT+01:00, "Tirdea, Irina" <irina.tirdea@xxxxxxxxx> wrote: > >> From: Jonathan Cameron [mailto:jic23@xxxxxxxxxx] > >> On 02/10/14 14:43, Daniel Baluta wrote: > >> > From: Irina Tirdea <irina.tirdea@xxxxxxxxx> > >> > > >> > One of the functionalities of a pedometer is a step counter. > >> > The step counter needs to be enabled and then it will count the > >steps > >> > in its hardware register. Whenever the applications need to check > >> > the step count, they will read the step counter register. > >> > > >> > To support this functionality we need a steps attribute that > >> > will export the number of steps. > >> > > >> I'm not keen on multiplexing different types of data onto a single > >activity type. > >> Steps is well enough defined on it's own to have it's own channel > >type. > >> > >> in_steps_input would be fine by me. I suppose steps might mean > >something else > >> though... > >> > > > >Hi Jonathan, > > > >Thanks for the review. > > > >Moving the pedometer part to a new type sounds good to me. > >However, I would prefer to add a new type called pedometer and keep > >steps as a modifier, generating names like in_ped_steps_input for the > >attribute and in_ped_steps_instance_en for the event. > >The reason for this is that for supporting Freescale's MMA9553L we will > >need additional attributes (distance, speed, calories, height, weight) > >that we can add as modifiers to this pedometer type. To keep things > >simple, I did not add these additional attributes to the RFC series, > >but I could do that if you think it would be useful. For this device, > >the motion events (walking, running, jogging, still) also depend on the > >height attribute being set, but we intend to deal with this dependency > >in the driver (using the pedometer's height attribute). > > > >What do you think? > I think I would rather each of these was included as a type rather than a modifier. > There are lots of other ways to measure speed for starters and often user space > won't care where it comes from... > > In_speed_raw etc... > > Trick where possible is to think about what is measured rather than how. Tends to give > more consistent interfaces. That makes sense. Will do the changes and also add one of these other types in v2. Thanks, Irina ��.n��������+%������w��{.n�����{��(��)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
