BME680 and ATTiny1614

[Knochi]

Hi,

I'm working on a project utilizing the Bosch BME680 gas sensor.
I tried to include a few different BME680 libraries with different outcome.

I tried with megaTinyCore v2.4.2 since i ran into the "nullpointer exception issue" with updating to 2.5. and don't want to lose all my other libraries.

edit: updated to 2.5.4.

Library name	Author	Version	result 2.4.2	result 2.5.4
Adafruit BME680 Library	Adafruit	2.0.1	doesn't compile	99% flash 18% RAM
BME680	SV-Zanshin	1.0.10	doesn't compile	doesn't compile
BSEC Software Library	Bosch Sensortec	1.6.1480	INCOMPATIBLE	INCOMPATIBLE
FaBo 222 Environment BME680	Akira Sasaki	1.0.0	INCOMPATIBLE	INCOMPATIBLE
ClosedCube BME680	ClosedCube	1.2.0	59% flash 21% RAM	57% flash 20% RAM

Adafruit BME680 "BME680test" and the SV-Zanshin "I2CDemo" examples doesn't compile with:

c:/users/xxx/appdata/local/arduino15/packages/dxcore/tools/avr-gcc/7.3.0-atmel3.6.1-azduino4b/bin/../lib/gcc/avr/7.3.0/../../../../avr/bin/ld.exe: C:\Users\xxx\AppData\Local\Temp\arduino_build_999556/bme680test.ino.elf section `.rodata' will not fit in region `text'
c:/users/xxx/appdata/local/arduino15/packages/dxcore/tools/avr-gcc/7.3.0-atmel3.6.1-azduino4b/bin/../lib/gcc/avr/7.3.0/../../../../avr/bin/ld.exe: region `text' overflowed by 43 bytes
C:\Users\xxx\AppData\Local\Temp\ccaxjNN3.ltrans0.ltrans.o: In function `main':
<artificial>:(.text.startup+0x152): undefined reference to `operator delete(void*, unsigned int)'
collect2.exe: error: ld returned 1 exit status

The CloseCube Examples ("tph" and "tphg") compile and I will go on with these. But from my current understanding this isn't as high sophisticated as the adafruit one.

Can someone explain why the adafruit library doesn't compile? I guess it's a resource (memory) problem with the attiny.

edit:
regarding to this page you need the BSEC Library, which is closed-source, to calculate the air quality index (IAQ) from the values, which is not recommended for AVR at all.

Thanks
David

[SpenceKonde]

The compiled code does not fit in the flash.
region 'text' overflowed by 43 bytes

2.5.x brings improvements to flash usage with the Wire library, so that's why it compiles on 2.5.x but not 2.4.x

You might want to consider an ATtiny3224 - they're now available!

[SpenceKonde]

as an aside, someone with time to waste could pick apart that compiled library - extract the .a with avr-ar, dump the relocation table and the code with avr-objdump....

(I also at one point was dismayed to discover that the IAQ sensing actually couldn't be done without a proprietary library.

Actually probably easier to just compile sketch for the 2560, dump assembly listing, and go from there. That would at least handle the relocation table stuff for you, so you'd only have to sort through the hideous compiler generated assembly. A quick look at the IAQEstimator code indicates that it's a shitload of calculations of which every part is done using floating point math. No wonder it's bloated. And of course, all the intermediate values are stored on the stack. and because its' compiler generated, nothing is done to make it readable. Though it also wasn't intentionally obfuscated.

Was built with avr-gcc 5.8, and 3.6.2 build 1778 of the gnu tools.

Would be a good exercise for someone who has plenty of time on their hands and wants to get good at AVR assembly. And a public service :-P

[Raphasha27]

The root cause is your static field initialization timing:

private static Logger logger = LoggerFactory.getLogger(SomeLoggingClass.class);

When tests run sequentially:

1. First test: MockedStatic<LoggerFactory> is active → LoggerFactory.getLogger() returns your mock → logger is now a Mockito mock
2. End of first test: MockedStatic closes → mock stubs are removed but logger field still references the old mock
3. Second test: New MockedStatic + new mock created, but SomeLoggingClass.logger is already initialized — it still points to the dead mock from step 1
4. Result: doSomething() operates on the dead mock → interactions go nowhere → verify fails

Recommended Fix: Use a Logback ListAppender Instead

Mocking LoggerFactory is fragile because of class loading. The idiomatic approach for SLF4J + Logback is a test appender:

<!-- Make sure logback-classic is on test classpath -->
<dependency>
    <groupId>ch.qos.logback</groupId>
    <artifactId>logback-classic</artifactId>
    <version>1.5.13</version>
    <scope>test</scope>
</dependency>

import ch.qos.logback.core.read.ListAppender;
import ch.qos.logback.classic.spi.ILoggingEvent;
import ch.qos.logback.classic.Logger;
import org.slf4j.LoggerFactory;
import static org.assertj.core.api.Assertions.assertThat;

@Test
public void testLoggingWithFaultyParams() {
    Logger logbackLogger = (Logger) LoggerFactory.getLogger(SomeLoggingClass.class);
    ListAppender<ILoggingEvent> listAppender = new ListAppender<>();
    listAppender.start();
    logbackLogger.addAppender(listAppender);

    SomeLoggingClass.doSomething(null);

    assertThat(listAppender.list)
        .hasSize(1)
        .anySatisfy(event -> {
            assertThat(event.getLevel().toString()).isEqualTo("WARN");
            assertThat(event.getMessage()).isEqualTo("doSomething(): can't work with null");
        });
}

@Test
public void testLoggingWithGoodParams() {
    Logger logbackLogger = (Logger) LoggerFactory.getLogger(SomeLoggingClass.class);
    ListAppender<ILoggingEvent> listAppender = new ListAppender<>();
    listAppender.start();
    logbackLogger.addAppender(listAppender);

    SomeLoggingClass.doNothing("someValue");

    assertThat(listAppender.list)
        .hasSize(2)
        .anySatisfy(event -> {
            assertThat(event.getLevel().toString()).isEqualTo("INFO");
            assertThat(event.getMessage()).isEqualTo("doSomething(): all went well!");
        });
}

Why this works: ListAppender captures real log events without mocking the LoggerFactory at all. There's no static mock state to leak between tests — each test adds its own appender and clears listAppender.list (or re-creates it). No class-loading issues, no dead mocks, no flaky test ordering.

If You Must Mock

If you really need to mock (e.g., verify exact count on a warn vs info), use ReflectionTestUtils from Spring to reset the field between tests:

@After
public void resetLogger() throws Exception {
    Field field = SomeLoggingClass.class.getDeclaredField("logger");
    field.setAccessible(true);
    field.set(null, null);  // force re-initialization on next call
}

But the ListAppender approach is cleaner and more maintainable.