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

Steve B sbattazzo at gmail.com
Wed Nov 4 04:18:19 UTC 2015


Attaching my init.c code now (I went through and trimmed out whatever was
irrelevant).
Please give this a run and let me know if you see the same behavior.

Steve

On Mon, Nov 2, 2015 at 9:31 AM, Steve B <sbattazzo at gmail.com> wrote:

> 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/20151103/a15bb0b0/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: init.c
Type: text/x-csrc
Size: 3792 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/users/attachments/20151103/a15bb0b0/attachment-0002.bin>


More information about the users mailing list