Adafruit_ADXL343 Library Throwing Error

[craigfoo]

EDIT: I rolled back the library to version 1.2.0 and it fixed the issue.

I'm developing with a ATTiny3216 dev board and I can flash it through PlatformIO just fine. But, when I bring in the Adafruit_ADXL343 library, it's complaining about a few things:

Processing ATtiny3216 (platform: atmelmegaavr; board: ATtiny3216; framework: arduino)
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/atmelmegaavr/ATtiny3216.html
PLATFORM: Atmel megaAVR (1.4.0) > ATtiny3216    
HARDWARE: ATTINY3216 16MHz, 2KB RAM, 32KB Flash 
PACKAGES:
 - framework-arduino-megaavr-megatinycore 2.1.5 
 - toolchain-atmelavr 2.70300.201015 (7.3.0)    
LDF: Library Dependency Finder -> http://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 16 compatible libraries
Scanning dependencies...
Dependency Graph
|-- <Adafruit ADXL343> 1.3.0
|   |-- <Adafruit BusIO> 1.9.1
|   |   |-- <Wire> 1.0
|   |   |-- <SPI> 1.0
|   |-- <Wire> 1.0
|   |-- <SPI> 1.0
|   |-- <Adafruit Unified Sensor> 1.1.4
|-- <Adafruit NeoPixel> 1.8.5
Building in release mode
Compiling .pio\build\ATtiny3216\src\main.cpp.o
Compiling .pio\build\ATtiny3216\lib7a8\Wire\Wire.cpp.o
Compiling .pio\build\ATtiny3216\lib7a8\Wire\utility\twi.c.o
Compiling .pio\build\ATtiny3216\lib04a\SPI\SPI.cpp.o
In file included from .pio\libdeps\ATtiny3216\Adafruit BusIO/Adafruit_BusIO_Register.h:2:0,
                 from .pio\libdeps\ATtiny3216\Adafruit ADXL343/Adafruit_ADXL343.h:27,
                 from src\main.cpp:2:
.pio\libdeps\ATtiny3216\Adafruit BusIO/Adafruit_SPIDevice.h:37:9: error: 'BitOrder' does not name a type
 typedef BitOrder BusIOBitOrder;
         ^~~~~~~~
.pio\libdeps\ATtiny3216\Adafruit BusIO/Adafruit_SPIDevice.h:67:22: error: 'BusIOBitOrder' has not been declared
                      BusIOBitOrder dataOrder = SPI_BITORDER_MSBFIRST,
                      ^~~~~~~~~~~~~
.pio\libdeps\ATtiny3216\Adafruit BusIO/Adafruit_SPIDevice.h:72:22: error: 'BusIOBitOrder' has not been declared
                      BusIOBitOrder dataOrder = SPI_BITORDER_MSBFIRST,
                      ^~~~~~~~~~~~~
.pio\libdeps\ATtiny3216\Adafruit BusIO/Adafruit_SPIDevice.h:93:3: error: 'BusIOBitOrder' does not name a type
   BusIOBitOrder _dataOrder;
   ^~~~~~~~~~~~~
*** [.pio\build\ATtiny3216\src\main.cpp.o] Error 1
=========================================================================== [FAILED] Took 1.43 seconds ===========================================================================

Environment    Status    Duration
-------------  --------  ------------
ATtiny3216     FAILED    00:00:01.431
====================================================================== 1 failed, 0 succeeded in 00:00:01.431 ======================================================================

I'm not sure where to go from here. Any thoughts on these errors?

[SpenceKonde]

Oh for fucks sake? I thought they've been testing the for enums and not assuming their presence on all megaavr for ages (they were a mindbogglingly stupid "feature" the official megaavr core has. they defined enum types for things that could only have limited options. Of course that broke all the existing code so they watered it down with compatibility layers. But at that point, it no longer served it's original purpose and just made things worse). I more or less gave up on the hope that the original cores would ever not suck around that time.

But I thought that the Adafruit libraries were aware that nobodty other than the official core was actually using the damned things ages ago, and detected that and didn't use them.... what the fucking hell...

[SpenceKonde]

OH!!! They DO

// some modern SPI definitions don't have BitOrder enum
#if (defined(__AVR__) && !defined(ARDUINO_ARCH_MEGAAVR)) ||                    \
    defined(ESP8266) || defined(TEENSYDUINO) || defined(SPARK) ||              \
    defined(ARDUINO_ARCH_SPRESENSE) || defined(MEGATINYCORE) ||                \
    defined(DXCORE) || defined(ARDUINO_AVR_ATmega4809) ||                      \
    defined(ARDUINO_AVR_ATmega4808) || defined(ARDUINO_AVR_ATmega3209) ||      \
    defined(ARDUINO_AVR_ATmega3208) || defined(ARDUINO_AVR_ATmega1609) ||      \
    defined(ARDUINO_AVR_ATmega1608) || defined(ARDUINO_AVR_ATmega809) ||       \
    defined(ARDUINO_AVR_ATmega808) || defined(ARDUINO_ARCH_ARC32)

[SpenceKonde]

Ah yeah, that's because the MEGATINYCORE define is getting swallowed by PIO.

I added a workaround for that in megaTinyCore 2.3.0 that detects the case where the MEGATINYCORE define that supposed to be getting passed down from platform.txt gets lost due to some unknown bug in PIO and defines it to a placeholder value to it is at least defined (it's supposed to be defined as the version represented as a string).

Version 2.1.5 of megaTinyCore is ANCIENT man....

[craigfoo]

Thanks for looking it and good call on the old ass megaTinyCore. Next mission is to figure out how to upgrade it within PIO...

[SpenceKonde]

Ugh. Yeah - one of the things I really dislike about PIO (I've never used it, I just mean as a guy answering issues from y'all) is that they bundle all these packages together, but hardly ever update them, They still don't have DxCore either, right? I told them they can go ahead and use my compiler package as long as they host it somewhere else (it costs me a few fractions of a cent every time anyone installs my core except on x64 linux; I don't want to try to find out h ow much traffic I can generate before github gets mad at me for hosting large binaries on their servers for free; x64 linux is the exception because that's what the github actions CI testing runs on, and if that were someplace other than github, neither me nor github would be happy, and it's also a small minority of the population, so the traffic it generates is less likely to arouse the ire of github than if I hosted the windows binaries here).

Either don't bundle anything and make people download them themselves, or keep the versions you distribute up to date. Don't bundle stuff so nobody knows the install procedure, and then leave old versions rusting there, generating support inquiries for problems fixed a year ago.