"Error compiling for board AVR DA-series (Optiboot)" with the Adafruit GFX Library

[spencekonde]

"Error compiling for board AVR DA-series (Optiboot)" with the Adafruit GFX Library

[SpenceKonde]

#include <SPI.h>
#include <Wire.h>
#include <Adafruit_GFX.h>
#include <Adafruit_SSD1306.h>

const uint8_t SCREEN_WIDTH = 128;
const uint8_t SCREEN_HEIGHT = 64;
const uint8_t OLED_RESET = 4;
Adafruit_SSD1306 display(SCREEN_WIDTH, SCREEN_HEIGHT, &Wire, OLED_RESET);

uint8_t BUFFER[64][16] = 
	{{0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
	{0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
	{0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
	{0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
	{0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
	{0x00, 0x00, 0x00, 0xe0, 0x03, 0x00, 0xfe, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
	{0x00, 0x00, 0x80, 0xff, 0x07, 0xf8, 0xff, 0x01, 0x00, 0x00, 0x00, 0xfe, 0x03, 0x00, 0x00, 0x00},
	{0x00, 0x00, 0xff, 0xff, 0x03, 0xfc, 0xff, 0x00, 0x00, 0x00, 0x00, 0xff, 0xff, 0x03, 0x00, 0x00},
	{0x40, 0xff, 0xff, 0x3f, 0x00, 0xfc, 0x03, 0x00, 0x00, 0xfc, 0x01, 0xfe, 0xff, 0xff, 0x00, 0x00},
	{0xe0, 0xff, 0x7f, 0x00, 0x00, 0x1c, 0x00, 0x00, 0x00, 0xff, 0x03, 0x00, 0xfc, 0xff, 0x01, 0x00},
	{0xe0, 0xff, 0x0e, 0x00, 0x00, 0x1c, 0x00, 0x00, 0xc0, 0xff, 0x01, 0x00, 0x78, 0xfc, 0x00, 0x00},
	{0xc0, 0x01, 0x0e, 0x00, 0x00, 0x1c, 0x00, 0x00, 0xe0, 0x03, 0x00, 0x00, 0x38, 0x00, 0x00, 0x00},
	{0x00, 0x00, 0x1c, 0x00, 0x00, 0x1c, 0x00, 0x00, 0xf0, 0x00, 0x00, 0x00, 0x38, 0x00, 0x00, 0x00},
	{0x00, 0x00, 0x1c, 0x00, 0x00, 0x1c, 0x00, 0x00, 0x70, 0x00, 0x00, 0x00, 0x38, 0x00, 0x00, 0x00},
	{0x00, 0x00, 0x1c, 0x00, 0x00, 0x1c, 0x00, 0x00, 0x38, 0x00, 0x00, 0x00, 0x38, 0x00, 0x00, 0x00},
	{0x00, 0x00, 0x1c, 0x00, 0x00, 0x1c, 0x00, 0x00, 0x38, 0x00, 0x00, 0x00, 0x38, 0x00, 0x00, 0x00},
	{0x00, 0x00, 0x38, 0x00, 0x00, 0x1c, 0x00, 0x00, 0x70, 0x00, 0x00, 0x00, 0x38, 0x00, 0x00, 0x00},
	{0x00, 0x00, 0x38, 0x00, 0x00, 0xfc, 0x3f, 0x00, 0x70, 0x00, 0x00, 0x00, 0x38, 0x00, 0x00, 0x00},
	{0x00, 0x00, 0x38, 0x00, 0x00, 0xfc, 0x7f, 0x00, 0xe0, 0x00, 0x00, 0x00, 0x38, 0x00, 0x00, 0x00},
	{0x00, 0x00, 0x38, 0x00, 0x00, 0xfe, 0x3f, 0x00, 0xc0, 0x01, 0x00, 0x00, 0x38, 0x00, 0x00, 0x00},
	{0x00, 0x00, 0x78, 0x00, 0x00, 0x0e, 0x00, 0x00, 0x80, 0x03, 0x00, 0x00, 0x1c, 0x00, 0x00, 0x00},
	{0x00, 0x00, 0x70, 0x00, 0x00, 0x0e, 0x00, 0x00, 0x00, 0x0f, 0x00, 0x00, 0x1c, 0x00, 0x00, 0x00},
	{0x00, 0x00, 0x70, 0x00, 0x00, 0x0e, 0x00, 0x00, 0x00, 0x1e, 0x00, 0x00, 0x1c, 0x00, 0x00, 0x00},
	{0x00, 0x00, 0x70, 0x00, 0x00, 0x0e, 0x00, 0x00, 0x00, 0x3c, 0x00, 0x00, 0x1c, 0x00, 0x00, 0x00},
	{0x00, 0x00, 0x70, 0x00, 0x00, 0x0e, 0x00, 0x00, 0x00, 0xf0, 0x00, 0x00, 0x1c, 0x00, 0x00, 0x00},
	{0x00, 0x00, 0xf0, 0x00, 0x00, 0x0e, 0x00, 0x00, 0x00, 0xe0, 0x01, 0x00, 0x1c, 0x00, 0x00, 0x00},
	{0x00, 0x00, 0xe0, 0x00, 0x00, 0x07, 0x00, 0x00, 0x00, 0xc0, 0x01, 0x00, 0x0e, 0x00, 0x00, 0x00},
	{0x00, 0x00, 0xe0, 0x00, 0x00, 0x07, 0x00, 0x00, 0x00, 0x80, 0x03, 0x00, 0x0e, 0x00, 0x00, 0x00},
	{0x00, 0x00, 0xe0, 0x00, 0x00, 0x07, 0x00, 0x00, 0x00, 0x00, 0x07, 0x00, 0x0e, 0x00, 0x00, 0x00},
	{0x00, 0x00, 0xe0, 0x00, 0x00, 0x07, 0x00, 0x00, 0x00, 0x00, 0x07, 0x00, 0x0e, 0x00, 0x00, 0x00},
	{0x00, 0x00, 0xe0, 0x00, 0x00, 0x07, 0x00, 0x00, 0x00, 0x00, 0x07, 0x00, 0x0e, 0x00, 0x00, 0x00},
	{0x00, 0x00, 0xe0, 0x00, 0x80, 0x03, 0xc0, 0x00, 0x00, 0x00, 0x07, 0x00, 0x0e, 0x00, 0x00, 0x00},
	{0x00, 0x00, 0xe0, 0x01, 0x80, 0x03, 0xe0, 0x01, 0x10, 0xc0, 0x03, 0x00, 0x04, 0x00, 0x00, 0x00},
	{0x00, 0x00, 0xc0, 0x01, 0x80, 0xff, 0xff, 0x00, 0x78, 0xf0, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00},
	{0x00, 0x00, 0xc0, 0x01, 0x80, 0xff, 0x7f, 0x00, 0xf0, 0xff, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
	{0x00, 0x00, 0xc0, 0x01, 0x00, 0xff, 0x1f, 0x00, 0xe0, 0x3f, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
	{0x00, 0x00, 0xc0, 0x01, 0x00, 0x00, 0x00, 0x00, 0xc0, 0x0f, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
	{0x00, 0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
	{0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
	{0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xf8, 0xff, 0x3f, 0x00, 0x00, 0x00},
	{0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xc0, 0xff, 0xff, 0xff, 0xff, 0xff, 0x0f, 0x00, 0x00},
	{0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xe0, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x1f, 0x00, 0x00},
	{0x00, 0x00, 0x00, 0x00, 0x00, 0xc0, 0xff, 0xff, 0xff, 0xff, 0x07, 0x00, 0xc0, 0x3f, 0x00, 0x00},
	{0x00, 0x00, 0x00, 0x00, 0x80, 0xff, 0xff, 0x3f, 0x00, 0x00, 0x00, 0x00, 0x00, 0x78, 0x00, 0x00},
	{0x00, 0x00, 0x00, 0x00, 0xff, 0xff, 0x1f, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xf0, 0x00, 0x00},
	{0x00, 0x80, 0x00, 0xff, 0xff, 0x3f, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xe0, 0x00, 0x00},
	{0x00, 0xc0, 0xff, 0xff, 0x7f, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xfe, 0x00, 0xe0, 0x00, 0x00},
	{0x00, 0x80, 0xff, 0xff, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xc0, 0xff, 0x03, 0xe0, 0x00, 0x00},
	{0x00, 0x00, 0xff, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xe0, 0xff, 0x07, 0xe0, 0x00, 0x00},
	{0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x40, 0x00, 0x00, 0x00, 0xf8, 0xf1, 0x07, 0xe0, 0x00, 0x00},
	{0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xe2, 0x00, 0x00, 0x00, 0x3c, 0xf8, 0x03, 0xf0, 0x00, 0x00},
	{0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x47, 0x00, 0x00, 0x00, 0x1e, 0xf0, 0x01, 0x7c, 0x00, 0x00},
	{0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02, 0x08, 0x00, 0x00, 0x07, 0x00, 0x80, 0x3f, 0x00, 0x00},
	{0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x1c, 0x00, 0x80, 0x03, 0x00, 0xf0, 0x0f, 0x00, 0x00},
	{0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x1e, 0x00, 0x80, 0x03, 0x80, 0xff, 0x03, 0x00, 0x00},
	{0x00, 0x00, 0x00, 0x00, 0x00, 0x20, 0x00, 0x0e, 0x00, 0x80, 0x03, 0xff, 0x7f, 0x00, 0x00, 0x00},
	{0x00, 0x00, 0x00, 0x00, 0x00, 0x70, 0x00, 0x0f, 0x00, 0x80, 0xff, 0xff, 0x0f, 0x00, 0x00, 0x00},
	{0x00, 0x00, 0x00, 0x00, 0x00, 0xf0, 0xe0, 0x07, 0x00, 0x00, 0xff, 0x7f, 0x00, 0x00, 0x00, 0x00},
	{0x00, 0x00, 0x00, 0x00, 0x00, 0xe0, 0xff, 0x03, 0x00, 0x00, 0xfc, 0x00, 0x00, 0x00, 0x00, 0x00},
	{0x00, 0x00, 0x00, 0x00, 0x00, 0xc0, 0xff, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
	{0x00, 0x00, 0x00, 0x00, 0x00, 0x80, 0x3f, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
	{0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
	{0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
	{0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}};


void setup(){
	Wire.begin();
	Serial.begin(9600);
	if (!display.begin(SSD1306_SWITCHCAPVCC, 0x3C)) {
		Serial.println(F("SSD1306 allocation failed"));
		while(true){};
	}
	
	delay(100);
	display.clearDisplay();
	delay(100);
	
}

void loop(){
	UpdateDisplay();
	while(true){};
}

void UpdateDisplay(){
	uint16_t x;
	uint16_t y;
	
	for (y = 0; y < SCREEN_HEIGHT; y++){
		for (x = 0; x < SCREEN_WIDTH; x++){
			display.drawPixel(x,y, bitRead(BUFFER[y][x / 8], x % 8));
		}
	}
	
	display.display();
}

Arduino: 1.8.13 (Windows 10), Board: "AVR DA-series (Optiboot), AVR128DA48, 24 MHz internal, No, 1.9V, Disabled/Disabled, Hardware Reset (recommended), TCB2, 8ms, 8 second (for use w/out autoreset), USART0: TX PA0, RX PA1"


In file included from c:\users\FFFFFF\appdata\local\arduino15\packages\arduino\tools\avr-gcc\7.3.0-atmel3.6.1-arduino7\avr\include\avr\io.h:619:0,

                 from c:\users\FFFFFF\appdata\local\arduino15\packages\arduino\tools\avr-gcc\7.3.0-atmel3.6.1-arduino7\avr\include\avr\pgmspace.h:90,

                 from C:\Users\FFFFFF\AppData\Local\Arduino15\packages\DxCore\hardware\megaavr\1.2.0\cores\dxcore/api/String.h:30,

                 from C:\Users\FFFFFF\AppData\Local\Arduino15\packages\DxCore\hardware\megaavr\1.2.0\cores\dxcore/api/Print.h:24,

                 from C:\Users\FFFFFF\AppData\Local\Arduino15\packages\DxCore\hardware\megaavr\1.2.0\cores\dxcore/api/Stream.h:25,

                 from C:\Users\FFFFFF\AppData\Local\Arduino15\packages\DxCore\hardware\megaavr\1.2.0\cores\dxcore/api/Client.h:22,

                 from C:\Users\FFFFFF\AppData\Local\Arduino15\packages\DxCore\hardware\megaavr\1.2.0\cores\dxcore/api/ArduinoAPI.h:29,

                 from C:\Users\FFFFFF\AppData\Local\Arduino15\packages\DxCore\hardware\megaavr\1.2.0\cores\dxcore/Arduino.h:23,

                 from C:\Users\FFFFFF\Documents\Arduino\libraries\Adafruit_GFX_Library\Adafruit_GFX.h:5,

                 from C:\Users\FFFFFF\Documents\Arduino\libraries\Adafruit_GFX_Library\Adafruit_SPITFT.h:25,

                 from C:\Users\FFFFFF\Documents\Arduino\libraries\Adafruit_GFX_Library\Adafruit_SPITFT.cpp:36:

C:\Users\FFFFFF\Documents\Arduino\libraries\Adafruit_GFX_Library\Adafruit_SPITFT.cpp: In member function 'void Adafruit_SPITFT::initSPI(uint32_t, uint8_t)':

C:\Users\FFFFFF\Documents\Arduino\libraries\Adafruit_GFX_Library\Adafruit_SPITFT.cpp:568:28: error: comparison between distinct pointer types 'SPIClass*' and 'SPI_t* {aka SPI_struct*}' lacks a cast

         || (hwspi._spi == &SPI1)

                            ^

exit status 1

Error compiling for board AVR DA-series (Optiboot).



This report would have more information with
"Show verbose output during compilation"
option enabled in File -> Preferences.

Does it reproduce in megaTinyCore? I can't imagine it does, as that library is pretty popular (I don't understand why people like screens and graphics so much, but that might be on me ;-)) I will have to look into this - it looks to me like a defect in DxCore.

[ProxyPlayerHD]

why wouldn't you like screens/Graphics?
how else would you do games or anything that requires more than a dozen LEDs to display something, like graphs, or specifically formatted text/number displays that are not possible without using a lot of extra circuitry, IO Pins, space, and power?

anyways, back to topic, Sorry but i didn't test it with MegaTinyCore so i can't say if it fails with it as well.

[SpenceKonde]

Oh waaaaait..... Actually, I think this is a defect in the Adafruit library!

[SpenceKonde]

Don't bother checking it elsewhere - it only manifests on AVR devices with more than 1 SPI port which define SPI_INTERFACES_COUNT as > 1...

[ProxyPlayerHD]

godammit.
So the AVR DA/DB Chips are literally too freature rich to work with that Library.
I Hope it's possible to add support for these devices though.
Do you want to open an issue on the Adafruit GFX Library Github or should i do it and link it to this Issue?

[SpenceKonde]

It will always choke in this way, because it expects the second and subsequent SPI classes to be named SPI1, SPI2, etc - but on a post-2016 AVR, the SPI_structs (with the registers in them) provided by the io.h files will have those names, hence the error error: comparison between distinct pointer types 'SPIClass*' and 'SPI_t* {aka SPI_struct*}'.... It's a bit of a BS mess - Microchip's systematic naming, and the systematic naming Arduino has used for many years for multiple SPI ports on parts that had them (like the SAM parts used in Zero, Due, etc) conflict on an AVR device with more than 1 SPI port.... There is really no graceful solution here, only ugly ones.... BUT considering the shitshow that was my attempt at supporting a second SPI port on DxCore, a strong argument can be made for taking that out behind the woodshed, it's just unspeakably bad, quite frankly, and incompatible with everything you might want to use it with...

[SpenceKonde]

Okay, fresh pull from github should have a decent chance of working; for now I just dropped SPI_INTERFACES_COUNT to 1; seeing as the Dx-series parts won't work with anything that tries to use standard methods to deduce what ports are named what and which are present anyway, and that's what that macro is for, just hiding the second port until at least I can show a vaguely compatible library, seems the wise course of action :-P

[SpenceKonde]

Not quite sure what I was thinking with my implementation of SPI1 for DxCore... I suspect that I wasn't. Like, the naming situation ensures that there's no graceful way, but mine wasn't just awkward, it was so incompatible as to be pointless.... it must be done with a pointer to the SPI struct so it can be a member of SPIclass, otherwise it is pretty much guaranteed not to work with anything that might have a way to support an alternate SPI port.... As I recall my implementation was terribly haphazard and I took way too long to recognize the naming issue which my original implementation ALSO fell afoul of...

[ProxyPlayerHD]

To be completely honest anything relatively advanced in C kinda goes over my head.
Like structs, or malloc. even pointers are still a bit confusing to me.

plus it took me a few days to finally get the bootloader working on my board so i can program it via USB (which works actually pretty great btw).
So i'm probably not the correct person to talk smart with.

though, would it be possible to just put #define SPI_INTERFACES_COUNT 1 at the start of the ino file and it would just accept it? or can there only be 1 define for that?

[SpenceKonde]

#undef SPI_INTERFACES_COUNT
#define SPI_INTERFACES_COUNT 1

but - IIRC that doesn't work; you can't get a #define from the sketch into the library (intensely frustrating, that...)... I'm not certain off-hand, but I seem to remember trying and not being able to figure out a way to make that happen. Easy enough to try though.

[SpenceKonde]

BTW, what board is it?

[ProxyPlayerHD]

yea i tried that just now and it didn't work. sad.

I made the board myself.
It's just an AVR128DA48, with an FT232RL connected to PA0/1 (default UART), 1 LED connected to PA7, and 2 LEDs for RX/TX.

Overall with the PCB, SMT Assembly from JLCPCB, and Parts, this board costs like ~10-15 bucks.

[SpenceKonde]

Not a bad price - what quantity did you have to go for for that? (hopefully not very many, see below)
Also, what led you to choose the FT232 as opposed to the CH340G or the HT42B534? (the latter is a particularly amazing part - and nearly as cheap as CH340's - though in a simple application like this, you don't really get much from it) Asking this out of curiosity, since I seem to be in the minority (at least among westerners) with my fondness for the CH340.

I will note that there is at least one potentially significant design flaw there - the chip is severely under-decoupled. The datasheet takes pains to note that a decoupling capacitor should be installed for each Vcc/Gnd pin; they also recently revised the hardware design section of the datasheet... those 0.1uF caps they recommended? "Oops, so sorry, we meant 1 uF!" (you know, it's only been out for six months, not like anyone might have designed anything with it right?) So your caps are insufficient in both size and number, leading to the chip having 1/30th of the recommended decoupling. While one can often get away with an underdecoupled AVR (not that I condone this practice - in fact, I vigorously condemn it every chance I get), particularly with good board-level decoupling (which you don't have), a mere 0.1uF is really pushing it... unpredictable resets or hangs would not be surprising on that board (particularly as the load on either I/O pins or the supply from other connected devices changes) as a result...

Anyway, I hope you have been having success with the github version of the core since then; I have decided what I will do about this moving forward: From the next released version (changes will go in over the weekend) there will only be the SPI.h library, but the SPI.swap() method will be extended to support choosing not only the pin mapping, but whether to use SPI0 or SPI1; I remembered why I considered it such a high riority to have that SPI1 library despite my manifest lack of the pointer skills to implement it in a usable manner even if there hadn't been the problem that this issue highlights: On the DB-series parts, pins A0 and A1 are used for the external high frequency crystal (if used). That means that if we wish to maintain code compatibility with everything that assumes Serial is the one connected to the serial monitor, we would want to have USART0 pointed at the alt pins by default. But those are also part of the only set of SPI pins available on the 28 and 32 pin parts for SPI0, so putting a serial adapter on those pins will interfere with their use for SPI and vice versa... Unaware of the pitfalls of a second SPI library, and having not thought of extending swap, I reasoned that I should consider a second SPI library to be a top priority, and implemented it (poorly) post-haste.

[ProxyPlayerHD]

It is the first PCB i ever made for any Microcontroller.
so obviously it's not perfect. (for example i had to cut a trace to stop the FT232 from getting reset when you press the rest button)

also i just choose the FT232 because it's what i know as i'm somewhat familiar with FTDI because i've used the FT240X in an 8 bit computer before, and it works perfectly fine.
(plus neither Mouser or Digikey doesn't even have the "CH340G" or "HT42B534" at all, so not like i had much of a choice).

I thought about doing a version 2 of the board where i fix stuff like that, and then just make the KiCad Project Public on Github so anyone can make a very minimalistic and cheap Dev Board.
maybe I can do one board design for each Size (64 pin, 48 pin, 32 pin, and 28 pin) and have the 28 pin MCU only use TH Componenets, so it's easier to solder for a beginner.

anyways, i manually downloaded and installed DxCore to test it out.
and while it does compile i'm running into an issue that i had a few times now.
basically the program would start executing but then just stop shortly after...
for example one of the first programs i tried out was for an RTC Clock, and i had this at the start of the program:

Serial.begin(9600);
Serial.printg("Starting!");

and all that would reach the Arduino Monitor would be "Starti" before it just stops... it's consistent as well, reuploading or resetting the AVR Board doesn't fix it.

Same is happening here, I made a small testing program where it just goes through each pixel, turing it on and off in a checkerboard pattern, and it crashes really quickly after drawing a few pixels.

So Either my PCB is really just that bad that after a few moments of using SPI/I2C the whole thing just crashes, there is an actual hardware bug in my MCU, or it's something software related.
though i don't think it's a hardware bug, the newest version of my RTC Program reads out the current time from the RTC Module ~4 times per second and it runs perfectly fine.

here an image of what it looks like after crashing, note that the program draws from left to right, and top to bottom. but when it crashed it drew a final pixel at a seemingly random position.

Here the full program, sorry for not commenting it:

#include <SPI.h>
#include <Wire.h>
#include <Adafruit_GFX.h>
#include <Adafruit_SSD1306.h>

const uint8_t SCREEN_WIDTH = 128;
const uint8_t SCREEN_HEIGHT = 64;
const uint8_t OLED_RESET = 4;
Adafruit_SSD1306 display(SCREEN_WIDTH, SCREEN_HEIGHT, &Wire, OLED_RESET);

bool FLIP = 1;

void setup(){
	Wire.begin();
	Serial.begin(9600);
	Serial.println("Starting");
	if(!display.begin(SSD1306_SWITCHCAPVCC, 0x3C)) {
		Serial.println("SSD1306 allocation failed");
		for(;;);
	}
	delay(1);
	display.clearDisplay();
	delay(1);
	
}

void loop(){
	for (uint16_t y = 0; y < SCREEN_HEIGHT; y++){
		for (uint16_t x = 0; x < SCREEN_WIDTH; x++){
			display.drawPixel(x, y, (x&1)^(y&1));
			
			delay(1);
			display.display();
			delay(1);
			Serial.print(x, DEC);
			Serial.print(" ");
			Serial.print(y, DEC);
			Serial.print(" ");
			Serial.println();
		}
	}
	Serial.println("Looping!");
}

[SpenceKonde]

Yeah, the selection of the western distributors for even the "china standard" parts is pretty pathetic...
The CH340's are ebay/aliexpress... CH340N, 8-pin soic package... about as easy as smd ICs get to solder, and 2 external comopnents is all you need for basic functionality...
https://www.aliexpress.com/item/4000968092543.html (no specific endorsement of vendor, just one of first results) 10 of them, including shipping, for less than digikey wants for a single FT232RL!

The holtek chips, unfortunately, are a little harder to get (my understanding is that if I spoke chinese and lived in china, they would be trivial to source, and cheaper than dirt - at one point I was seriously considering buying a bunch of cheap LGT based nano clones with the holtec chip and turning the blow-torch on them to get the chips for my super-serial-adapter prototypes, as that was about the same price as the bare IC, but managed to get 10 of the -2's for about the same price (around $1/ea, iirc - bulk they are same price as CH340s, if you speak chinese), since no competition for the chips... for production of course would just have assembly house source them - not sure if i will do the Ultimate ones - maybe just the "basic" onesbuilt on ch340E, with such extravagances as a working voltage switch, a regulator that can power an esp8266 straight up, a micro-usb connector, and nothing done flagrantly wrong - sadly that combination is not obtainable on the market; best I can do is 2 out of 4 from commercial ones!).

I would imagine the all TH 28-pin would probably be in highest demand from the home assembly crowd. Like, I hand solder TQFP-64's, but even I find it unpleasant. It's not the soldering (the only things I find actually hard to solder are QFNs; my hot air capability isn't up to par - if it's got leads, the soldering is easy IMO), it's the alignment that's hard... there are 2 axes to misposition it in, but also rotation, and the axis of rotation has 2 degrees of freedom too. So you can check one edge, and it's right on, then you check the others, and one of the four is too far off. On 32's which aren't the fine pitch, you have to be really far off for it to be a problem, with 48 pins, in the finer pitch... you'll notice it. but with 64, it's the main challenge. I need to make better alignment marks on my next version; got some ideas there. I might even take the plunge and do QFN; alignment seems to be less of a problem with those (I think the surface tension effect is more helpful there). Fixing bridges is easy, evem fun in a way, but if it's not lined up right when you reflow, forget it. The routing was actually a royal pain for the 48 and 64 pin versions... (like >50 hours just between the Rev. - and Rev. A)... and then I lost my design files to an SSD failure!

Re programs:
On the RTC one that doesn't work, I would have done a couple of debugging steps:

1. Add a Serial.flush() after the print. Prediction: It will print successfully.
2. Try a delay before and delay after the print (and lose the Serial.print). Prediction: delay before will do nothing, delay after will add 1 character per ms of delay(),
3. Increase baud rate (without any of that stuff) - Prediction: faster baud would print successfully before hanging

All predictions confirmed would lead me to suspect communication with the peripheral.

4. Assuming that, add a delay to the thing that is repeatedly calling it, so there is a delay every pass through the loop. If this fixes it, you trying to write paste the end of a buffer....

shrug that might not explain the issue it in and of itself, but it would get you way closer..

On the problem with the screen....

Are those actuaklly every pixel on and off? (that would be my first guess about what it's expected to do)

that's a weird one... Again... I would try sanity checks like I outlined; my gut instinct is that a faster baud rate and/or a delay after every pixel would 'fix' the problem (not that you should need such measures. Knowing which it is would be helpful when I get to look into this... (also, does that library require including both SPI and Wire? Why include both if not? And if so, am disappointed in adafruit... not that that's the problem...))

[ProxyPlayerHD]

Serial:

Adding "Serial.flush();" did actually work. and adding a bit of delay after the print also worked (more dleay = more characters).
increasing the baudrate itself did not change anything, though the amount of extra characters printed by using the delay did increase with a higher baudrate.

So overall the AVR just can't send all the data fast enough before continuing to execute code? but why would that just completely halt the entire CPU? plus i thought Serial.print would always wait until everything has been sent before continuing with the rest of the program.
also that doesn't explain why it works on other AVR Devices. Is there something special about the UARTs on the AVR Dx Series?

Screen:

in the code there already are delays between each pixel drawn, 1ms from pixel being sent to the display and the display being updated, and then another 1ms delay before it prints all the stuff and then repeats the loop.
increasing or removing the delay has no noticable effect on the amount of pixels it can draw before it crashes, it still appears it be pretty random, though it never seems to go over ~70.

also note that the same exact code runs perfectly fine on my Arduino Mega, with and without delays.
here a pic of how the resulting pattern should look if the program were to run for longer than around half a line of pixels:

PCB Stuff:

i just use FreeRouting for my PCBs, but Auto Routers are not perfect so after it's done i go in myself and adjust some traces manually. it worked well so far, even for relatively high speed things like my 16MHz 65C02 Computer.

This is the Second Rev. of the x48 Board. I added the Autoreset circuit from other Arduino Boards, replaced the TH LEDs with SMD ones, and added more detail to the Pin Names. plus the board is slightly smaller than the first Version.

(I could also add a Copper Pour on both sides (for GND), though i don't know if that would help at all with SPI/I2C/etc)

[SpenceKonde]

Oh no, it's totally a bug in the core :-P

Serial.print() on a hardware serial port will stuff the data into a buffer, and then feed that buffer a character at a time using the DRE interrupt. This is one of the many advantages of hardware serial ports - otherwise serial is SLOW - 9600 baud is just over 1ms per character. DxCore can currently do up to 1/16th of it's F_CPU in baud (ie, 16 MHz = 1 MBaud), the serial fix I mention below doubles that - also permitting 115200 baud at 1 MHz)

(hmm, does DxCore have the serial fix yet? It may not... on megaTinyCore I recently massively refactored serial because I was convinced (just on not liking the looks of what they were doing, and thinking it was a dangerous approach) that it could deadlock and would definitely break certain advanced code in a way that would leave the would be user of that advanced feature flabbergasted... AND ALL THAT to... get behavior that was subtly different from the behavior of the classic core but which didn't even hold any advantage over it... (I try to not make things work differently in my cores unless the classic behavior is obviously wrong) The original complaint was about it's flash usage (which I did drop by a couple hundred bytes - a big deal for users on 2k flash parts), but in the process I think I fixed another mysterious serial bug that someone had just reported...

And I just checked, DxCore doesn't have the serial fix, so that may very well be what's happening there.... And yeah, I think your code would run until the serial buffer filled with those per-pixel reports, and then it would be in the potential bug zone... which could transform dubious coding practices (trying to print stuff so fast it ran up against the serial speed limit) from something causing only poor performance (which printing data for each pixel will do unavoidably - it'll run fast until it fills the buffer, then Serial.print will become blocking and slow the sketch down to the speed limit of the serial output) into a hang/crash. I would predict that if you followed that Serial.println() with Serial.flush() it would work (and that the speed that it runs at with that fix would be a function of the serial baud rate, too; that effect could be observed on an Arduino Mega too, and is unavoidable with serial, though cranking the baud rate will help)... but yeah, if you see that behavior, it would in my mind prove that the issue is that DxCore needs the Serial fix I put into megaTinyCore, as a priority, since it would now be a bug in a critical piece of the API, not an enhancement. I suspect the bug itself is a timing bug involving DRE and the TWI code...

Now that I see the top view, you don't have to tell me you're using an autorouter :-P Always do the copper pour- nothing ever behaved worse because it had a nice solid ground, routing is easier, and functionality aside, you look like a noob without the copper pours - and people totally judge based on that, because "jeez, this dude doesn't even know how to do copper pours? I wonder what else he screwed up?" - as it happens, that reasoning led me to not buy a bunch of one of the type of disappointing serial adapters, before i'd recognized a bunch of it's flaws... but I could tell by the shoddy routing and the halfassery surrounding the copper pour, that he wasn't very experienced.... sure enough he omitted the polyfuse, had the line that's supposed to be CTS tied to ground (dude, it's an OUTPUT from the target device! The target could (probably shouldn't, and arduinos generally don't use it anyway) be trying to drive it high! And the actual CTS pin was just millimeters away from where they did that... The target can tie it to ground, the adapter must not!), they were using a switch at potentially 1.5-4 times it's rated current, not adhering to best practices around the LED, no protection on the TX line so if it was set to wrong voltage level it could burn out the pin on the target... About the only thing those guys did right was make the serial adapter use 3.3v logic levels when set to 3,3v.... (you laugh, but the other adapter with a voltage switch? it switches Vcc pin (correctly, with a pair of fets)... but not the chip's Vdd, so it outputs 5v logic levels and so a 3.3v target's RX line will be riding the protection diodes via the 1k resistor on the adapter, ie, barely in spec for classic AVRs, and with no load other than the chip, that current injection will nudge the the voltage high enough that 3.7V BOD won't trigger when it's set to 3.3V... THAT took a while to figure out (it was not supposed to be set to 3.7, of course))

[ProxyPlayerHD]

Removing all Serial.print() lines and even Serial.begin() from the code doesn't fix the issue with the screen though.
like before, it draws some pixels and then crashes, it just does it faster because it doesn't have to send anything over Serial.
Maybe there is a similar issue with the TWI and SPI Functions, like with Serial?

PCB:

i saw people online saying that if done badly a copper pour can actually hurt signal integrity, and so far none of my PCBs ever needed one, so i never risked adding one. (thought for the speeds of an AVR it shouldn't be an issue)
but here a pic of how it looks with one (added some Vias to stitch both GND copper pours together)

And here the 28 pin version, almost entirely from TH Components (except the FT232RL of course):

fun fact, the x28 Board doesn't require a single Via, which is a first for my PCBs.
but obviously it has Vias because Stitching.

[SpenceKonde]

Not bad.

I would again repeat my suggestion to use a CH340N - it is less than 1/10th the price, and much easier to solder.... you don't even need the 2x 27 ohm resistors and the 47 pf caps...

[SpenceKonde]

huh, well that's unfortunate regarding the TWI (how is SPI involved? That screen definitely looks like it's I2C/TWI

[ProxyPlayerHD]

I was just assuming SPI also has issues... it might not be. like you said the screen and the RTC Clock are both I²C, so i have nothing to test SPI with.

and i would like to use the CH340N, but as said big vendors like Digikey and Mouser don't have it as a standalone chip, and people who just want a functional board (including myself) would likely not be comfortable ordering chips from some questionable asian sites...

[SpenceKonde]

SPI library can now use any of the sets of pins (on SPI0 or SPI1 peripherals). Actually having two independent copies of the SPI library working at once is not going to happen because the name used for the instance of the SPI class on every other device in the universe is used for thje underlying peripheral over here... lol -and I had rushed that one out due to there being so much competition for the only pins that SPI0 could use on the lower pincount devices - and was greeted with this catastrophe. Anyway. in github version, you can now tell the SPI library to use any of the hardware SPI pin sets, and it will use the appropriate SPI peripheral for those pins. See readme for more info.