I have recently obtained an Arduino RP2040 connect and a SSD1306 128*64 SPI OLED display. When I try to upload the standard 128*64 i2c example from the SSD1306 library (this one), I get the following feedback:
C:\Users\20182653\Documents\Arduino\libraries\Adafruit_SSD1306\Adafruit_SSD1306.cpp:45:6: error: expected unqualified-id before 'const'
45 | (*(const unsigned char *)(addr)) ///< PROGMEM workaround for non-AVR
| ^~~~~
c:\users\20182653\appdata\local\arduino15\packages\rp2040\hardware\rp2040\3.3.0\arduinocore-api\api\deprecated-avr-comp/avr/pgmspace.h:116:29: note: in expansion of macro 'pgm_read_byte'
116 | static inline unsigned char pgm_read_byte(const void *addr) {
| ^~~~~~~~~~~~~
C:\Users\20182653\Documents\Arduino\libraries\Adafruit_SSD1306\Adafruit_SSD1306.cpp:45:6: error: expected ')' before 'const'
45 | (*(const unsigned char *)(addr)) ///< PROGMEM workaround for non-AVR
| ~^~~~~
c:\users\20182653\appdata\local\arduino15\packages\rp2040\hardware\rp2040\3.3.0\arduinocore-api\api\deprecated-avr-comp/avr/pgmspace.h:116:29: note: in expansion of macro 'pgm_read_byte'
116 | static inline unsigned char pgm_read_byte(const void *addr) {
| ^~~~~~~~~~~~~
C:\Users\20182653\Documents\Arduino\libraries\Adafruit_SSD1306\Adafruit_SSD1306.cpp:45:6: error: expected ')' before 'const'
45 | (*(const unsigned char *)(addr)) ///< PROGMEM workaround for non-AVR
| ~ ^~~~~
c:\users\20182653\appdata\local\arduino15\packages\rp2040\hardware\rp2040\3.3.0\arduinocore-api\api\deprecated-avr-comp/avr/pgmspace.h:116:29: note: in expansion of macro 'pgm_read_byte'
116 | static inline unsigned char pgm_read_byte(const void *addr) {
| ^~~~~~~~~~~~~
exit status 1
Error compiling for board Arduino Nano RP2040 Connect.
I tried compiling the same example for an Arduino Nano, which did not have these issues. Is it possible that the SSD1306 and RP2040 connect are not compatible? Or is there something I am missing?
It looks like error in your board and library setup. Do you sure that you selected Arduino_RP2040 at the Arduino IDE?
I asking because the error cited above should not have occurred when compiling for the Rp2040 platform, since line 45 of the Adafruit_SSD1306.cpp file noted in the error is in a part of the code that is not compiled for RP2040 at all (it is in the conditional compilation directive that is turned off when choosing RP2040 boards).
Did you installed a latest version of the Adafruit_SSD1306 library?
It's always wise to review the files being used. The SSD1306 OLED is probably one of the widely most compatible displays in any language and any hardware. Many of these libraries check to see what hardware you are running to implement certain functions or parameters. If you don't see an rp2040 or pico type wording listed, chances are its not compatible with the 2040. I agree with the post above explaining this, if you look at the new file you'll will see the change that allows it to work on 2040 compare that to the old version..
Yes most of the time you can just trust the IDE but you need to be willing to sharpen your programming skills to be able to troubleshoot a trivial error such as this. Take the time to really learn proper C or C++. Do not rely on the IDE to do all the work because it'll fail you sometimes. This is the reason I took the time to revisit C (havent touched since college) and started my programming of Pico's using pure C and the official SDK only. This put its me in a small category because its the long and hard way of doing tasks. Its the most efficient in terms of speed. I had a very hard time even finding examples for many of the well known easy projects for hardware. Because of this I had no choice but to do trial and error and work off what I know and the books I had. I'm sure 98% of 2040 users use MicroPython or Arduino's version of coding (C/C++ but hides a lot of the hard work behind modules and functions).
I just recently started to move away from pure C (in Visual Studio code) to MicroPython after looking for examples in pure C on github and finding none but finding a mountain for MP or Arduino sketches. I used these to reverse code in C.
I decide to take the lazy way out, and I learned MicroPython. It's so unreal how just a few lines in MP can replace dozens of C code. That does not mean I gave up on C I still use that sometimes when RAM is of concern especially. I didn't bother with Arduino's version of code because it wasn't pure c or c++ and relied heavily on modules.
MP is similar but in that it relies on modules, however its a standardized language and it is tailed to specific hardware chips such as the NANO2040 at the end of the day its still micropython which is VERY close to pure python. I have been reading and learning both pure python and MP. I've picked it up very quickly as it is such a friendly language. After C, learning MP was a cake walk.
Anyhow side rant sorry. Sharpen up your skills in Arduino and real C/C++ so you can debug these things in a heartbeat.
