On 13-08-2015 14:51, Ketul Shah wrote:
Hi Andre,
Thanks for the reply.
On 13 August 2015 at 19:13, André Marques
<andre.lousa.marq...@gmail.com <mailto:andre.lousa.marq...@gmail.com>>
wrote:
Hello Ketul,
On 13-08-2015 13:04, Ketul Shah wrote:
Hi Andre,
Great API and happy to know that it is merged with main line.
Eventually I implemented GPIO driver for BBB using this API.
After debugging for rtems_gpio_get_value() on BBB I found the
following bug.
For BBB, GPIO pin nos. varies from 0 to 32. So function return
type would be uint32_t instead of uint8_t.
For BBB I wrote :-
uint32_t rtems_gpio_bsp_get_value(uint32_t bank, uint32_t pin)
{
return (mmio_read(bbb_reg(bank, AM335X_GPIO_DATAIN)) &
BIT(pin));
So it would be:- return ((mmio_read(bbb_reg(bank,
AM335X_GPIO_DATAIN)) & BIT(pin)) > 0);
Am I correct ?
}
Yes, but since this function is not used by applications maybe it would
be best to return the bitmask here and avoid another operation, as
rtems_gpio_get_value does the mapping to 1 anyway for any value above 0.
So yes the bsp function shall return uint32_t instead of the uint8_t.
Doxygen also has to be updated.
the rtems_gpio_bsp_get_value returns the value of a GPIO pin,
which can only be either 0 or 1. This is not platform dependent.
Any value greater than zero should map to 1.
I do notice that I forgot this detail in the Pi implementation
too, so it is also returning a 32 bit value.
The reasoning for the 8-bit return is that the return will always
be binary. 0 or non-zero, but by mapping a non-zero value to 1 may
make more sense than outputing a 32-bit bitmask, which was the
initial approach.
Thanks.
Best Regards,
Ketul
--André Marques.
[snip]
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
