On Tue, Jun 16, 2015 at 8:14 AM, André Marques <andre.lousa.marq...@gmail.com> wrote: > Hello , > > Thank you for the responses. Sorry for the late response and lengthy mail. > > At this point the features mentioned in the blog post are almost done in the > code (apart from some details). There are some differences from what is > mentioned in the blog, but the overall idea still stands (an blog update is > in order, as well as more documentation in the code). > > One major change is related with the interaction with the API. It currently > maintains a data structure which holds the current GPIO status (which pins > are used, what interrupt handlers they have associated, ...), so an > application can either fill a different structure to configure a pin, which > is passed to the API through an API call, or configure the pin directly > through API calls. > > The struct approach can be used either to define a new pin to be requested, > or to update its configuration, all done by updating/changing the struct and > doing the same function call to the API. Since the structs can be defined on > a separate file, the application code can be the same across different > platforms, as the only diference is the configuration file that is > used/called. The platform specific configuration (which pin in y platform > corresponds to the warning led?) for an application would then be reduced to > file management. > > The API call that does the processing of these structs parses them and does > the necessary API calls to setup/update the GPIO hardware as needed. > > By having both a struct based interface and direct API call options an user > can choose what is best for their need. The direct API calls can be > specially useful for an interactive usage, through a shell program. > > The current implementation for the above can be seen in [1], [2] and [3]. > Note that the gpio.c and gpio.h can be anywhere else at this point, as they > do not have any rpi code anymore (another question is where they could go > then?). > I think the first place to migrate shared code is libbsp/shared. After that, we can consider whether the code is generic enough to put in cpukit, which is where other driver frameworks (i2c, libdrvmgr) have landed recently.
> A pending issue is related with pin definitions. It would be useful if after > the pin request to the API, the application could have a gpio_pin_id which > would be used as a reference to an application pin. > > Small example with direct API call: > > gpio_pin_id warning_led; > > gpio_request_pin(RPI_GPIO_23, &warning_led, DIGITAL_OUT, ..); > > gpio_set(warning_led); > > The RPI_GPIO_23 would be the platform pin number (the API calculates the > bank and pin number from this), but after the request the application uses > the gpio_pin_id to refer to it. The gpio_pin_id would be a simple struct > filled by the API with the calculated bank and pin numbers, which no one > else is supposed (or have the need to) to modify/use this struct other than > to pass it to the API to refer to a pin. This would also avoid the constant > bank/pin numbers calculation and pin number boundary validation that is made > currenty in every API call. > That makes sense. You could define an opaque type to store the identifier. However, if it is a struct, passing it by value could be an expensive operation, so care should be taken there. (If you can fit it in 32-bits, you can union the gpio_pin_id with a uint32_t) > A final note would be the need for multiple pin operations. The rpi and most > platforms (I suppose) allow several pins to be defined on a single call, by > writting a more complete bitmask to the registers. This could be a challenge > with the struct approach (maybe by having pin arrays, instead of a single > pin in the struct, if they all share the same configuration). As for direct > pin calls maybe through variadic functions. I just got done writing about zero-length arrays for Yang Qiao [https://github.com/yangqiao/rtems/commit/38c26a49126e5cff92ae389dba252cb180362c90#commitcomment-11707035], but perhaps you could use something similar albeit simpler in this case too. You define the pin as a zero-length array (it should always be at least 1 though), and then include the number of pins in the struct. > > [1] - > https://github.com/asuol/rtems/tree/GPIO_API/c/src/lib/libbsp/arm/raspberrypi/gpio > [2] - > https://github.com/asuol/rtems/blob/GPIO_API/c/src/lib/libbsp/arm/raspberrypi/include/gpio.h > [3] - > https://github.com/asuol/rtems/blob/GPIO_API/c/src/lib/libbsp/arm/raspberrypi/include/rpi-gpio.h > > --André Marques. > > > On 11-06-2015 15:13, Gedare Bloom wrote: >> >> 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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
