"Howto" get this to work on a standard pico RP2040 with SPI

[ThrudTheBarbarian]

I've been trying to get this to work on the RP2040 and not having much luck figuring out how to get started. Generally I use CMakeLists.txt and VSCode for RP2040 stuff, but it looks as though the bundled CMakeLists.txt is specific to Arduino, unless I'm missing something.

I've gathered that I need to create a User_Setups/xxx.h file, and I copied Setup60_RP2040_ILI9341.h to a test_setup.h file, changed the driver to ILI9481_DRIVER, modified the pins (I'm still using SPI0, so just changed the GPIOs to match the layout I have), and made the change in User_Setup_Select.h to comment out the top-level one and #include the new one I made.

Now what ? :)

There's no Makefile (fair enough, that's reasonable given the number of support options) but how do I go about creating a Makefile, or building the code ?

Is there a way to build it, standalone ? Or is it time to start dragging files into a new CMakeLists.txt until it stops complaining about not being able to find something ? :)

[Bodmer]

The Cmakelists is for the Espresif ESP IDF.

The library is Arduino IDE compatible and requires the appropriate board support package for the RP2040 such a Earle Philhower's. The simplest way forward is to use the Arduino IDE or PlatformIO IDE.

[ThrudTheBarbarian]

Thanks for the very fast reply :)

I think I misunderstood the "RP2040 support" part to be native support rather than via an Arduino-compatible BSP. Once I tried the "throw everything in and see where it squeals" approach, it quickly became apparent that the Arduino API was required :)

Regardless, I managed to throw something together in native C++ that was based on what I could see you were doing from looking at the code and I have it drawing filled rectangles now. The hardest part turned out to be figuring out that CPOL=1 and CPHA=1 - I was scratching my head for a while before realizing I was in fact sending the correct data, and it was just being sent improperly. The data sheet was correct, of course - I'd just missed it.

There's quite a bit of interference on the screen, but it's hardly the ideal grounded setup :) So perhaps that'll go away if I properly mount the board and there aren't fly-wires everywhere...

Now that it works, the (very basic!) code is here

[Bodmer]

Great.

It is best to have the 0V (GND) connection direct between the processor and display to avoid common mode noise.

The rectangle appears to have missing pixels, so ground noise or too high a SCLK frequency may be the cause. SPI is quite tolerant to long wires if the 0V connection is short.

[ThrudTheBarbarian]

Yep, the SPI seems to top out at ~20MHz, which is a bit disappointing. OTOH, I'm fairly sure the RP2040 can do a lot better than that, so unless the display is limited, it could actually be a signal integrity thing (I'm never really confident in just how good these breadboard-style circuits handle signal integrity. It's entirely possible that when it's in-place properly it will run faster :)

Not really related but I think the comment documenting the VlwFont structure in Smooth_font.cpp might be a little incorrect. I think it ought to be:

After the bitmaps is:
2 bytes for font name string length
a non-terminated character string giving the font name
2 bytes for Postscript name string length
a non-terminated character string giving the font name
last byte is 0 for non-anti-aliased and 1 for anti-aliased (smoothed)

(emphasis mine). The zeros, I think, are just the byte-swapped upper length value (which is pretty much going to be 0 unless your string name is very long). The first byte immediately after the bitmap data is '0' for me, followed by the string length. That repeats for the 'postscript name' and then there's the smoothed flag...

• Font loaded
  • Glyphs : 312
  • Version : 11
  • Font size : 12
  • Ascent : 9
  • Descent : 3
  • Font name : 'NotoSansKannada-Thin'
  • Postscript name : 'NotoSansKannada-Thin'
  • Font is anti-aliased

[Bodmer]

The ILI9481 is the slowest SPI TFT display chip I have come across. 20MHz is above the data sheet max.

[mlepage]

I agree it would be really useful if we could use this library directly with the Raspberry Pi Pico SDK.

What are the dependencies? I'm guessing it would need a class to wrap the SPI functions, and a mapping of basic functions (writeCommand, writeData, delay), anything else? Maybe it's not too much work to make it happen?