Hi Ketul,
we are experiencing a deadlock that seems to be caused by
+#define OBTAIN_LOCK(s) assert( rtems_semaphore_obtain(s, \
+ RTEMS_WAIT, \
+ RTEMS_NO_TIMEOUT \
+ ) == RTEMS_SUCCESSFUL )
+
which differs from the previous version. Are you sure this is the
intended behavior for in-interrupt context? What if the semaphore is
already locked?
IIUC this causes either a forever sleep or an assertion in case the
semaphore cannot be acquired.
Thanks,
Daniel.
On Tue, Jun 23, 2015 at 11:53 AM, Ketul Shah <ketulshah1...@gmail.com> wrote:
> Sorry wrong attachment. Kindly review the recent one.
>
> Thanks.
>
> Best Regards,
> Ketul
>
> On 23 June 2015 at 20:20, Ketul Shah <ketulshah1...@gmail.com> wrote:
>>
>> Hello all,
>>
>> Sorry as I am updating you related to my GPIO API after a huge delay.
>>
>> I have developed it and tested it on my BBB. I did some big changes in the
>> API taking in the account comment(s)/suggestion(s) from my respective
>> mentors.
>>
>> I am also looking the API developed by Andre working for Raspberry Pi. Now
>> I think it is a good time to merge the gpio code as API is getting more
>> stable and generalized.
>>
>> So now it is good time to take the best things from API and we can have
>> common API for GPIO driver running on every embedded board.
>>
>> Your comment(s) are welcomed.
>>
>> Thanks.
>>
>> Best Regards,
>> Ketul
>>
>> On 29 April 2015 at 06:39, Chris Johns <chr...@rtems.org> wrote:
>>>
>>> [ Just catching up ]
>>>
>>> On 26/04/2015 9:26 pm, Ben Gras wrote:
>>> > All,
>>> >
>>> > I think the API as it is (for digital GPIO's) is pretty close to
>>> > generic. I like my suggestion (gpio_* in my previous mail) better as
>>> > more generic. (More configuration is hidden from the application.)
>>> >
>>> > Joel I just read your presentation.
>>> >
>>> > I have come up with a minimal GPIO API based on the above (so
>>> > ultimately based on the RPI API) that just covers the GPIO digital out
>>> > case but allows expansion (with more defines and functions).
>>> >
>>> > https://devel.rtems.org/wiki/TBR/User/BenGras
>>> >
>>> > Is this an idea? Then we can merge this code implementing a reasonably
>>> > generic API without having to flesh out the whole thing.
>>> >
>>>
>>> How do we define hardware specific details without bloating the API ?
>>>
>>> For example on a zynq project I am working on I needed a GPIO interface
>>> and I decided to use a struct to define the pin and the API takes
>>> references to it. For example to control the write enable pin on a flash
>>> device I have:
>>>
>>> static const gpio_pin_def gpio_Flash_WD =
>>> {
>>> pin: 4,
>>> output: true,
>>> on: GPIO_FLASH_WD_EN,
>>> outen: true,
>>> volts: gpio_LVCMOS33,
>>> pullup: true,
>>> fast: false,
>>> tristate: false
>>> };
>>>
>>> and then I have:
>>>
>>> gpio_error ge = gpio_setup_pin(&gpio_Flash_WD);
>>> if (ge != GPIO_NO_ERROR)
>>> return FLASH_WRITE_LOCK_FAIL;
>>>
>>> ....
>>>
>>> gpio_output(gpio_Flash_WD.pin, GPIO_FLASH_WD_EN);
>>>
>>> ....
>>>
>>> I need to set the voltage on the pin on the Zynq but this is Zynq
>>> specific.
>>>
>>> We need a way to let a user convey specific hardware details to the BSP
>>> driver through the API plus we need a light weight API with minimal
>>> internal translations. This approach also lets me define an array of
>>> pins and a single set up call configures them.
>>>
>>> So you could have:
>>>
>>> typedef struct
>>> {
>>> int pin; /* The pin number. */
>>> bool output; /* True for output, false for input. */
>>> bool on; /* True default output is on */
>>> bool outen; /* True for output enable on, false for off. */
>>> bool pullup; /* True to enable the pull up. */
>>> bool tristate; /* True to enable tri-state. */
>>> void* platform; /* Opaque hardware specific set up details. */
>>> } gpio_pin_def;
>>>
>>> where the 'platform' references a struct agreed between the BSP (or
>>> device layer) and the user code. For the generic cases this is not
>>> needed and NULL. It also allows layering where a device set up phase of
>>> user code sets the voltages and the generic code can play with the pin
>>> at a generic level, eg direction etc.
>>>
>>> What locking is being considered in this API ?
>>>
>>> Chris
>>
>>
>
>
> _______________________________________________
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
--
Daniel F. Gutson
Chief Engineering Officer, SPD
San Lorenzo 47, 3rd Floor, Office 5
Córdoba, Argentina
Phone: +54 351 4217888 / +54 351 4218211
Skype: dgutson
LinkedIn: http://ar.linkedin.com/in/danielgutson
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
