The inevitable Arduino page

General observations:

The Arduino "ino" file does not store the board type or its dependencies. Before compiling a file the user is responsible for:

Installing the board support package if required
Installing any required libraries
Selecting the board if it wasn't automatically detected

Due to the above it is strongly advisable to include detailed comments listing a file's target board and its requirements. That is not to say that a project won't "port" to a different board but it can be incredibly frustrating to have the source code to a microcontroller project but not know the exact target hardware it calls for.

One motivation for migrating to VScode/PliatformIO is that with VScode you have a project file which remembers a project's target board and its dependencies, though this still won't tell you what other devices may have been attached.

Again: describe your hardware in detail.

Boards currently of interest:

DFRobot Romeo V1.3 (V3)
DFRobot DFR0287 LCD12864

Other boards of lesser significance

Digispark Rev. 3 ATTiny85 board

Romeo V1.3

The Romeo V1.3 board appears to be interchangeable with an Arduino Uno, but with an additional motor driver and some handy connecting points

LCD12864

The LCD12864 is a "Shield" with a graphic type LCD display and a switch type joystick. The actual display is accessed via SPI, using only 5 I/O pins. The switches and the joystick each take up one analogue input.

Stacked together these form a convenient block for performing evaluations, as the resulting module has a display, five pushbuttons and the joystick, plus a significant amount of unencumbered IO.

DigiSpark ATTiny85 board

The DigiSpark achieved some note as the "World's smallest Arduino" and while it isn't strictly true the board can (could) be programmed with the Arduino IDE and could perform useful work as a low pin count controller.

What the DigiSpark could NOT do is establish a serial connection with the Arduino IDE. This is because the board only supports LOW speed USB and USB specifications only allow low speed devices to be HID types such as a keyboard or a mouse.

Support for the DigiSpark appears to be fading and a work-around is needed because the original board support URL no longer works. The alternative URL is:
https://raw.githubusercontent.com/digistump/arduino-boards-index/master/package_digistump_index.json
this appears to still be valid.

The boards I had were copies, and could be distinguished from originals as pin P5 was a reset pin. Originals had the reset pin disabled allowing P5 to be used for IO.

Another strange issue I've experienced is that after a while the boards I had appeared to lose the stored program when power was removed. It has been suggested that this is due to a problem with the boot-loader installed on the ATTiny85 chip. The solution is to reprogram the chip with the "Micronucleus" boot-loader, which is a far better replacement. The programming procedure is quite involved though.

Driving the LCD12864

At this time I know of three libraries supporting this display.

u8glib by Oliver Krause
u8g2
u8x8

U8GLIB Library

Note from the Github page: U8glib Note: There will be no more development for U8glib. Please use u8g2. A graphics library with support for many different monochrome displays.

For this reason I've done little beyond running the supplied example.

U8G2 Library

Some changes were required to get the supplied "Hello World" demo from the U8G2 page to run on the DFR0287 LCD12864.

The constructor that seemed to work was:

    U8G2_ST7565_NHD_C12864_1_4W_SW_SPI u8g2(U8G2_R2,
    /* clock=*/ 13,
    /* data=*/ 11,
    /* cs=*/ 10,
    /* dc=*/ 9,
    /* reset=*/ 8);
  

An additional contrast setting was needed in "Begin":

    void setup(void)
    {

      u8g2.begin();

      u8g2.setContrast(32);
    // Config the contrast to the best effect

    }
  

I tried a few contrast values, 32 worked for me.

After that the main curiosity was that the drawing process was inside a "while" block:

      u8g2.firstPage();

      do
    {

        u8g2.setFont(u8g2_font_ncenB14_tr);

        u8g2.drawStr(0,15,"Hello
    World!");

      }
    while
    ( u8g2.nextPage()
    );
  

What seems to be going on here is that the library uses a relatively unusual strategy to efficiently update the display:

The display is physically implemented as several pages of memory each covering part of the display area. The library creates a RAM buffer that is enough to hold one page but not the entire display area.

Each time the block loops it draws one part of the display area which is then dumped to the display.

This allows the whole display to be redrawn relatively quickly without needing to hold a copy of the whole display in RAM.

It has the peculiarity that each display update completely replaces the previous one, which is often the desired result in an embedded project.

U8x8 Library

This appears to be a basic text mode library, using character coordinates and having one fixed display orientation.

The orientation comes out upside down relative to the PCB.

The constructor is now:

    U8X8_ST7565_NHD_C12864_4W_SW_SPI u8x8(
    /* clock=*/ 13,
    /* data=*/ 11,
    /* cs=*/ 10,
    /* dc=*/ 9,
    /* reset=*/ 8);
  

The output method was called "drawString" instead of "drawStr" and used character coordinates. It also uses a conventional update strategy where old display content persists until overwritten or cleared. This probably takes advantage of the display's internal memory layout in that each character exactly fits in eight consecutive bytes with no overlap.

U8log Library

This appears to be an extension to create a scrolling "console" type window on the display.

There are two ways to use it:

one way is automatic update which appears to "anchor" the terminal to the top left corner of the display. The display object is bound to the terminal via a callback. The terminal can be configured to update after every character or every line. Update after every line is recommended.
The other way is "manual" update where the terminal is only drawn when called, and the top left coordinate can be specified. This allows for a small terminal window in a larger display layout

The terminal appears to redraw its entire area every time, there does not appear to be any clever hardware scrolling at work here. That said it does appear to be efficient, with the boards shown the update was fairly fast.