-
Couldn't load subscription status.
- Fork 8.1k
cmake: modules: shields: Introducing shield options #82825
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
e97a87d to
ce4ea3b
Compare
f382e92 to
9441086
Compare
a02fbd7 to
1be40c0
Compare
The it8801 template is helpful but in the current state it does not allow changing the device address as that is in the template itself. Fix that by moving the template content down a level in the hierarchy, so that it extends the mfd device itself rather than than instantiate it, then the base instance can have any address, now the only limitation is that only one instance is possible, but that is probably alright for now. Alternatives would be to use a define for the address, or even a template per address, but this feels like a better compromise for now. This may also use zephyrproject-rtos#82825 in the future if that ever becomes a thing. Signed-off-by: Fabio Baltieri <[email protected]>
The it8801 template is helpful but in the current state it does not allow changing the device address as that is in the template itself. Fix that by moving the template content down a level in the hierarchy, so that it extends the mfd device itself rather than than instantiate it, then the base instance can have any address, now the only limitation is that only one instance is possible, but that is probably alright for now. Alternatives would be to use a define for the address, or even a template per address, but this feels like a better compromise for now. This may also use zephyrproject-rtos#82825 in the future if that ever becomes a thing. Signed-off-by: Fabio Baltieri <[email protected]>
The it8801 template is helpful but in the current state it does not allow changing the device address as that is in the template itself. Fix that by moving the template content down a level in the hierarchy, so that it extends the mfd device itself rather than than instantiate it, then the base instance can have any address, now the only limitation is that only one instance is possible, but that is probably alright for now. Alternatives would be to use a define for the address, or even a template per address, but this feels like a better compromise for now. This may also use #82825 in the future if that ever becomes a thing. Signed-off-by: Fabio Baltieri <[email protected]>
The it8801 template is helpful but in the current state it does not allow changing the device address as that is in the template itself. Fix that by moving the template content down a level in the hierarchy, so that it extends the mfd device itself rather than than instantiate it, then the base instance can have any address, now the only limitation is that only one instance is possible, but that is probably alright for now. Alternatives would be to use a define for the address, or even a template per address, but this feels like a better compromise for now. This may also use zephyrproject-rtos/zephyr#82825 in the future if that ever becomes a thing. (cherry picked from commit b716b06) Original-Signed-off-by: Fabio Baltieri <[email protected]> GitOrigin-RevId: b716b06 Cr-Build-Id: 8726996916743985489 Cr-Build-Url: https://cr-buildbucket.appspot.com/build/8726996916743985489 Copybot-Job-Name: zephyr-main-copybot-downstream Change-Id: I9c5ef18d33e2854405fae39b0c519408195c19b6 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/zephyr/+/6135133 Tested-by: ChromeOS Prod (Robot) <[email protected]> Bot-Commit: ChromeOS Prod (Robot) <[email protected]> Commit-Queue: ChromeOS Prod (Robot) <[email protected]>
The it8801 template is helpful but in the current state it does not allow changing the device address as that is in the template itself. Fix that by moving the template content down a level in the hierarchy, so that it extends the mfd device itself rather than than instantiate it, then the base instance can have any address, now the only limitation is that only one instance is possible, but that is probably alright for now. Alternatives would be to use a define for the address, or even a template per address, but this feels like a better compromise for now. This may also use zephyrproject-rtos#82825 in the future if that ever becomes a thing. Signed-off-by: Fabio Baltieri <[email protected]>
a054f60 to
ec9099d
Compare
d3e816a to
aa056ca
Compare
Add dts/common directory to doxygen sources list. And updated `dts/common/freq.h` and `dts/common/mem.h` to generate readable API reference. Signed-off-by: TOKITA Hiroshi <[email protected]>
To create and tune multiple instances of shields, we are introducing shield options. We can now tweak the behavior of a shield by specifying options as a string after the shield name when building. To achieve this, we are changing how build and shield overlays work. See the documentation in this commit for more details. Signed-off-by: TOKITA Hiroshi <[email protected]>
Add shield definition for Seeed's LIS3DHTR accelerometer. This shield can take option to select connecting bus, so such like following example. ``` west build -p -b m5stack_atoms3/esp32s3/procpu --shield=seeed_grove_accel_lis3dhtr@1:addr=0x18 samples/sensor/lis2dh/ ``` Signed-off-by: TOKITA Hiroshi <[email protected]>
aa056ca to
8c6e421
Compare
|
This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time. |
|
This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time. |
|
This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time. |
|
This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time. |
With this change, the shield specified by
--shieldcan receivea connector name and various options.
This allows you to adapt the shield to your board at compile time.
Command line options:
which connects this device by appending @ after its name.
It can also append options separated with ":" to specify shield-specific
options. Multiple options can be assigned.
The format is as follows:
Derived overlay:
When you specify the connector to connect to, an overlay file is
generated that includes the @connector_name part of the connector name.
Here, we will call this a "derived overlay".
The derived overlay defines
the SHIELD_DERIVED_NAMEandSHIELD_DERIVED_NAME_DEFINEDmacros and including the original overlayfile. The overlay author can use helper macros to reflect options per
the derived definition.
Options and helper macros:
Options are defined in the format [key]=[value]. The value will be
treated as 1 if only the key is specified.
Helper macros are also defined to handle these options in overlays.
SHIELD_OPTION_DEFINED(opt)returns 0 or 1 to indicate whetheropt is defined.
SHIELD_OPTION(opt)returns the macro value corresponding to opt if itis defined. Otherwise, it returns the value of
SHIELD_DEFAULT_[opt].SHIELD_DEFAUILT_[opt]is automatically It is not generated,so you must explicitly define it in the overlay file.
Example:
For example, if you specify something like:
the automatically generated header will have a definition like
A derived overlay is also created with the file name
seeed_grove_lis3dhtr@grove_i2c1.overlay.In this case, the derived overlay will include
SHIELD_OPTION(CONNECTOR_NAME), You can reference these withSHIELD_OPTION(ADDR).To ensure that the helper macros work correctly in the original
overlay and not in a derived overlay,
you must define
SHIELD_DEFAULT_CONNECTOR_NAMEandSHIELD_DEFAULT_ADDR.You also need to take care not to duplicate labels, etc.
Finally, It will look like this:
By defining it like this,
you can connect this seeed_grove_lis3dhtr to any
grove connector.
As a result, you got processed dts such as follows.