About dfrey

I'm having two problems while attempting to integrate BSEC on for gcc Cortex A7. I'm trying to build an application which links to a shared library which includes libalgobsec.a and some other code.  I'm running into problems during the linking phase. I have created a proof of concept that doesn't use BSEC so that I can demonstrate a possible solution (in addition to the problem).  I can't solve the problem with BSEC because I don't have the source code. The structure of the proof of concept is: test{main.c} -> libsaythings.so{saythings.c, libgreeting.a{hello.c, goodbye.c}} When I build the proof of concept with my ARM Cortex A7 toolchain, I get the following output: $ make arm-poky-linux-gnueabi-gcc  -march=armv7-a -mfpu=neon  -mfloat-abi=softfp --sysroot=/opt/swi/y22-ext-SWI9X07Y_02.22.00.00/sysroots/armv7a-neon-poky-linux-gnueabi -c -Ilibsaythings main.c arm-poky-linux-gnueabi-gcc  -march=armv7-a -mfpu=neon  -mfloat-abi=softfp --sysroot=/opt/swi/y22-ext-SWI9X07Y_02.22.00.00/sysroots/armv7a-neon-poky-linux-gnueabi -c -Ilibgreeting -fPIC -o libsaythings/saythings.o libsaythings/saythings.c arm-poky-linux-gnueabi-gcc  -march=armv7-a -mfpu=neon  -mfloat-abi=softfp --sysroot=/opt/swi/y22-ext-SWI9X07Y_02.22.00.00/sysroots/armv7a-neon-poky-linux-gnueabi -c  -o libgreeting/hello.o libgreeting/hello.c arm-poky-linux-gnueabi-gcc  -march=armv7-a -mfpu=neon  -mfloat-abi=softfp --sysroot=/opt/swi/y22-ext-SWI9X07Y_02.22.00.00/sysroots/armv7a-neon-poky-linux-gnueabi -c  -o libgreeting/goodbye.o libgreeting/goodbye.c ar rcs libgreeting/libgreeting.a libgreeting/hello.o libgreeting/goodbye.o arm-poky-linux-gnueabi-gcc  -march=armv7-a -mfpu=neon  -mfloat-abi=softfp --sysroot=/opt/swi/y22-ext-SWI9X07Y_02.22.00.00/sysroots/armv7a-neon-poky-linux-gnueabi -shared -o libsaythings/libsaythings.so libsaythings/saythings.o libgreeting/libgreeting.a /opt/swi/y22-ext-SWI9X07Y_02.22.00.00/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/6.2.0/real-ld: libgreeting/libgreeting.a(hello.o): relocation R_ARM_MOVW_ABS_NC against `a local symbol' can not be used when making a shared object; recompile with -fPIC libgreeting/libgreeting.a: error adding symbols: Bad value collect2: error: ld returned 1 exit status Makefile:20: recipe for target 'libsaythings/libsaythings.so' failed make: *** [libsaythings/libsaythings.so] Error 1 If I then run "make clean" and set STATIC_LIB_OPTS=-fPIC in the Makefile and try again, the build is successful. So a possible solution is for Bosch to compile the .c files within BSEC using -fPIC.  Would Bosch be willing to do this for the gcc Cortex A7 version?  I'm also open to hearing other suggestions.  The problem goes away if you structure the application like this: test{main.c, saythings.c, libgreeting.a{hello.c, goodbye.c}} I consider that a non-solution to the problem since it prevents the use of any shared libraries on top of BSEC.   The second (more minor) problem I'm having is that I think libalgobsec.a was built with -fshort-enums.  This causes warnings like this to be emitted when the code that links to it is not built with -fshort-enums. /opt/swi/y22-ext-SWI9X07Y_02.22.00.00/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/6.2.0/real-ld: warning: libgreeting/libgreeting.a(goodbye.o) uses variable-size enums yet the output is to use 32-bit enums; use of enum values across objects may fail Is there a reason why the gcc Cortex A7 version of BSEC is built with -fshort-enums?  I think it would be better to build without that option.  The gcc manpage has this to say about -fshort-enum: Warning: the -fshort-enums switch causes GCC to generate code that is not binary compatible with code generated without that switch.  Use it to conform to a non-default application binary interface. ... View more

I'm looking at the BME680 datasheet and I have some questions about the following fields: reg field purpose meas_status_0 measuring Reads as 1 when a TPHG conversion is active and 0 when the results are transferred to the data registers meas_status_0 gas_measuring Changes to 1 during gas measurement phase and then changes to 0 once the gas measurement has been transferred to the data registers meas_status_0 new_data_0 Is new data available? yes (1), no (0). I believe this is set to 0 when a measurement is initiated by writing 1 to ctrl_meas.mode and thus entering "forced" mode gas_r_lsb heat_stab_r Did the heater reach the temperature specified? yes (1), no (0) gas_r_lsb gas_valid_r Is the gas data in the register real (1) or dummy (0)   Is meas_status_0.measuring just an inverted version of meas_status_0.new_data_0?  If not, how are they different? What is the purpose of meas_status_0.gas_measuring?  Why would a driver care when the gas measurement is active?  Isn't it sufficient to just look at the measuring or new_data_0 fields to know when the whole TPHG cycle is complete? I believe gas_valid_r indicates whether the value in the data register is a real value or a dummy value.  If I set ctrl_gas_1.run_gas=1 before entering forced mode, then why would the value be a dummy? Are the dummy values at all meaningful or are they just garbage that should be discarded? ... View more