Possible bug and lacking feature in BBB bsp, GPIO API hooks

[Steve B]

I just looked at some sample code on Ketul's github, and the source code of
the API itself, rather than any actual documentation.

I have already made calls to rtems_gpio_initialize() and
rtems_gpio_request_pin() as Ketul suggested.
I am about to go on travel but I will attach my code once tonight I get
settled in, and maybe one of you can run it and see if you agree with me on
the symptom.

Steve

On Sat, Oct 31, 2015 at 6:45 AM, Gedare Bloom <gedare at rtems.org> wrote:

> This problem indicates a lack of clear documentation. Steve, where did
> you look for guidance on using the API?
>
> On Sat, Oct 31, 2015 at 5:11 AM, Ketul Shah <ketulshah1993 at gmail.com>
> wrote:
> > Hi Steve,
> >
> > I suggest you to kindly configure GPIO API by using following functions
> in
> > your code,
> >
> > rtems_gpio_initialize();
> > rtems_gpio_request_pin(.....);
> >
> > After using it should work properly. Me and Ben had tested on our BBBs.
> >
> > For example code you can have a loot at link.
> >
> > Hope this helps.
> >
> > Thanks,
> >
> > Ketul
> >
> > On 31 October 2015 at 05:11, Steve B <sbattazzo at gmail.com> wrote:
> >>
> >> Hi again guys,
> >> I've noticed an unexpected (to me) behavior in the GPIO API for
> Beaglebone
> >> Black.
> >>
> >> I borrowed a periodic task from the clock test source, and set it up to
> >> toggle the GPIOs once every couple seconds.. here's what I have:
> >>
> >> rtems_task Test_task(
> >>   rtems_task_argument task_index
> >> )
> >> {
> >>   int task_count = 0;
> >>   rtems_time_of_day time;
> >>   rtems_interval    ticks;
> >>
> >>   ticks = task_index * 2 * rtems_clock_get_ticks_per_second();
> >>
> >>   for ( ; ; ) {
> >>     task_count++;
> >>     (void) rtems_clock_get_tod( &time );
> >>     if ( time.second >= 35 ) {
> >>       puts( "*** END OF CLOCK TICK TEST ***" );
> >>       //exit( 0 );
> >>       while(1);
> >>     }
> >>     put_name( Task_name[ task_index ], FALSE );
> >>     print_time( " - rtems_clock_get_tod - ", &time, "\n" );
> >>
> >>     //Toggle GPIO
> >>     if(task_count & 1) {
> >>         rtems_gpio_set(LED1);
> >>         rtems_gpio_set(LED2);
> >>         }
> >>     else rtems_gpio_clear(LED1);
> >>
> >>     (void) rtems_task_wake_after( ticks );
> >>   }
> >> }
> >>
> >> Notice I've defined that if the least significant bit of my variable
> >> task_count is 1, then I set both LED1 and LED2. If that LSB is zero, I
> just
> >> call to clear LED1.
> >> When I actually run this, both LED1 and LED2 are being cleared! Same is
> >> true with the 3rd and 4th user LEDs as well, if I happen to set all
> four of
> >> them. So I think somehow rtems_gpio_bsp_clear() is clearing the entire
> bank,
> >> not just the single pin specified in the argument. Can somebody confirm
> this
> >> behavior?
> >> I will dig around and see if I can figure out why it's happening and
> >> generate a patch if I find it.
> >>
> >> Also, I was hoping to be able to toggle a GPIO output by checking its
> >> current state and using that to decide whether to set or clear, but I
> don't
> >> see anything in the API that would allow me to check the state of an
> output.
> >> Is this a known/intended limitation?
> >>
> >> Cheers,
> >>
> >> Steve
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> users mailing list
> >> users at rtems.org
> >> http://lists.rtems.org/mailman/listinfo/users
> >
> >
> >
> > _______________________________________________
> > users mailing list
> > users at rtems.org
> > http://lists.rtems.org/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20151102/4a933eb7/attachment.html>