RP2040

[keomell]

Has anyone used this with the raspberry pi pico or any related RP2040 dev board, if so could you share your experience with me?

[RudolphRiedel]

Well, so far it probably is not so likely that anyone else than me is answering here since this is not really a forum. :-)
I used a Pico board to implement the RP2040 support but I have not done anything else with it besides getting it to work.

At first it was no fun at all since the support under Windows was rather bad.
Without https://github.com/Wiz-IO/wizio-pico I probably could not have done it as early as I did.

And I just checked, it still compiles fine.
But some time has passed now, no idea where the RP2040 support currently is.

[keomell]

Lol well that is true. I am trying to use this with the new haven 4.3 800x480 EVE2 display, but I did have a hard time getting it to just compile on windows correctly. But I will try your link and please let me know if you have anymore tips for the pico board.

Thank you for responding.

[keomell]

On another side note too, running the Arduino example that you've provided if I wanted to use this with the new haven 4.3 800x480 display I would change the defile on line 151 in the EVE_config.h file to EVE_NHD_43_800400. Is there anything else that I am missing?

Thank you.

[RudolphRrr]

I would change the defile on line 151 in the EVE_config.h file to EVE_NHD_43_800400

That is correct although the examples are slightly outdated.

Is there anything else that I am missing?

There is no direct Arduino support for the RP2040 yet since there was no official Arduino core when I played with it.
So compiling for Arduino would use the default Arduino code in line 1698ff of EVE_target.h and with no DMA support.

[AndrejValand]

Hi Rudolph,

As the RP2040 is so popular more maybe even now as its readily available even in large quantities and other micros are quite hard to get i also tried to get the example working i used the "EVE_Test_Arduino_PlatformIO" example as the basis and tried to change the platformio.ini file with no luck. I have quite some experience with Microchip MPLAB and Studio but PlatformIO is new for me. What config did you have in the platformio to get it to work?

As for arduino they have a RP2040 board now and also the original board is supported. Basic examples work fine, even the direct download over USB is now working, no need to press the reset button and plug/unplug the cable anymore, what was the case when the RP2040 came out.

Any pointers how to get your library to compile for RP2040?

[RudolphRiedel]

I have not checked what the SPI pins are for the RP2040 Arduino core or if "5" and "6" actually mean GP5 and GP6.

[AndrejValand]

Hi, just checked the GP5 and GP6 do switch state to 1 after power up but there is no traffic on any of the SPI busses.

[RudolphRrr]

Looks like the SPI class is doing things a little differently.
I'll have a look later this afternoon - if you don't solve that puzzle first. :-)

[AndrejValand]

Did not find the SPI class issue yet but working with your library in baremetall mode i changed the Calibration display a bit so it works also for portrait mode

<tft.c>

    EVE_cmd_text(5, 5, 26, 0, "TOUCH TRANSFORMATIONS");
    EVE_cmd_text(5, 30, 16, 0, "A:");
    EVE_cmd_text(5, 45, 16, 0, "B:");
    EVE_cmd_text(5, 60, 16, 0, "C:");
    EVE_cmd_text(5, 75, 16, 0, "D:");
    EVE_cmd_text(5, 90, 16, 0, "E:");
    EVE_cmd_text(5, 105, 16, 0, "F:");    

    /* Display left justified results */
    EVE_cmd_setbase(16L);
    EVE_cmd_number(24, 30, 16, 8, touch_a); 
    EVE_cmd_number(24, 45, 16, 8, touch_b);
    EVE_cmd_number(24, 60, 16, 8, touch_c);
    EVE_cmd_number(24, 75, 16, 8, touch_d);
    EVE_cmd_number(24, 90, 16, 8, touch_e);
    EVE_cmd_number(24, 105, 16, 8, touch_f);

Also added possiblity to set portrait mode to configuration but don't know if its the most elegant way to do it, hope it does not brake something. There is maybe a way to just set portrait mode and not have two defines.

<EVE_commands.c>

    /* Initialize Display */
    EVE_memWrite16(REG_HSIZE,   EVE_HRES);   /* active display width */
    EVE_memWrite16(REG_HCYCLE,  EVE_HCYCLE);  /* total number of clocks per line, incl front/back porch */
    EVE_memWrite16(REG_HOFFSET, EVE_HOFFSET); /* start of active line */
    EVE_memWrite16(REG_HSYNC0,  EVE_HSYNC0);  /* start of horizontal sync pulse */
    EVE_memWrite16(REG_HSYNC1,  EVE_HSYNC1);  /* end of horizontal sync pulse */
    EVE_memWrite16(REG_VSIZE,   EVE_VRES);   /* active display height */
    EVE_memWrite16(REG_VCYCLE,  EVE_VCYCLE);  /* total number of lines per screen, including pre/post */
    EVE_memWrite16(REG_VOFFSET, EVE_VOFFSET); /* start of active screen */
    EVE_memWrite16(REG_VSYNC0,  EVE_VSYNC0);  /* start of vertical sync pulse */
    EVE_memWrite16(REG_VSYNC1,  EVE_VSYNC1);  /* end of vertical sync pulse */
    EVE_memWrite8(REG_SWIZZLE,  EVE_SWIZZLE); /* FT8xx output to LCD - pin order */
    EVE_memWrite8(REG_PCLK_POL, EVE_PCLKPOL); /* LCD data is clocked in on this PCLK edge */
    EVE_memWrite8(REG_CSPREAD,  EVE_CSPREAD); /* helps with noise, when set to 1 fewer signals are changed simultan
![msedge_1mApPGP489](https://user-images.githubusercontent.com/78184229/181743299-5435690a-89a1-409f-94fe-28cf2f08813d.png)
eously, reset-default: 1 */
    EVE_cmd_setrotate(EVE_ROTATION);          /* Set screen rotation (0=landscape, 2=Portrait)
    /* do not set PCLK yet - wait for just after the first display list */

Tested the Riverdi setup you have for RVT43HLB and it works fine, also custom font update.... Added EVE_HRES, EVE_VRES and EVE_ROTATION.

<EVE_config.h>

/* RVT43HLBxxxxx 480x272 4.3" Riverdi, various options, BT817 */
#if defined (EVE_RVT43H)
#define EVE_HRES    (480L)
#define EVE_VRES    (272L)

#define EVE_ROTATION (2L)
#define EVE_HSIZE   (272L)
#define EVE_VSIZE   (480L)

#define EVE_VSYNC0  (0L)
#define EVE_VSYNC1  (4L)
#define EVE_VOFFSET (12L)
#define EVE_VCYCLE  (292L)
#define EVE_HSYNC0  (0L)
#define EVE_HSYNC1  (4L)
#define EVE_HOFFSET (43L)
#define EVE_HCYCLE  (531L)
#define EVE_PCLK    (7L)
#define EVE_PCLKPOL (1L)
#define EVE_SWIZZLE (0L)
#define EVE_CSPREAD (0L)
#define EVE_HAS_CRYSTAL
#define EVE_GEN 4
#endif

[RudolphRrr]

Without checking, the calibration is supposed to be done in normal mode, the parameters are adapted when you rotate.
So you always calibrate first and rotate afterwards.
I only can't say why it is supposed to be this way right now.

Edit:
I can not find a reason in the Programming Guide to not rotate first and calibrate then, this is probably something I read in a discussion in the BRT-Forum.
However, I believe this should be done with REG_ROTATE and not CMD_SETROTATE since the screen is not calibrated yet anyways.
And this probably is better as optional parameter and not part of the profile - the idea is that you do not need to edit EVE_config.h.
Sounds like an addition to the upcoming new release.

[RudolphRiedel]

For a start, with help from Georgi Angelov I was able to fix why the BareMetall version did not work with the library from the repository.
Turns out that I needed to edit the "frameworks" and "platforms" lines in my library.json file.
I opted to remove these lines entirely which just means that any combination of framework and platform is allowed.

EVE_Test_RP2040_PlatformIO_EVE3-50G.zip

The next question is why the Arduino build is not working.
And I already checked with the logic-analyzer, PD and CS are fine, the SPI is not doing anything.

[RudolphRiedel]

Step two, the wizio-pico Arduino build works now.
EVE_Test_Arduino_PlatformIO.zip

Turns out that the pins are not configured by default to SPI0, so the SPI class needs one line extra for wizio-pico:
SPI.setPins(2, 4, 3);

This is still in the generic Arduino section though, so no DMA support, yet.

[AndrejValand]

This is both excellent news, will try the updated code on the pico as soon as i finish the base of my UI . I was today all day with the library and the display to make some interactive UI work. Learning the firsts steps, and you really made an excellent library. The only think I'm scratching my head about at this moment is how to upload custom fonts. You have a custom font included that work excellent, but have not managed to do it myself. I can make the glyph and xfont with the EAB but don't know where to find the unified.blob, to pack everything together as you did.

[RudolphRiedel]

The flash image is composed by EAB as well, in the "FLASH UTILITIES" tab.
And the "normal" thing to do would be to use an USB/SPI adapter to flash the image to the display.
That I include the image in the demo is out of conveniance.
To include it I am using the "ASSET COMPRESSOR" and the "BIN2C" tools. And since this means that I need to use CMD_INFLATE, this method is limited to <1MB for the uncompressed file.

I played a little more with platform raspberrypi and that still refuses to compile its own modules.

And adding DMA to the wizio-pico Arduino build is not that easy as well since the SPI class does not seem to support DMA.
Well, DMA and Arduino, every implementation I have seen so far is unique, probably because none of the Arduinos up to the Zero even supported DMA.

[AndrejValand]

I find it nice that you included it in the demo. Its so much simpler for us first time EVE users. No need to play with an additional USB/SPI adapter, cables and working of EAB. If you connect a new display you can commission it on the fly. Nice. An in the case of pico RP2040 or ESP32 variants they have enough memory to hold all this data in compressed form with lot to spare. I figured how to upload the custom font now, and found the unified.blop within the EAB folders. What i intend to do next is to have this unified blob separate byte array for upload when needed. And have custom fonts separate it will be more logical.

As for the DMA if you can make it work you are a wizard :) I onece played with it on SAMD21 based Arduinos and newer got it to work as i wanted to with DMA, it always did brake something else...

Its a shame that such a good micro as the RP2040 is so limited by the SDK, i have read the storry of Georgi Angelov also, its unbelivable. Good think he made the wizio-pico.

[AndrejValand]

Tried now all the fixes you made and i can confirm both the baremetall and the Arduino compile and work perfectly (WIZIOPICO version for android only) also on my side. But as expected the Arduino version is about 10x slower then the baremetall one.

On my two days with the new EVE display and using your library as a newcomer my thoughts below:
Negative:
-Nothing

Positive:
-Exceptional fast library
-Exceptional low footprint
-Works immediately (tried a lot of examples from the web nothing worked as was, even for simple AVR MCUs)
-Good bounded example
-Beautiful written library, easy to understand with comments that make sense

Things to improve in the library, when you have time and energy and the will :)
-Add an option to enable portrait mode or any screen rotation (my solution but not perfect is above)
-Separate the unified.blob out of the custom font compressed package
-The only thing that took me a while to understand was the comment for the custom font (below some additional notes)
-Direct serial download of build firmware to RP2040 as with RP2040 original examples in PlatformIO. Its more convenient than pressing the buttons all the time for download.

My changed comment for the custom font:

/*
Source File: Funtype.zlib (Contains the blob, glymph and xfont in one compressed data array)

                              Start   Size
-----------------------------------------------------------------------------------------------------------------
unified.blob                : 0     : 4096     Needed for display to read from its build in flash memory
Funtype_24_ASTC.glyph       : 4096  : 80832    Converted glyphs from selected font
Funtype_24_ASTC.xfont       : 84928 : 320      glyphs widths for converted glyphs
-----------------------------------------------------------------------------------------------------------------
z-lib compressed size is 12753, unpacked 85248

The font is this one: https://fontlibrary.org/de/font/funtype
Converted with EVE Asset Buider (EAB) using an ASCII map file to reduce the number of glyphs from 364 to 187.
Glyph and xfont files are automaticlly generated, for compression to get the zlib file use buld in Asset compressor
This is only included for the purpose to demonstrate how to handle UTF-8 fonts with BT81x. 
Byte arrays in C format can be easilly copied directlly from converted files with the help of HxD Editor
*/

[RudolphRiedel]

I have a first preview for you to test:
EVE_Test_RP2040_Arduino_EVE3-50G_PlatformIO.zip

This implements two new optional parameters for EVE_init(): EVE_ROTATE and EVE_BACKLIGHT_PWM
To compliment EVE_ROTATE I moved my calibration function from the demo code to EVE_commands.c and made it aware
of the screen rotation.

I changed the demo code to be aware of screen rotation and activated the calibration.
The final demo will have that deactivated and run in landscape mode again.

Things to improve in the library, when you have time and energy and the will :)
-Add an option to enable portrait mode or any screen rotation (my solution but not perfect is above)

Well, probably done now. :-)

-Separate the unified.blob out of the custom font compressed package

That is not actually part of the library but in the demo and the flash image always needs the unfied.blob to work.

-The only thing that took me a while to understand was the comment for the custom font (below some additional notes)

I expanded the note in tft_data.c but a little differently.
EAB can do it all, I asked for a BIN2C converter and Bridgetek implemented one. :-)

-Direct serial download of build firmware to RP2040 as with RP2040 original examples in PlatformIO.
Its more convenient than pressing the buttons all the time for download.

Again, not the library but I really get your point.
This does however require the additional step to install a second stage bootloader and this would make the demo no longer self-contained.
That said - what do I need to set this up?

[AndrejValand]

Landscape/portrait works effective. But one thought. It might brake compatibility of your library to other older projects as you introduced the screen_width/screen_height? Therefore my idea was to leave the EVE_VSIZE / EVE_HSIZE and rather introduce EVE_VRES / EVE_HRES at EVE_config level? Just a thought. But for me as I'm starting with EVE displays its fine as you changed it. Or will compatibility remain?

The calibration will need smaller fonts as there are some BAR type EVE screens i myself have one Matrix oribital EVE2-38G. This has only 480x116 resolution and i think its the lowest vertical resolution where EVE displays are used.

As for the unified.blob my thinking was for the demo to be more easy for others to build upon. Would that not work if you first copy the unified.blob to flash and than do an extra separate copy of the custom font to flash? So to have two zlib's. Or is it a must that the blob gets send with the font together? I know this is not part of the library but the best feature of your library is you have working demos. This is super helpful and maybe even the most important feature of your library when starting out with the EVE displays.

Don't know how i did not see the BIN2C :) Works brilliant.

As for the comfortable upload without the button pressing don't know how it works, but you might test it out by simply making a new project via platformIO selecting the Raspberry Pi RP2040 Arduino.

The result is as following, it will probably not work for baremetall but for the Arduino it should work.

[RudolphRiedel]

I found out why it does not build for platform = raspberrypi.
There is a bug in framework-arduino-mbed/cores/arduino/api/Common.h, it tries an utterly useless "typedef bool boolean;" without including stdbool.h, useless because there is no bool anywhere, it works when you just remove the line.
And this has been "fixed" upstream back in early june:
https://github.com/arduino/ArduinoCore-API/blob/master/api/Common.h

Only the fix was to add the include instead of removing the useless line...

https://github.com/platformio/platform-raspberrypi is using https://github.com/arduino/ArduinoCore-mbed and this is using https://github.com/arduino/ArduinoCore-API.
https://github.com/arduino/ArduinoCore-API had the last release in december 2020.
https://github.com/arduino/ArduinoCore-mbed had the last release in mid may 2022.
https://github.com/platformio/platform-raspberrypi had the last release end of may 2022.

Sometimes open source is just hell. :-)
And this makes me wonder, how on earth is anyone using this?

[RudolphRiedel]

Uploading with platform = raspberrypi does not work for me.
Initially the Pico is just dead on the USB.
So I put the RP2040 in boot-mode and manually flashed the generated firmware.uf2.
After this the app is not doing anything but there is a "Raspberry Pi (Trading) Arduino RaspberryPi Pico - COM5" on the USB.
When I use "Upload" from PlatformIO the RP2040 is resetted into UF2 mode and the picotool fails to upload:
Flash: [ ] 0.2% (used 4102 bytes from 2097152 bytes)
Configuring upload protocol...
AVAILABLE: cmsis-dap, jlink, picotool, raspberrypi-swd
CURRENT: upload_protocol = picotool
Looking for upload port...
Auto-detected: COM5
Forcing reset using 1200bps open/close on port COM5
Uploading .pio\build\pico\firmware.elf
rp2040load 1.0.1 - compiled with go1.15.8
.....................
*** [upload] Error 1

Fun.

[RudolphRiedel]

Ah ok, so the Pico RP2 Boot needs to have the driver set to WinUSB with Zadig which means nothing else than that the USB implementation of the ROM Bootloader in the RP2040 is buggy.
I can upload with platform = raspberrypi now but so far the display does not show anything.

[RudolphRiedel]

And we have DMA with Arduino for the RP2040:
EVE_Test_RP2040_Arduino_EVE3-50G_PlatformIO.zip

Ok, I did not have to do much for this as I already implemented SPI over DMA for the BareMetall target.
Since the wizio-pico Arduino SPI class does not support DMA, I just went around it and used the SDK directly.

This might be working with platform-raspberrypi as well but since this one is not compiling at all there does not seem to be a point to try this further right now.

[AndrejValand]

Hi Rudolph,

DMA works like a charm :) The loop needs now under 20us the same as with barmetall version.

[AndrejValand]

All in all really grateful to you, i was able to make a working demo screen for a project with your library so i can show it to a potential customer this Monday. How can i repay you for your help up to now?

[RudolphRiedel]

Don't worry about me, I am having fun here. :-)
I could not find the EVE2-38 but I found an EVE_CFAF480128A0_039TC.
And I finally ordered an organizer with four drawers for my overflowing shelf. ;-)

[AndrejValand]

Well you are certainly a EVE programing ninja :) Would have nice to have somebody like you on our team for the project we are starting, but probably you have too much work already.

[RudolphRiedel]

I call that a slow sunday. :-)
But that was certainly more entertaining than what I am returning tomorrow to at work. :-)

[AndrejValand]

Tested a few sample displays i have, all work fine except the bar types. The hardware resolution is 480x272 but usable is only 470x116 so this also calls for a mechanism that solves the landscape/portrait mode to have a seperate Screen Horizontal/Vertical variable from the one that is used for initialization.

Will try to add this as i have the screen for testing and send you the complete package as you send me tomorrow.

[AndrejValand]

Hi Rudolf, look that you solved all the puzzles for all display combinations:) I was building some prototypes PCBs all day long so u had no time for testing. I look forward to do that tomorrow evening.

[RudolphRiedel]

Right, now that you mention it, I did get two sets of new boards on friday, assembling the few still missing parts on at least one of these is something to sweeten my day tomorrow. :-)

[AndrejValand]

Hi, just played around with the new library. Portrait calibration now works bit bar type display i like the new defines.

#define EVE_TYPE_BAR
#define EVE_HSIZE_VISIBLE   (480L)
#define EVE_VSIZE_VISIBLE   (116L)

There is only a little discrepancy with variables, and why the demo does not show up 100% correct on the bar display. Could we change the init in the demo like below? Or maybe even move this to EVE_init itself? So no matter how you use the display the new screen_width and screen_height would be set correctly? With older landscape only code the old type EVE_VSIZE and EVE_HSIZE would still hold the same values as they did for backward compatibility.

/* Set screen width and height depending on EVE Screen orientation 
           0 - Normal Landscape orientation
           1 - Inverted landscape orientation
           2 - Normal portrait orientation 
           3 - Inverted portrait orientation */
        if(rotation & 0x02) /* we are in portrait mode */
        {            
            #if defined (EVE_TYPE_BAR)
            screen_width = EVE_VSIZE_VISIBLE;
            screen_height = EVE_HSIZE_VISIBLE;
            #else
            screen_width = EVE_VSIZE;
            screen_height = EVE_HSIZE;
            #endif
        }
        else{ /* we are in landscape mode */
            #if defined (EVE_TYPE_BAR)
            screen_width = EVE_HSIZE_VISIBLE;
            screen_height = EVE_VSIZE_VISIBLE;            
            #else
            screen_width = EVE_HSIZE;
            screen_height = EVE_VSIZE;
            #endif
        }

I was thinking that it would also be nice if you already added all this portrait and bar type support now that before you make a release if you could use the bar display also in portrait mode. So to have the library complete with new features.

Some small bugs left in regards to rotation:
Normal screens demo display | calibration procedure | calibration parameters transform alter rotation. :
Mode 0 Display OK | calibrates ok | touch calibration ok
Mode 1 Display OK | calibrates ok | touch calibration not rotated with the screen, needs new calibration parameters
Mode 2 Display OK | calibrates ok | touch calibration not rotated with the screen, needs new calibration parameters
Mode 3 Display OK | calibrates ok | touch calibration not rotated with the screen, needs new calibration parameters
note: touch to leave calibration not working anymore in any screen

Bar screens:
Mode 0 Display OK | calibrates ok | touch calibration ok
Mode 1 Display clipped | black screen only | touch calibration ?
Mode 2 Display white | black screen only | touch calibration ?
Mode 3 Display OK | calibrates ok with automatic| touch calibration not rotated with the screen, needs new calibration parameters
note: touch to leave calibration working only in mode 0 (no factors shown so a different procedure with 1,2,3)

So to sum up next to my upper fix some little thing needs a touch up to everything to work in all situations :)

[RudolphRiedel]

There is only a little discrepancy with variables, and why the demo does not show up 100% correct on the bar display.
Could we change the init in the demo like below?

I changed it but I was ok with that the demo was not properly working with the bar type displays.
The demo is meant to be compact and concise, not to contain everything. :-)
So I probably should remove the whole rotation support code from tft.c.
This is just not what the demo is for.

Or maybe even move this to EVE_init itself?
So no matter how you use the display the new screen_width and screen_height would be set correctly?

I disagree that this is something to put into the library itself.
This is entirely up to the user on how he wishes to use the display.
And this is not something you could not do yourself in user-code.

Some small bugs left in regards to rotation:
Normal screens demo display | calibration procedure | calibration parameters transform alter rotation. :
Mode 0 Display OK | calibrates ok | touch calibration ok
Mode 1 Display OK | calibrates ok | touch calibration not rotated with the screen, needs new calibration parameters
Mode 2 Display OK | calibrates ok | touch calibration not rotated with the screen, needs new calibration parameters
Mode 3 Display OK | calibrates ok | touch calibration not rotated with the screen, needs new calibration parameters

Yes, this is to be expected. The calibration values are completely in user space, this needs to done individually,
sometimes the parameters work across a family, sometimes you need completely different parameters for a new production
run of the same display you were using before, sometimes you can use the same set across families.
This is why I always calibrated in Mode 0 and then used CMD_SETROTATE after init.

Adding the calibration to EVE_init() is not what I want to do, EVE_init() is for the basic low-level initialization.

note: touch to leave calibration not working anymore in any screen

Carefully calibrated or just putting three touches somewhere?

Bar screens:
Mode 0 Display OK | calibrates ok | touch calibration ok
Mode 1 Display clipped | black screen only | touch calibration ?
Mode 2 Display white | black screen only | touch calibration ?
Mode 3 Display OK | calibrates ok with automatic| touch calibration not rotated with the screen, needs new calibration parameters
note: touch to leave calibration working only in mode 0 (no factors shown so a different procedure with 1,2,3)

The clipped screen might be due to that the display you are using has a pixel offset.
I was testing this with a EVE_CFAF480128A0_039TC and it was fine even in portrait mode.
Btw. what display are you using? Is this a EVE3-38G from Matrix Orbital?

I should not really bother to put in extra code for these things, I mean beyond support to make them useable,
these are so very exotic.
If EVE_calibrate() does a bad you for your display, well, you can just grab that, put it in your code and improve it to meet your requirements.
On the other hand trying to make this work with every possible display there is would blow this even more out of proportion than it currently is with no benefit for most of the users.
This is why I always kept this in tft.c instead of moving it to EVE_commands.c, this is user-space code.
And imagine a product, you really want to add your own custom calibration screen in the style of your UI.

So yeah, I have to think about this some more but I probably will revert some of the changes.
EVE_TYPE_BAR, EVE_HSIZE_VISIBLE and EVE_VSIZE_VISIBLE seems like a good idea.
But quite frankly even these are not really necessary since you do develop your application around your display
and usually not for a range of displays. So you are already aware of what your display can do and how.
You do not need #if defined (EVE_TYPE_BAR) in your code, you already know that you have a bar type display.

My demo only runs on most of the displays as it is not doing anything usefull.

[AndrejValand]

Well if i reed your thinking about it i have to agree on most points. But on the other hand the library is more universal if supporting orientation modes 0,1,2,3 directly and #ifdefined in a library should not hurt its compactness, portability and readability as this has to be only implemented in two places maximum. But its fully understandable the library it can not be universal for all possible display types, and yes it does not make sense fixing it for the Matrix Orbital EVE2-38G i was testing for mode 1&2. All other combinations for varios displays i have work fine now with all your implementations and the small change i have written above. As for the EVE2-38G I have tested it now and drawing to display has to be shifted in modes 1&2 so no sense to implementing that i agree this is completely user code if needed...

[RudolphRiedel]

I have a new test-archive.
EVE_Test_RP2040_Arduino_EVE3-50G_PlatformIO.zip

This one supports SPI over DMA with platform = raspberrypi which uses ArduinoCore-mbed.
It really was a different can of worms to deal with this.
First the ArduinoCore-mbed is using a different set of pins for the SPI and there do not seem to be any
examples around, I could not find out how to change the pins for SCK, MOSI and MISO.
Then there is no support for DMA in the official Arduino SPI class/wrapper anyways so I had to find out
if and how to use the RP2040 SDK directly.
The last odd thing was that the RP2040 SDK function spi_init() is renamed to _spi_init().
Edit: forgot to mention, it throws quite a number of warnings when compiling.

And now that it works there is this:

This is the same sequence when running with wizio-pico:

M0+M1+M2 is tft.c/TFT_touch()
M3 is tft.c/TFT_display()

Somehow running the exact same code takes twice as long when running it with ArduinoCore-mbed.

[AndrejValand]

Nice. Will try this when we get back from vacation.