On Wed, Jun 10, 2015 at 7:09 PM, Chris Johns <chr...@rtems.org> wrote: > On 11/06/2015 3:01 am, Gedare Bloom wrote: >> On Mon, Jun 8, 2015 at 5:44 AM, André Marques >> <andre.lousa.marq...@gmail.com> wrote: >>> Hello, >>> >>> I have just updated my GSOC blog [1] with a detailed post about how a >>> rtems-wide GPIO API could look like, and at the same time exposing the >>> current features of the Raspberry Pi GPIO API and how it can evolve to that >>> level. >>> >>> I tried to make it as generic and flexible as possible, but that can be hard >>> with the number of platforms where rtems can be used. Api and method naming >>> were somewhat overlooked, as well as the definition of possible error codes >>> since I am not sure if it would be correct to have a set of error codes for >>> this API, or if it should use rtems_status_code, or other. >>> >>> Current code for the Raspberry Pi GPIO API can be looked at in [2], where I >>> am currently carving out the rpi specific code. >>> >>> I tried to be as clear as possible in the blog, and now I would like to ask >>> any interested party to have a look and hopefully point failure points and >>> suggestions, or ask for clarifications. It would also be interesting to hear >>> the community expectations towards an API such as this one. >>> >> Great write-up. > > I agree, it is a nice write up. > >> Here are some comments/questions: >> - The "user application must fill a gpio_pin struct for every pin it >> needs" should probably be done through some set of API calls that help >> filling out that struct. I'd imagine some alloc with initialization, >> and dealloc, with most of the complexity in alloc/init. > > Being const lets you fill them out when coding as a table which I have > found easy to review plus being const has the advantage on small RAM > devices of only using ROM type storage which they usually have more of. > > I think an API to fill the struct in would be confusing and so think at > this point in time we should limit what we do. > OK that is fair. On the other hand, anything we can do to make the const initializer easier would be good. I especially was concerned by #ifdef's inside the initializer.
> I currently have 3 Zynq variants with similar IO requirements with very > different pin selections due to easier PCB routing and I have a separate > C file with pin definitions per variant. The resulting user code is > clean and simple. > That makes much more sense, where the struct definition will be pulled in through the build system logic to choose the correct file to compile. >> - The bsp_specific pointer might be better implemented with a >> zero-length array >> [https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html]. Since you embed >> the type of the struct, you can tell whether that array should have >> any data in it or not. >> - I wonder if eventually we can refactor all this to work with the >> libdrvmgr. This is a long-term question but might be one worth >> thinking about now. (libdrvmgr mainly focuses on providing >> abstractions for device drivers that attached to bus-based i/o >> protocols. You may like to take a look at its documentation.) > > I have not looked at that API so I cannot comment but I wonder if this > is outside the scope of this GSoC project. > Definitely outside the scope. > Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
