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