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. 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. > - 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. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
