Skip to content
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

bme280 sample does not compile #23148

Closed
mbolivar opened this issue Feb 28, 2020 · 3 comments · Fixed by #23235
Closed

bme280 sample does not compile #23148

mbolivar opened this issue Feb 28, 2020 · 3 comments · Fixed by #23235
Assignees
Labels
bug The issue is a bug, or the PR is fixing a bug priority: high High impact/importance bug
Milestone

Comments

@mbolivar
Copy link
Contributor

Describe the bug
The https://docs.zephyrproject.org/latest/samples/sensor/bme280/README.html build instructions do not build. The recommended board (nrf52840_pca10056) doesn't have that sensor in its DTS, so the reason why is clear, but all in-tree samples should compile.

I am unable to find a board in tree which does have this sensor in its DTS.

It's not clear to me whether or how mainline CI is building this sample. It seems like the fixture restriction is bypassing it:

sanitycheck -vv -T samples/sensor/bme280/ -p nrf52840_pca10056
...
DEBUG   - nrf52840_pca10056         samples/sensor/bme280/sample.sensor.bme280         SKIPPED: No hardware support
DEBUG   - nrf52840_pca10056         samples/sensor/bme280/sample.sensor.bme280.spi     SKIPPED: No hardware support

To Reproduce
Steps to reproduce the behavior:

  1. cd zephyr
  2. west build -b nrf52840_pca10056 samples/sensor/bme280
  3. observe build error
In file included from /home/mbolivar/zp/zephyr/drivers/sensor/bme280/bme280.c:24:0:
/home/mbolivar/zp/zephyr/drivers/sensor/bme280/bme280.h:114:2: error: #error "BME280 device type not specified"
 #error "BME280 device type not specified"
  ^~~~~
/home/mbolivar/zp/zephyr/drivers/sensor/bme280/bme280.c: In function 'bme280_init':
/home/mbolivar/zp/zephyr/drivers/sensor/bme280/bme280.c:370:22: warning: unused variable 'data' [-Wunused-variable]
  struct bme280_data *data = dev->driver_data;
                      ^~~~
In file included from ../include/drivers/sensor.h:23:0,
                 from /home/mbolivar/zp/zephyr/drivers/sensor/bme280/bme280.c:11:
/home/mbolivar/zp/zephyr/drivers/sensor/bme280/bme280.c: At top level:
/home/mbolivar/zp/zephyr/drivers/sensor/bme280/bme280.c:398:29: error: 'DT_INST_0_BOSCH_BME280_LABEL' undeclared here (not in a function); did you mean 'DT_INST_0_SOC_NV_FLASH_LABEL'?
 DEVICE_AND_API_INIT(bme280, DT_INST_0_BOSCH_BME280_LABEL, bme280_init, &bme280_data,
                             ^
../include/device.h:106:11: note: in definition of macro 'DEVICE_AND_API_INIT'
   .name = drv_name, .init = (init_fn),     \
           ^~~~~~~~

Expected behavior
Following build instructions for built-in samples should not result in compile errors.

Environment (please complete the following information):

  • Commit SHA or Version used: today's master (b96477d)
@mbolivar mbolivar added the bug The issue is a bug, or the PR is fixing a bug label Feb 28, 2020
@jhedberg jhedberg added the priority: high High impact/importance bug label Mar 3, 2020
@jhedberg jhedberg added this to the v2.2.0 milestone Mar 3, 2020
@nashif
Copy link
Member

nashif commented Mar 4, 2020

is this really a high prio bug?

@jhedberg
Copy link
Member

jhedberg commented Mar 4, 2020

is this really a high prio bug?

Well, a non-building sample in the tree was something we decided we want fixed before the release (doesn't really matter what the priority is, but setting high forces it to be done). This was at least the consensus in yesterday's release meeting.

carlescufi added a commit to carlescufi/zephyr that referenced this issue Mar 4, 2020
And an overlay for the nRF52840 DK to be able to build the sample after
the transition to Device Tree.

Fixes zephyrproject-rtos#23148.

Signed-off-by: Carles Cufi <[email protected]>
jhedberg pushed a commit that referenced this issue Mar 4, 2020
And an overlay for the nRF52840 DK to be able to build the sample after
the transition to Device Tree.

Fixes #23148.

Signed-off-by: Carles Cufi <[email protected]>
@nashif
Copy link
Member

nashif commented Mar 5, 2020

doesn't really matter what the priority is, but setting high forces it to be done

This is bad, high priority bugs should really be reserved to bugs that are more critical than a sample that does not build due to some missing overlay...

hakehuang pushed a commit to hakehuang/zephyr that referenced this issue Mar 18, 2020
And an overlay for the nRF52840 DK to be able to build the sample after
the transition to Device Tree.

Fixes zephyrproject-rtos#23148.

Signed-off-by: Carles Cufi <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug The issue is a bug, or the PR is fixing a bug priority: high High impact/importance bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants