<div dir="ltr">Sorry wrong attachment. Kindly review the recent one.  <div><br></div><div>Thanks.</div><div><br></div><div>Best Regards,</div><div>Ketul</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 23 June 2015 at 20:20, Ketul Shah <span dir="ltr"><<a href="mailto:ketulshah1993@gmail.com" target="_blank">ketulshah1993@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello all,<div><br></div><div>Sorry as I am updating you related to my GPIO API after a huge delay.</div><div><br></div><div>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.</div><div><br></div><div>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. </div><div><br></div><div>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.  </div><div><br></div><div>Your comment(s) are welcomed.</div><div><br></div><div>Thanks.</div><div><br></div><div>Best Regards,</div><div>Ketul</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On 29 April 2015 at 06:39, Chris Johns <span dir="ltr"><<a href="mailto:chrisj@rtems.org" target="_blank">chrisj@rtems.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> [ Just catching up ]<br>
<span><br>
On 26/04/2015 9:26 pm, Ben Gras wrote:<br>
> All,<br>
><br>
> I think the API as it is (for digital GPIO's) is pretty close to<br>
> generic. I like my suggestion (gpio_* in my previous mail) better as<br>
> more generic. (More configuration is hidden from the application.)<br>
><br>
> Joel I just read your presentation.<br>
><br>
> I have come up with a minimal GPIO API based on the above (so<br>
> ultimately based on the RPI API) that just covers the GPIO digital out<br>
> case but allows expansion (with more defines and functions).<br>
><br>
> <a href="https://devel.rtems.org/wiki/TBR/User/BenGras" rel="noreferrer" target="_blank">https://devel.rtems.org/wiki/TBR/User/BenGras</a><br>
><br>
> Is this an idea? Then we can merge this code implementing a reasonably<br>
> generic API without having to flesh out the whole thing.<br>
><br>
<br>
</span>How do we define hardware specific details without bloating the API ?<br>
<br>
For example on a zynq project I am working on I needed a GPIO interface<br>
and I decided to use a struct to define the pin and the API takes<br>
references to it. For example to control the write enable pin on a flash<br>
device I have:<br>
<br>
static const gpio_pin_def gpio_Flash_WD =<br>
{<br>
  pin:      4,<br>
  output:   true,<br>
  on:       GPIO_FLASH_WD_EN,<br>
  outen:    true,<br>
  volts:    gpio_LVCMOS33,<br>
  pullup:   true,<br>
  fast:     false,<br>
  tristate: false<br>
};<br>
<br>
and then I have:<br>
<br>
   gpio_error ge = gpio_setup_pin(&gpio_Flash_WD);<br>
   if (ge != GPIO_NO_ERROR)<br>
       return FLASH_WRITE_LOCK_FAIL;<br>
<br>
   ....<br>
<br>
    gpio_output(gpio_Flash_WD.pin, GPIO_FLASH_WD_EN);<br>
<br>
   ....<br>
<br>
I need to set the voltage on the pin on the Zynq but this is Zynq specific.<br>
<br>
We need a way to let a user convey specific hardware details to the BSP<br>
driver through the API plus we need a light weight API with minimal<br>
internal translations. This approach also lets me define an array of<br>
pins and a single set up call configures them.<br>
<br>
So you could have:<br>
<br>
typedef struct<br>
{<br>
    int   pin;       /* The pin number. */<br>
    bool  output;    /* True for output, false for input. */<br>
    bool  on;        /* True default output is on */<br>
    bool  outen;     /* True for output enable on, false for off. */<br>
    bool  pullup;    /* True to enable the pull up. */<br>
    bool  tristate;  /* True to enable tri-state. */<br>
    void* platform;  /* Opaque hardware specific set up details. */<br>
} gpio_pin_def;<br>
<br>
where the 'platform' references a struct agreed between the BSP (or<br>
device layer) and the user code. For the generic cases this is not<br>
needed and NULL. It also allows layering where a device set up phase of<br>
user code sets the voltages and the generic code can play with the pin<br>
at a generic level, eg direction etc.<br>
<br>
What locking is being considered in this API ?<br>
<span><font color="#888888"><br>
Chris<br>
</font></span></blockquote></div><br></div>
</div></div></blockquote></div><br></div>