SPI TFT-LCD drawBitmap

Arduino SDK
1

Application: Muse-Charm
EVB : AMB82-mini
SPI : ILI9341 TFTLCD
example : EdgeAI-AmebaPro2/Arduino/AMB82-mini/ILI9341_Bitmap at main · rkuo2000/EdgeAI-AmebaPro2 · GitHub

failed code : ILI9341_Bitmap_org.ino

void drawBitmap(int16_t x, int16_t y, int16_t w, int16_t h, const unsigned short *color)
{
tft.drawBitmap(x, y, w, h, color);
delay(500);
}

bug found by codex :
The loop itself is fine. The likely cause is your installed AmebaILI9341::drawBitmap() (/home/rkuo/.arduino15/packages/realtek/hardware/AmebaPro2/4.1.1-build20260922/libraries/SPI/src/AmebaILI9341.cpp:248):

  • It casts away const and swaps the source image’s bytes in place.
  • It passes that array to SPI as both the transmit and receive buffer, allowing received data to overwrite the image.

That is unsafe for your const ... PROGMEM images and can break repeated drawing. All seven image arrays have the correct size and contain nonblack pixels.

I updated ILI9341_Bitmap.ino (ILI9341_Bitmap.ino:25) to transmit RGB565 bytes directly, preserving the image arrays and bypassing the faulty bulk transfer.

The modified sketch compiles successfully with your AMB82 toolchain. Upload it to verify the display; drawing may be slower with this workaround.

fixed code : ILI9341_Bitmap.ino

  1. This is drawing much slower, is it possible to fix ILI9341 SPI driver ?

  2. SPI1 did not work :
    #define TFT_CS SPI1_SS
    AmebaILI9341 tft = AmebaILI9341(TFT_CS, TFT_DC, TFT_RESET, &SPI1);

2

Hi @rkuo2000 ,

  1. Please find the attached patch of AmebaILI9341.cpp and AmebaILI9341.h for replacement. We have updated the drawBitmap() such that data is transmitted through the TX-only stream API via a private staging buffer and wait on TX_BUSY between chunks.
  2. To use SPI1, kindly rename object SPI to SPI1 in your example code.

Thank you.

AmebaILI9341_patch.zip (5.4 KB)