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

[Gedare Bloom]

I did not run it as I don't have a BBB, hopefully Ketul or Ben can
check. I did look through the code and your test seems fine, so you
have probably found something unexpected in the BBB GPIO code.

On Tue, Nov 3, 2015 at 11:18 PM, Steve B <sbattazzo at gmail.com> wrote:
> 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
>>
>>
>
>
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users