12-14-2019 06:42 AM - edited 12-14-2019 06:43 AM
Hi,
I'd like confirmation of a probable bug in the BSEC_integration.c file, in the bsec_iot_init function. It reads:
return_values_init bsec_iot_init(uint8_t deviceAddr, float sample_rate, float temperature_offset, bme680_com_fptr_t bus_write, bme680_com_fptr_t bus_read, sleep_fct sleep, state_load_fct state_load, config_load_fct config_load) { return_values_init ret = {BME680_OK, BSEC_OK}; bsec_library_return_t bsec_status = BSEC_OK; uint8_t bsec_state[BSEC_MAX_PROPERTY_BLOB_SIZE] = {0}; // <--- BUG uint8_t bsec_config[BSEC_MAX_PROPERTY_BLOB_SIZE] = {0}; uint8_t work_buffer[BSEC_MAX_PROPERTY_BLOB_SIZE] = {0}; // <--- BUG int bsec_state_len, bsec_config_len;
and I'm pretty sure it should read:
return_values_init bsec_iot_init(uint8_t deviceAddr, float sample_rate, float temperature_offset, bme680_com_fptr_t bus_write, bme680_com_fptr_t bus_read, sleep_fct sleep, state_load_fct state_load, config_load_fct config_load) { return_values_init ret = {BME680_OK, BSEC_OK}; bsec_library_return_t bsec_status = BSEC_OK; uint8_t bsec_state[BSEC_MAX_STATE_BLOB_SIZE] = {0}; // <--- BUG fixed uint8_t bsec_config[BSEC_MAX_PROPERTY_BLOB_SIZE] = {0}; uint8_t work_buffer[BSEC_MAX_WORKBUFFER_SIZE] = {0}; // <--- BUG fixed int bsec_state_len, bsec_config_len;
Please let me know if this is indeed a bug. My app was crashing before the bug fix and is working now after the above fix.
It was crashing because bsec_iot_init was calling state_load with the wrong buffer size and the subsequent call to bsec_set_state was failing.
If this is confirmed to be a bug, how is it possible that no one else has discovered and reported this problem in the past two years?
Thank you,
Kevin
Solved! Go to Solution.
01-13-2020 03:45 PM
01-18-2020 11:54 PM - edited 01-18-2020 11:55 PM
I met some of the engineers at CES and explained how this should be done. They were more managers than engineers but said someone would eventually get back to me. We'll see...
Basically it has to be simple to implment for the developer, right? That way the uptake and onboarding will be simple and fast and and developers can stay focused on their project instead of trying to implement the sensor. I had to incorporate 12 files and fix a few bugs and tweak a little Bosch code to finally get the BSEC to work properly. And even then, it's (assumed) PID loop is integrating too slowly for my use case so ultimately I probably won't be able to use it.
From Bosch's end, to keep it simple for us developers, Bosch should provide a single file or two that contains all the code necessary to get the BSEC running. Just off the top of my head: that file should have just a single entry point to initialize everything (including telling the BSEC who the data consumer is), another single entry point to set settings like sample rate, voltage, etc., a single entry point to get a current sample (as an override), a single entry point to start or pause the system which will utilize best practices for energy management, and a single entry point to stop and release all resources.
This way, all the developer has to do is implement a few calls into their application to utilize the BSEC and they are good to go. This needs to be all well documented with plenty of examples to show how to properly utilize the BSEC, how to integrate the binary, some common pitfalls like memory issues, etc.
That's how I would implement this.
That all said, in an ideal scenario: everything the BSEC does should really be contained onboard the BME680 iself. It should not require a developer to implement libraries and such. There should just be I2C data transfers to get and set everythning needed by the BSEC. Right? That way NONE of the above has to be implemented by a developer and, again, they can just stay focused on their project.
Hope that helps. Contact me offline (my info was input into the iPad at the CES show) if you'ld like more input...
Take care, Kevin.