Thinking about removing EVE_...._burst() functions.

[RudolphRiedel]

I am thinking about removing EVE_...._burst() functions.

Not EVE_start_cmd_burst() / EVE_end_cmd_burst(), but all the extra functions that only work in burst-mode:
EVE_cmd_append_burst()
EVE_cmd_bgcolor_burst()
EVE_cmd_button_burst()
...

These offer a puny speed-boost over using the normal functions of a few clock cycles.
But with any controller that can be used with DMA this is utterly pointless.
Going down from 14µs for the display update to 13µs is not worth the effort.

Yes, there are real gains for 8 bit controllers like AVR.
I have not touched AVR in years now outside checking if things still compile, I feel like it is time to move on.
The sane bare minimum to support these days would be a Cortex-M0.

Yes, while Arduino uses 32 bit controllers for a very long time now, they still do not support DMA in their API.
At least not officially, some third party variants like Teensy do support DMA, each with a different API.
And I am growing tired of it.
When I was updating the Arduino SPI class for the UNO R4 I was required to remove a function that was not in the official API.
Even if I had added DMA support, it would not have ended up in the UNO R4 repository.

Do you really still use a 8 bit controller with an EVE display?
I would like to move on.
And even when removing these functions, this is still probably the fastest EVE library, even for 8 bit / without DMA support.

[dstulken]

I am thinking about removing EVE_...._burst() functions.
...
The sane bare minimum to support these days would be a Cortex-M0.
...
Do you really still use a 8 bit controller with an EVE display?

Just to be clear, you are considering removing only an architecture-specific optimization, not support for an architecture entirely, correct? 8-bit AVR would still work, just less efficiently, after your proposed changes?

At a high level, it would seem to be a big loss to remove 8-bit architecture support as a whole, as I think EVE-based displays are uniquely suited for them. While there are many faster processor options out there, there are also other display/UI library options available for (and enabled by) those faster processors. The 8-bit chips however are much more limited in what they can drive, so pairing them with a display system that offloads the heavy lifting to other hardware is quite beneficial.

I don't know how many people use 8-bit processors, or how much of your time it takes to maintain support... but there is a large gap between low-resource displays like u8g2, and the high end with projects like LVGL that are absolutely not possible with those 8-bit processors. EVE really does do a good job of filling that gap.

(It's all moot if nobody uses it of course. I'm just saying from a capabilities perspective, it would be a loss.)

[RudolphRiedel]

No, this is not about removing 8-bit support or anything specific to 8-bit support.

I have a lot of code like this:

/**
 * @brief Assign the value of the current matrix to the bitmap transform matrix.
 */
void EVE_cmd_setmatrix(void)
{
    if (0U == cmd_burst)
    {
        eve_begin_cmd(CMD_SETMATRIX);
        EVE_cs_clear();
    }
    else
    {
        spi_transmit_burst(CMD_SETMATRIX);
    }
}

/**
 * @brief Assign the value of the current matrix to the bitmap transform matrix, only works in burst-mode.
 */
void EVE_cmd_setmatrix_burst(void)
{
    spi_transmit_burst(CMD_SETMATRIX);
}

So for every regular display-list function there is a _burst variant which saves about two clock cycles when used in burst-mode,
This puny optimization makes the functions a bit akward to use, to maintain and is pointless when DMA is available.
So the biggest impact would be for 8-bit controllers and any platform that does not support DMA.

And I spent about two hours chatting with ChatGPT yesterday, well, mostly rejecting what ChatGPT was proposing, there seems to be no way to deal with this if/else at compile time, at least not in way that does not require extra clock cycles somewhere else and/or would make the binary larger.

Well, I just grabbed an Arduino R3 clone, I need to actually run the current library on it to see how the current performance looks like and what difference it makes to not use the _burst functions.

[RudolphRiedel]

Hmm, I just found out that I broke support for GT911 touch controllers for EVE2 and AVR with an update to EVE_commands.c that I pushed 2022-12-30.
I just fixed it.
But that probably means that no one is using that code for at least the past two years with an AVR.

[dstulken]

But that probably means that no one is using that code for at least the past two years with an AVR.

Or that those who do are working from older checkouts of the codebase. I myself am guilty of this.

[RudolphRiedel]

Ok, now that I can actually use the display I selected with the UNO R3, time for some measurements.

Time for the display update of the simple demo, 27 commands:
earlier code with EVE_cmd_dl_burst() functions: 340µs, 77 bytes SRAM, 12104 bytes FLASH
current code without EVE_cmd_dl functions: 340µs , 77 bytes SRAM, 12328 bytes FLASH - no surprise there, same code, more functions
current code, no _burst functions: 396µs, 77 bytes SRAM, 13488 bytes FLASH
current code, using EVE_cmd_number_burst(): 384µs, 77 bytes SRAM, 13594 bytes FLASH

Ok, that a more "complex" function like for CMD_NUMBER needs 12µs longer than the _burst variant is a surprise.
That is a whopping 192 clock cycles at 16MHz, there is no way that this is the if statement.
The impact by less complex functions is less dramatic.
The differences in code size are less surprising, the functions that are not used get removed by the linker.
And removing the complexer function saves more memory.

void EVE_cmd_number(int16_t xc0, int16_t yc0, uint16_t font, uint16_t options, int32_t number)
{
    if (0U == cmd_burst)
    {
        eve_begin_cmd(CMD_NUMBER);
        spi_transmit_32(i16_i16_to_u32(xc0, yc0));
        spi_transmit_32(u16_u16_to_u32(font, options));
        spi_transmit_32(i32_to_u32(number));
        EVE_cs_clear();
    }
    else
    {
        spi_transmit_burst(CMD_NUMBER);
        spi_transmit_burst(i16_i16_to_u32(xc0, yc0));
        spi_transmit_burst(u16_u16_to_u32(font, options));
        spi_transmit_burst(i32_to_u32(number));
    }
}

void EVE_cmd_number_burst(int16_t xc0, int16_t yc0, uint16_t font, uint16_t options, int32_t number)
{
    spi_transmit_burst(CMD_NUMBER);
    spi_transmit_burst(i16_i16_to_u32(xc0, yc0));
    spi_transmit_burst(u16_u16_to_u32(font, options));
    spi_transmit_burst(i32_to_u32(number));
}

How the heck is EVE_cmd_number() taking 12µs more to execute than EVE_cmd_number_burst()?