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

Steve B sbattazzo at gmail.com
Fri Oct 30 23:41:03 UTC 2015


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20151030/c0c251b1/attachment.html>


More information about the users mailing list