vikrant8052
commented
5 years ago @carlescufi Is that mean I have to update said Apps (via submitting new PRs) with latest GPIO APIs ?
Closed carlescufi closed 4 years ago
vikrant8052
commented
5 years ago @carlescufi Is that mean I have to update said Apps (via submitting new PRs) with latest GPIO APIs ?
carlescufi
commented
5 years ago @carlescufi Is that mean I have to update said Apps (via submitting new PRs) with latest GPIO APIs ?
Yes, please. Send a Pull Request against the topic-gpio branch, since that is the branch we are targeting, not master.
vikrant8052
commented
5 years ago @carlescufi
https://github.com/zephyrproject-rtos/zephyr/pull/16648/commits/ff873b8a49b30cc7b20c91d7fee058d30d060d33 & we have to take reference from this link for modifications (for nrfx). right ?
carlescufi
commented
5 years ago @carlescufi
ff873b8 & we have to take reference from this link for modifications (for nrfx). right ?
That is modifying an actual GPIO driver, not a user of it. Take a look at the one of the PRs listed in the table in the main description of the issue to get a better feeling.
pabigot
commented
5 years ago @vikrant8051 Specifically you should look at the commits with these subjects:
since the only GPIO use in the samples you're responsible for are toggling LEDs and responding to button presses. The only significant change in API will be in button handling.
(Note: The SHA1s above will change when the topic-branch is updated, so look for the commit message if you can't find them.)
pabigot
commented
5 years ago Some notes on converting GPIO users. If this is useful it may be edited for clarifications/extensions.
If you capture devicetree GPIOS_PIN information in a configuration structure, you should now also capture devicetree GPIOS_FLAGS information so it can be passed to gpio_pin_configure along with any direction/pull/other flags. Pin values should be stored as type gpio_pin_t, and flag values recorded from GPIOS_FLAGS as gpio_devicetree_flags_t (soon to be gpio_dt_flags_t). Note that gpio_dt_flags_t will not record flags that are not provided through devicetree, e.g. direction. If you are augmenting the flags from devicetree with other flags, use gpio_flags_t.
Don't make people search out the datasheet to figure out what the active level for a signal should be. Document in the device bindings the active level of each signal as produced/consumed by the device, and add a note that the flags value in the devicetree node should reflect any inversion performed between the device and the GPIO line.
Ensure that all devicetree nodes include GPIO_ACTIVE_HIGH or GPIO_ACTIVE_LOW as appropriate for the GPIO signal path.
sensors/drivers/hts221 (merged) provides a basic example of how to handle data-ready interrupts in the new infrastructure. Several platforms don't support level triggers, so the best practice is to use edge triggers. Some sensors produce level signals which require an operation (like reading the data) to clear the signal.
Be aware that on board reset a level ready signal may already be asserted and if so no observation reports will be triggered. Thus it's important to check the signal state and trigger a handle operation if already signalled.
sensors/drivers/sht3xd (#20295) shows an example of configuring triggers. It's mostly the same as for data-ready, but isn't enabled until the trigger is configured. Be aware that just as with data-ready device reset may have left the signal asserted so handling it when enabling is required here too.
A working idiom to handle interrupts is exemplified in the converted driver for st,hts221 (PENDING: See also #21548):
setup_signal(dev, enable) function that invokes gpio_pin_interrupt_configure() with GPIO_INT_DISABLE or (usually) GPIO_INT_EDGE_TO_ACTIVE based on the value of the passed enable flag.handle_signal(dev) function that invokes setup_signal() to disable the interrupt, then processes the interrupt (signals a semaphore, queues a work item)process_signal(dev) function that's run from the thread or work callback to retrieve the sample and do whatever is appropriate.gpio_pin_configure() and gpio_add_callback() for the signal initializing the trigger infrastructure.setup_signal(dev, false)setup_signal(dev, true) then read the signal and if it's asserted invoke handle_signal(dev). This ensures that we don't miss a transition that occured before the interrupt was enabled.NOTE Some drivers may use gpio_pin_write(..., ACTIVE) where the driver currently defines ACTIVE as zero or non-zero. A complete conversion solution would update the driver to use gpio_pin_set(..., 0) (or 1) and specify the active level in the devicetree flags. A minimal conversion may be achieved by using gpio_pin_set_raw(..., ACTIVE).
jenmwms
commented
4 years ago Can someone please explain the reasoning to remove tests/boards/intel_s1000_crb? I need to include rationale in the commit for #21471 . Any thoughts, @dcpleung, @carlescufi?
avisconti
commented
4 years ago @carlescufi I am still owner of the following 3 items: lis2dh, lis2ds12, lsm9ds0_gyro. I am not sure I'll be able to complete them in the timeframe, as I have other urgencies till end of January. Is there anyone who can volunteer on those tasks?
avisconti
commented
4 years ago @carlescufi I am still owner of the following 3 items: lis2dh, lis2ds12, lsm9ds0_gyro. I am not sure I'll be able to complete them in the timeframe, as I have other urgencies till end of January. Is there anyone who can volunteer on those tasks?
OK, I changed also lis2ds12 (see #22040). I think I'll not be able to proceed with the remaining two (lis2dh and lsm9ds0_gyro).
pabigot
commented
4 years ago I think I'm tapped to handle anything that's left over, which I will do but I can't test them unless somebody can identify a shield or inexpensive supported dev board that has them.
avisconti
commented
4 years ago I think I'm tapped to handle anything that's left over, which I will do but I can't test them unless somebody can identify a shield or inexpensive supported dev board that has them.
Maybe we can just test the compilation for the moment? Let see what @erwango and @carlescufi have to say.
pabigot
commented
4 years ago Yes, we have agreement that build-test is sufficient so we can make progress, but we're also supposed to annotate devices that have not been verified on real hardware somehow. AFAIK there is no documentation of how that's to be done.
carlescufi
commented
4 years ago @avisconti yes, that is the agreement for this particular branch at least. @pabigot This should come together with the discussion about how to document stability per-API. It can either be done in Doxygen or else in the upcoming maintainers file.
avisconti
commented
4 years ago @carlescufi @pabigot I removed my ownership for lis2dh and lsm9ds0_gyro.
carlescufi
commented
4 years ago @carlescufi @pabigot I removed my ownership for lis2dh and lsm9ds0_gyro.
OK, thanks. @pabigot will take those two.
pabigot
commented
4 years ago All identified conversions have been completed. Any more that are discovered will be addressed when topic-gpio merges to master, or in master.
List of users to convert:
Boards (DONE)
boards/arm/mimxrt1020_evkboards/arm/mimxrt1050_evkboards/arm/mimxrt1060_evkboards/arm/mimxrt1064_evkDrivers
Samples
Other (DONE)
Sensors (DONE)