BRT Community

Please login or register.

Login with username, password and session length
Advanced search  

News:

Welcome to the Bridgetek Community!

Please read our Welcome Note

Technical Support enquires
please contact the team
@ Bridgetek Support

Please refer to our website for detailed information on all our products - Bridgetek - Bridging Technology

Pages: [1] 2

Author Topic: BRT_AN_025 Beta - Portable MCU library for EVE  (Read 28407 times)

BRT Community

  • Administrator
  • Hero Member
  • *****
  • Posts: 732
    • View Profile
BRT_AN_025 Beta - Portable MCU library for EVE
« on: January 09, 2020, 01:39:10 PM »

Hi,

We have a new beta version of a framework for EVE which is designed to be portable across a range of different MCUs. The download includes projects for the following MCUs but you can also use it as the basis of your code on other platforms too.

- BridgeTek FT900
- ST STM32
- Microchip PIC18F
- Espressif ESP32
- TI MSP430
- BeagleBone
- Raspberry Pi

The code currently supports the FT80x and FT81x families of EVE.

Here are the draft document and the beta code project download links:

BRT_AN_025_FT8xx_Portable_MCU_Library_DRAFT.pdf
BRT_AN_025_Source_BETA.zip
(Note: The link in the pdf file for the source code download is not yet active but you can download the code via the link above)

The beta document and code are supplied on an as-is basis and are not guaranteed by BridgeTek.

Coming soon...
- We have almost finished adding the BT81x support to the code and this will be released as an update soon
- We also have a separate application note showing how to port this code to other MCUs, using an NXP K64 as an example.
- We will also be creating further code examples in future using the framework provided in BRT_AN_025

We hope this code helps to get you up and running with EVE on your own MCU. If you have any feedback or questions then please get in touch via support.emea@brtchip.com quoting "BRT_AN_025 feedback" in the email subject.

Best Regards,
BRT Community
Logged

Rudolph

  • Sr. Member
  • ****
  • Posts: 389
    • View Profile
Re: BRT_AN_025 Beta - Portable MCU library for EVE
« Reply #1 on: February 21, 2020, 04:03:22 PM »

Since this looks nothing like the EVE HAL 2.0 but is very close to my own library, is it planned to add an exporter for this to the EVE Screen Editor?


Edit: I started to port an example to a platform that I can actually use to test this.
And my first feedback really is - what the heck?

Edit: I ported it now, sort of,  and I seriously doubt that the STM32 example even compiles.
Your library has quite some issues and I would not really call it portable code.
What goes where, which include is used for what, this is a mess so far.

Please provide a sample project that builds with PlatformIO.


Anyways, I modified the eve_display() function in eve_example.c:

Code: [Select]
#define BRT_LOGO_W 147
#define BRT_LOGO_H 60

void eve_display(void)
{
uint32_t counter = 0;

EVE_LIB_BeginCoProList();
EVE_CMD_DLSTART();
EVE_CLEAR_COLOR_RGB(0, 0, 0);
EVE_CLEAR(1,1,1);
EVE_COLOR_RGB(255, 255, 255);

EVE_CMD_NUMBER(120, 460, 28, EVE_OPT_RIGHTX|5, num_profile_a); /* duration in µs for this function */

EVE_CMD_NUMBER(70, 100, 28, EVE_OPT_RIGHTX|5, BRT_LOGO_W);
EVE_CMD_NUMBER(70, 130, 28, EVE_OPT_RIGHTX|5, BRT_LOGO_H);

EVE_BEGIN(EVE_BEGIN_BITMAPS);
EVE_CMD_SETBITMAP(0, EVE_FORMAT_RGB565, BRT_LOGO_W, BRT_LOGO_H);

// Set origin on canvas using EVE_VERTEX_TRANSLATE.
EVE_VERTEX_TRANSLATE_X(((EVE_DISP_WIDTH/2)-(BRT_LOGO_W/2)) * 16);
EVE_VERTEX2II(0, 0, 0, 0);
EVE_VERTEX_TRANSLATE_X(0);

EVE_CMD_TEXT(EVE_DISP_WIDTH/2, BRT_LOGO_H+10, 29, EVE_OPT_CENTERX, "Touch the counter");

EVE_TAG(100);
EVE_COLOR_RGB(255, 0, 0);

EVE_CMD_NUMBER(400, 240, 30, EVE_OPT_CENTER|5, counter);

EVE_DISPLAY();
EVE_CMD_SWAP();
EVE_LIB_EndCoProList();
EVE_LIB_AwaitCoProEmpty();
}

Not to make it display a fancier list but to allow to call it from main() every 20ms.
I also removed the touch as I am using an EVE2-35G for the test and it uses a GT911 which I
did not want to patch into your library.

I also removed the custom font and the use of bitmap-handle 7 for the logo in order to not have
to add this to my own code as well.

I completely replaced main.c with my own and used the same code to init the core, the timer and the SPI in both projects.
Same toolchain, same optimisation level (-O2).
And of course I am using one hardware, for this test a board I designed with an ATSAMC21E18A, this is a Cortex-M0+ running at 48MHz.
Oh yes, I also disabled DMA for my own library.

Now when I run your version with the function above the number printed for the var num_profile_a is 942.
It takes 942µs to run the function once.

There is one optimisation, remove the last line: "EVE_LIB_AwaitCoProEmpty();".
This is completely safe, for one it is part of "EVE_LIB_BeginCoProList();" anyways and then the function
is now called only once every 20ms and not anymore as fast as the controller could make the loop.

Without the line the time spend in the function drops to 372µs.

In my own library this looks like this:
Code: [Select]
#define BRT_LOGO_W 147
#define BRT_LOGO_H 60

void TFT_display(void)
{
uint32_t counter = 0;

if(tft_active != 0)
{
EVE_start_cmd_burst(); /* start writing to the cmd-fifo as one stream of bytes, only sending the address once */

EVE_cmd_dl(CMD_DLSTART); /* start the display list */
EVE_cmd_dl(DL_CLEAR_RGB | BLACK); /* set the default clear color to black */
EVE_cmd_dl(DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG); /* clear the screen - this and the previous prevent artifacts between lists, Attributes are the color, stencil and tag buffers */

EVE_cmd_dl(DL_COLOR_RGB | WHITE);

EVE_cmd_number(120, 460, 28, EVE_OPT_RIGHTX|5, num_profile_a); /* duration in µs for this function */

EVE_cmd_number(70, 100, 28, EVE_OPT_RIGHTX|5, BRT_LOGO_W);
EVE_cmd_number(70, 130, 28, EVE_OPT_RIGHTX|5, BRT_LOGO_H);

EVE_cmd_dl(DL_BEGIN | EVE_BITMAPS);
EVE_cmd_setbitmap(MEM_LOGO, EVE_RGB565, BRT_LOGO_W, BRT_LOGO_H);

// Set origin on canvas using EVE_VERTEX_TRANSLATE.
EVE_cmd_dl(VERTEX_TRANSLATE_X(((EVE_HSIZE/2)-(BRT_LOGO_W/2)) * 16));
EVE_cmd_dl(VERTEX2II(0, 0, 0, 0));
EVE_cmd_dl(VERTEX_TRANSLATE_X(0));

EVE_cmd_text(EVE_HSIZE/2, BRT_LOGO_H+10, 29, EVE_OPT_CENTERX, "Touch the counter");

EVE_cmd_dl(TAG(100));
EVE_cmd_dl(DL_COLOR_RGB | RED);
EVE_cmd_number(400, 240, 30, EVE_OPT_CENTER|5, counter);

EVE_cmd_dl(DL_DISPLAY); /* instruct the graphics processor to show the list */
EVE_cmd_dl(CMD_SWAP); /* make this list active */

EVE_end_cmd_burst(); /* stop writing to the cmd-fifo */
EVE_cmd_start(); /* order the command co-processor to start processing its FIFO queue but do not wait for completion */
}
}

This also shows why I asked about the EVE Screen Editor output, I could almost directly use that. :-)
And I already plan to add more functions to replace the EVE_cmd_dl() calls.

This takes 259µs to execute.
When I remove the EVE_start_cmd_burst()/EVE_end_cmd_burst() lines this goes up to 351µs.

What this does is described in the comment: /* start writing to the cmd-fifo as one stream of bytes, only sending the address once */
This removes three bytes of overhead from every command by not sending the adress in the FIFO over and over again.

When I also make the function wait for the FIFO to be empty the time goes up to 917µs.

So  my library is 25µs faster under the same conditions, 21µs without waiting and 113µs with the litte burst-trick.
Sure, this is not much but this also is a very short display llist.

And just for the kicks since I can not do this with your library.  8)
When I enable DMA by setting "EVE_DMA" in my EVE_target.h and not changing anything else, the time drops to 82µs.

To be totally unfair that is 942µs for your example and 82µs for my version.  :o
« Last Edit: February 23, 2020, 09:01:23 PM by Rudolph »
Logged

BRT Community

  • Administrator
  • Hero Member
  • *****
  • Posts: 732
    • View Profile
Re: BRT_AN_025 Beta - Portable MCU library for EVE
« Reply #2 on: February 25, 2020, 11:12:44 AM »

Hi Rudolph,

Thanks,
It is good to get your thoughts on the code and we'll certainly go through and review your concerns and recommendations.

Just to provide a few initial replies,

This library does use SPI burst writes and so the address is only sent once and the commands are then streamed over SPI and so it works in a similar way to your library.

The STM32 one was built using the Keil uVision IDE.

We thought our functions here...
EVE_LIB_BeginCoProList(); // CS low and send address
commands
EVE_LIB_EndCoProList(); // CS high and update REG_CMD_WRITE
EVE_LIB_AwaitCoProEmpty();     // Wait pointers becoming equal

... were quite similar to your functions here...
EVE_start_cmd_burst(); EVE_end_cmd_burst(); EVE_cmd_start(); 

We may have some duplication however. There could be cases where this is needed (e.g. if you execute a command and then want to perform other register or memory actions when complete rather than send a new co-pro list) and so we do check for the completion of the commands at the end of the list as well as at the start. We may be able to optimise this however to make it run faster.

We are keen to make the code as good and as easy to use as possible and so we appreciate your honest feedback,

Best Regards, BRT Community



Logged

Rudolph

  • Sr. Member
  • ****
  • Posts: 389
    • View Profile
Re: BRT_AN_025 Beta - Portable MCU library for EVE
« Reply #3 on: February 25, 2020, 10:01:26 PM »

Hello,

Thanks,
It is good to get your thoughts on the code and we'll certainly go through and review your concerns and recommendations.

Just keep in mind that I am not trying to be rude here or attacking you.
But with Englisch not beeing my native language I sometimes struggle to write as polite as I intend to.
So if I overstep somewhere, please point it out to me.

Quote
The STM32 one was built using the Keil uVision IDE.

Okay, I was wrong, it does indeed compile just fine without any change when using Keil uVision IDE.
I just can not test it.

Edit: and Keil really is a tad bit to intrusive for me.

What made me believe that it probably would not build is for example the chip-select functions
in EVE_MCU_STM32.c.
These look like this:
Code: [Select]
inline void MCU_CSlow(void)
{
  HAL_GPIO_WritePin(GPIOB, GPIO_PIN_6, GPIO_PIN_RESET); //lo
  //Nop();
}

Having a function declared as "inline" from within a .c file usually does not work.

The function in my EVE_MCU_ATSAMC21.c is this:
Code: [Select]
void MCU_CSlow(void)
{
PORT->Group[EVE_CS_PORT].OUTCLR.reg = EVE_CS;
}

And it will not compile when I put "inline" in front of it.
Well, I am using GCC and the Keil µVision IDE uses the ARM compiler, maybe that is it.

There are other issues though.
Why is eve_example.h defining the platform_calib_xxx() functions that are in main.c?
Why is MCU.h defining MCU_Setup() that is in main.c?
Why are so many modules over-including files they do not even need?
Why is EVE_MCU_STM32.c setting up the system clock?
What is the purpose of all these byte-swapping functions and why are they in EVE_MCU_xx.c?

Quote
This library does use SPI burst writes and so the address is only sent once and the commands are then streamed over SPI And so it works in a similar way to your library.

We thought our functions here...
EVE_LIB_BeginCoProList(); // CS low and send address
commands
EVE_LIB_EndCoProList(); // CS high and update REG_CMD_WRITE
EVE_LIB_AwaitCoProEmpty();     // Wait pointers becoming equal

... were quite similar to your functions here...
EVE_start_cmd_burst(); EVE_end_cmd_burst(); EVE_cmd_start(); 

You are right, I hooked up a logic-analyzer and attached two logfiles.
I created these with a Logic 16 from Saleae.
This clearly shows now that you actually are using a command-burst.
I assumed wrongly your version does not burst since it put the execution times so much closer together
when I switched it off for my version.

Unfortunately this makes the different in speed quite a lot bigger.
With my version commands are transfered in 248µs plus 7,16µs for the command to execute.
With your version I get a command, sometimes two or more of 14µs before the burst, 337µs for the commands and
13.34µs for the command to execute.

Oh yes, I do not check if the command-fifo is ready.
This is because apart from loading images it is always ready to accept more data as soon as you execute the fifo.
EVE just is this fast to execute the fifo, there is not much of a chance to be faster.
The only thing that I found so far that really takes time is decoding .png images.
And then there is that I am only writing every 20ms to the FIFO and always check for the execution time
during development of a HMI.

The command to execute is of course only the write to REG_CMD_WRITE.
For your version I right now have the sequence 0xb0 0x20 0xfc 0xec 0x08 0x00 0x00 on the screen.
It takes 1.58µs from chip-select-low to the first rising clock.
The gaps between the bytes are: 0.66µs, 0.76µs, 2.48µs, 0.68µs and 0.76µs.
And the time from the last falling clock to the rising chip select is 1.34µs.

For my version I ended up with the sequence 0xb0 0x20 0xfc 0x84 0x07.
Okay, first difference, I only write REG_CMD_WRITE as 16 bits - as the valid range is 12 bits anyways.
It takes 0.44µs from chip-select-low to the first rising clock.
The gaps between the bytes are: 0.66µs, 0.68µs, 0.9µs and 0.82µs.
And the time from the last falling clock to the rising chip select is 0.56µs.

I would like to know what you measure with your system, preferably of course with the STM32 and
runnning the SPI at 12MHz. :-)

This is my start-command:
Code: [Select]
/* order the command co-processor to start processing its FIFO queue and do not wait for completion */
void EVE_cmd_start(void)
{
uint32_t ftAddress;

#if defined (EVE_DMA)
if(EVE_dma_busy)
{
return; /* just do nothing if a dma transfer is in progress */
}
#endif

ftAddress = REG_CMD_WRITE; /* this changes between EVE 80x and 81x, so as a constant at compile-time the compiler should happily optimize away the following bit-shifting */

EVE_cs_set();
spi_transmit((uint8_t)(ftAddress >> 16) | MEM_WRITE); /* send Memory Write plus high address byte */
spi_transmit((uint8_t)(ftAddress >> 8)); /* send middle address byte */
spi_transmit((uint8_t)(ftAddress));      /* send low address byte */
spi_transmit((uint8_t)(cmdOffset));      /* send data low byte */
spi_transmit((uint8_t)(cmdOffset >> 8)); /* send data high byte */
EVE_cs_clear();
}

All of the code at the bottom is replaced with inline code though.
There is no function beeing called.
It sure does cost a couple kB of code extra but I worry about that if I actually run out of memory. :-)
And with the BT81x this is even less of an issue.

Quote
We may have some duplication however. There could be cases where this is needed (e.g. if you execute a command and then want to perform other register or memory actions when complete rather than send a new co-pro list) and so we do check for the completion of the commands at the end of the list as well as at the start. We may be able to optimise this however to make it run faster.

Sure, my code does read the touch registers every 5 ms and as you can see in my test-code I usually read the size of the display list right before building a new one in order to be able to keep an eye on its size.
The TFT_touch() function in my current project does check if EVE is busy, mostly due to my use of DMA,
but also because the little overhead does no harm there since the function has a very short runtime overall.
And it uses a CMD_TRACK for a slider with my EVE_cmd_execute() function for this which waits for completion of the command.
But when I check this with the logic-analyzer I usually see the command, the write to REG_CMD_WRITE and only a single read of REG_CMD_READ since EVE executes this faster than I can check if she is busy.
So for this I could even change to EVE_cmd_start() since building the next display list is at least a return-from-function and a call-function away.
But then again, the usually <50µs for the touch function are neglectable in comparison with building the display list.
My current project has a display list that takes >1ms to build, even without any SPI transfers due to DMA.
« Last Edit: February 25, 2020, 10:34:15 PM by Rudolph »
Logged

epichfallen

  • Newbie
  • *
  • Posts: 1
    • View Profile
Re: BRT_AN_025 Beta - Portable MCU library for EVE
« Reply #4 on: June 11, 2020, 01:46:36 PM »

Hello there,

I have tried to install the example project for ESP32 but the build process failed. I'm not quite experienced with esp-idf or eve.

The compiler is giving me some errors and warnings. I wonder if this is caused by the version of esp-idf. Or am I making a mistake during the process?

Code: [Select]

 #pragma message "Compiling " __FILE__ " for Espressif ESP32"
         ^~~~~~~
In file included from ../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:65:
../lib/eve/eve_arch_esp32/endian.h:86: warning: "__bswap16" redefined
 #define __bswap16     __bswap_16

In file included from ../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:59:
c:\users\dunya\.espressif\tools\xtensa-esp32-elf\esp-2019r2-8.2.0\xtensa-esp32-elf\xtensa-esp32-elf\sys-include\machine\endian.h:24: note: this is the location of the previous definition
 #define __bswap16(_x) __builtin_bswap16(_x)

In file included from ../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:65:
../lib/eve/eve_arch_esp32/endian.h:87: warning: "__bswap32" redefined
 #define __bswap32     __bswap_32

In file included from ../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:59:
c:\users\dunya\.espressif\tools\xtensa-esp32-elf\esp-2019r2-8.2.0\xtensa-esp32-elf\xtensa-esp32-elf\sys-include\machine\endian.h:25: note: this is the location of the previous definition
 #define __bswap32(_x) __builtin_bswap32(_x)

../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c: In function 'MCU_Init':
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:91:5: error: unknown type name 'gpio_config_t'; did you mean 'spi_bus_config_t'?
     gpio_config_t io_conf;
     ^~~~~~~~~~~~~
     spi_bus_config_t
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:73:22: error: 'GPIO_NUM_19' undeclared (first use in this function); did you mean 'PIN_NUM_PD'?
 #define PIN_NUM_MISO GPIO_NUM_19
                      ^~~~~~~~~~~
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:94:24: note: in expansion of macro 'PIN_NUM_MISO'
         .miso_io_num = PIN_NUM_MISO,
                        ^~~~~~~~~~~~
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:73:22: note: each undeclared identifier is reported only once for each function it appears in
 #define PIN_NUM_MISO GPIO_NUM_19
                      ^~~~~~~~~~~
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:94:24: note: in expansion of macro 'PIN_NUM_MISO'
         .miso_io_num = PIN_NUM_MISO,
                        ^~~~~~~~~~~~
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:74:22: error: 'GPIO_NUM_23' undeclared (first use in this function); did you mean 'PIN_NUM_PD'?
 #define PIN_NUM_MOSI GPIO_NUM_23
                      ^~~~~~~~~~~
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:95:24: note: in expansion of macro 'PIN_NUM_MOSI'
         .mosi_io_num = PIN_NUM_MOSI,
                        ^~~~~~~~~~~~
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:75:22: error: 'GPIO_NUM_18' undeclared (first use in this function); did you mean 'PIN_NUM_PD'?
 #define PIN_NUM_CLK  GPIO_NUM_18
                      ^~~~~~~~~~~
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:96:24: note: in expansion of macro 'PIN_NUM_CLK'
         .sclk_io_num = PIN_NUM_CLK,
                        ^~~~~~~~~~~
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:117:12: error: request for member 'intr_type' in something not a structure or union
     io_conf.intr_type = GPIO_PIN_INTR_DISABLE;
            ^
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:117:25: error: 'GPIO_PIN_INTR_DISABLE' undeclared (first use in this function)
     io_conf.intr_type = GPIO_PIN_INTR_DISABLE;
                         ^~~~~~~~~~~~~~~~~~~~~
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:119:12: error: request for member 'mode' in something not a structure or union
     io_conf.mode = GPIO_MODE_OUTPUT;
            ^
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:119:20: error: 'GPIO_MODE_OUTPUT' undeclared (first use in this function); did you mean 'GPIO_SD5_OUT_IDX'?
     io_conf.mode = GPIO_MODE_OUTPUT;
                    ^~~~~~~~~~~~~~~~
                    GPIO_SD5_OUT_IDX
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:121:12: error: request for member 'pin_bit_mask' in something not a structure or union
     io_conf.pin_bit_mask = BIT(PIN_NUM_PD) | BIT(PIN_NUM_CS);
            ^
In file included from ../../components/esp_common/include/esp_system.h:22,
                 from ../../components/freertos/include/freertos/portable.h:128,
                 from ../../components/freertos/include/freertos/FreeRTOS.h:105,
                 from ../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:62:
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:78:22: error: 'GPIO_NUM_15' undeclared (first use in this function); did you mean 'PIN_NUM_PD'?
 #define PIN_NUM_PD   GPIO_NUM_15
                      ^~~~~~~~~~~
../../components/esp_common/include/esp_bit_defs.h:53:42: note: in definition of macro 'BIT'
 #define BIT(nr)                 (1UL << (nr))
                                          ^~
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:121:32: note: in expansion of macro 'PIN_NUM_PD'
     io_conf.pin_bit_mask = BIT(PIN_NUM_PD) | BIT(PIN_NUM_CS);
                                ^~~~~~~~~~
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:76:22: error: 'GPIO_NUM_22' undeclared (first use in this function); did you mean 'PIN_NUM_PD'?
 #define PIN_NUM_CS   GPIO_NUM_22
                      ^~~~~~~~~~~
../../components/esp_common/include/esp_bit_defs.h:53:42: note: in definition of macro 'BIT'
 #define BIT(nr)                 (1UL << (nr))
                                          ^~
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:121:50: note: in expansion of macro 'PIN_NUM_CS'
     io_conf.pin_bit_mask = BIT(PIN_NUM_PD) | BIT(PIN_NUM_CS);
                                                  ^~~~~~~~~~
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:123:12: error: request for member 'pull_down_en' in something not a structure or union
     io_conf.pull_down_en = 0;
            ^
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:125:12: error: request for member 'pull_up_en' in something not a structure or union
     io_conf.pull_up_en = 0;
            ^
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:127:5: error: implicit declaration of function 'gpio_config'; did you mean 'lldesc_config'? [-Werror=implicit-function-declaration]
     gpio_config(&io_conf);
     ^~~~~~~~~~~
     lldesc_config
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c: In function 'MCU_CSlow':
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:140:5: error: implicit declaration of function 'gpio_set_level'; did you mean '_xtos_set_intlevel'? [-Werror=implicit-function-declaration]
     gpio_set_level(PIN_NUM_CS, 0);
     ^~~~~~~~~~~~~~
     _xtos_set_intlevel
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:76:22: error: 'GPIO_NUM_22' undeclared (first use in this function); did you mean 'PIN_NUM_PD'?
 #define PIN_NUM_CS   GPIO_NUM_22
                      ^~~~~~~~~~~
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:140:20: note: in expansion of macro 'PIN_NUM_CS'
     gpio_set_level(PIN_NUM_CS, 0);
                    ^~~~~~~~~~
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c: In function 'MCU_CShigh':
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:76:22: error: 'GPIO_NUM_22' undeclared (first use in this function); did you mean 'PIN_NUM_PD'?
 #define PIN_NUM_CS   GPIO_NUM_22
                      ^~~~~~~~~~~
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:146:20: note: in expansion of macro 'PIN_NUM_CS'
     gpio_set_level(PIN_NUM_CS, 1);
                    ^~~~~~~~~~
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c: In function 'MCU_PDlow':
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:78:22: error: 'GPIO_NUM_15' undeclared (first use in this function); did you mean 'PIN_NUM_PD'?
 #define PIN_NUM_PD   GPIO_NUM_15
                      ^~~~~~~~~~~
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:152:20: note: in expansion of macro 'PIN_NUM_PD'
     gpio_set_level(PIN_NUM_PD, 0);
                    ^~~~~~~~~~
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c: In function 'MCU_PDhigh':
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:78:22: error: 'GPIO_NUM_15' undeclared (first use in this function); did you mean 'PIN_NUM_PD'?
 #define PIN_NUM_PD   GPIO_NUM_15
                      ^~~~~~~~~~~
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:158:20: note: in expansion of macro 'PIN_NUM_PD'
     gpio_set_level(PIN_NUM_PD, 1);
                    ^~~~~~~~~~
cc1.exe: some warnings being treated as errors
[832/838] Building C object esp-idf/eve_arch_esp32/CMakeFiles/__idf_eve_arch_esp32.dir/__/source/EVE_HAL.c.obj
ninja: build stopped: subcommand failed.
ninja failed with exit code 1

Logged

BRT Community

  • Administrator
  • Hero Member
  • *****
  • Posts: 732
    • View Profile
Re: BRT_AN_025 Beta - Portable MCU library for EVE
« Reply #5 on: June 12, 2020, 01:04:10 PM »

Hello Epichfallen,

Can you let me know which version of the IDE you are using?

Best Regards,
BRT Community
Logged

korstiaan

  • Newbie
  • *
  • Posts: 14
    • View Profile
Re: BRT_AN_025 Beta - Portable MCU library for EVE
« Reply #6 on: July 01, 2020, 02:52:33 PM »

Hello there,

I have tried to install the example project for ESP32 but the build process failed. I'm not quite experienced with esp-idf or eve.

The compiler is giving me some errors and warnings. I wonder if this is caused by the version of esp-idf. Or am I making a mistake during the process?

Code: [Select]

 #pragma message "Compiling " __FILE__ " for Espressif ESP32"
         ^~~~~~~
In file included from ../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:65:
../lib/eve/eve_arch_esp32/endian.h:86: warning: "__bswap16" redefined
 #define __bswap16     __bswap_16

In file included from ../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:59:
c:\users\dunya\.espressif\tools\xtensa-esp32-elf\esp-2019r2-8.2.0\xtensa-esp32-elf\xtensa-esp32-elf\sys-include\machine\endian.h:24: note: this is the location of the previous definition
 #define __bswap16(_x) __builtin_bswap16(_x)

In file included from ../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:65:
../lib/eve/eve_arch_esp32/endian.h:87: warning: "__bswap32" redefined
 #define __bswap32     __bswap_32

In file included from ../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:59:
c:\users\dunya\.espressif\tools\xtensa-esp32-elf\esp-2019r2-8.2.0\xtensa-esp32-elf\xtensa-esp32-elf\sys-include\machine\endian.h:25: note: this is the location of the previous definition
 #define __bswap32(_x) __builtin_bswap32(_x)

../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c: In function 'MCU_Init':
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:91:5: error: unknown type name 'gpio_config_t'; did you mean 'spi_bus_config_t'?
     gpio_config_t io_conf;
     ^~~~~~~~~~~~~
     spi_bus_config_t
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:73:22: error: 'GPIO_NUM_19' undeclared (first use in this function); did you mean 'PIN_NUM_PD'?
 #define PIN_NUM_MISO GPIO_NUM_19
                      ^~~~~~~~~~~
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:94:24: note: in expansion of macro 'PIN_NUM_MISO'
         .miso_io_num = PIN_NUM_MISO,
                        ^~~~~~~~~~~~
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:73:22: note: each undeclared identifier is reported only once for each function it appears in
 #define PIN_NUM_MISO GPIO_NUM_19
                      ^~~~~~~~~~~
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:94:24: note: in expansion of macro 'PIN_NUM_MISO'
         .miso_io_num = PIN_NUM_MISO,
                        ^~~~~~~~~~~~
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:74:22: error: 'GPIO_NUM_23' undeclared (first use in this function); did you mean 'PIN_NUM_PD'?
 #define PIN_NUM_MOSI GPIO_NUM_23
                      ^~~~~~~~~~~
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:95:24: note: in expansion of macro 'PIN_NUM_MOSI'
         .mosi_io_num = PIN_NUM_MOSI,
                        ^~~~~~~~~~~~
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:75:22: error: 'GPIO_NUM_18' undeclared (first use in this function); did you mean 'PIN_NUM_PD'?
 #define PIN_NUM_CLK  GPIO_NUM_18
                      ^~~~~~~~~~~
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:96:24: note: in expansion of macro 'PIN_NUM_CLK'
         .sclk_io_num = PIN_NUM_CLK,
                        ^~~~~~~~~~~
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:117:12: error: request for member 'intr_type' in something not a structure or union
     io_conf.intr_type = GPIO_PIN_INTR_DISABLE;
            ^
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:117:25: error: 'GPIO_PIN_INTR_DISABLE' undeclared (first use in this function)
     io_conf.intr_type = GPIO_PIN_INTR_DISABLE;
                         ^~~~~~~~~~~~~~~~~~~~~
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:119:12: error: request for member 'mode' in something not a structure or union
     io_conf.mode = GPIO_MODE_OUTPUT;
            ^
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:119:20: error: 'GPIO_MODE_OUTPUT' undeclared (first use in this function); did you mean 'GPIO_SD5_OUT_IDX'?
     io_conf.mode = GPIO_MODE_OUTPUT;
                    ^~~~~~~~~~~~~~~~
                    GPIO_SD5_OUT_IDX
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:121:12: error: request for member 'pin_bit_mask' in something not a structure or union
     io_conf.pin_bit_mask = BIT(PIN_NUM_PD) | BIT(PIN_NUM_CS);
            ^
In file included from ../../components/esp_common/include/esp_system.h:22,
                 from ../../components/freertos/include/freertos/portable.h:128,
                 from ../../components/freertos/include/freertos/FreeRTOS.h:105,
                 from ../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:62:
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:78:22: error: 'GPIO_NUM_15' undeclared (first use in this function); did you mean 'PIN_NUM_PD'?
 #define PIN_NUM_PD   GPIO_NUM_15
                      ^~~~~~~~~~~
../../components/esp_common/include/esp_bit_defs.h:53:42: note: in definition of macro 'BIT'
 #define BIT(nr)                 (1UL << (nr))
                                          ^~
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:121:32: note: in expansion of macro 'PIN_NUM_PD'
     io_conf.pin_bit_mask = BIT(PIN_NUM_PD) | BIT(PIN_NUM_CS);
                                ^~~~~~~~~~
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:76:22: error: 'GPIO_NUM_22' undeclared (first use in this function); did you mean 'PIN_NUM_PD'?
 #define PIN_NUM_CS   GPIO_NUM_22
                      ^~~~~~~~~~~
../../components/esp_common/include/esp_bit_defs.h:53:42: note: in definition of macro 'BIT'
 #define BIT(nr)                 (1UL << (nr))
                                          ^~
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:121:50: note: in expansion of macro 'PIN_NUM_CS'
     io_conf.pin_bit_mask = BIT(PIN_NUM_PD) | BIT(PIN_NUM_CS);
                                                  ^~~~~~~~~~
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:123:12: error: request for member 'pull_down_en' in something not a structure or union
     io_conf.pull_down_en = 0;
            ^
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:125:12: error: request for member 'pull_up_en' in something not a structure or union
     io_conf.pull_up_en = 0;
            ^
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:127:5: error: implicit declaration of function 'gpio_config'; did you mean 'lldesc_config'? [-Werror=implicit-function-declaration]
     gpio_config(&io_conf);
     ^~~~~~~~~~~
     lldesc_config
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c: In function 'MCU_CSlow':
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:140:5: error: implicit declaration of function 'gpio_set_level'; did you mean '_xtos_set_intlevel'? [-Werror=implicit-function-declaration]
     gpio_set_level(PIN_NUM_CS, 0);
     ^~~~~~~~~~~~~~
     _xtos_set_intlevel
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:76:22: error: 'GPIO_NUM_22' undeclared (first use in this function); did you mean 'PIN_NUM_PD'?
 #define PIN_NUM_CS   GPIO_NUM_22
                      ^~~~~~~~~~~
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:140:20: note: in expansion of macro 'PIN_NUM_CS'
     gpio_set_level(PIN_NUM_CS, 0);
                    ^~~~~~~~~~
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c: In function 'MCU_CShigh':
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:76:22: error: 'GPIO_NUM_22' undeclared (first use in this function); did you mean 'PIN_NUM_PD'?
 #define PIN_NUM_CS   GPIO_NUM_22
                      ^~~~~~~~~~~
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:146:20: note: in expansion of macro 'PIN_NUM_CS'
     gpio_set_level(PIN_NUM_CS, 1);
                    ^~~~~~~~~~
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c: In function 'MCU_PDlow':
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:78:22: error: 'GPIO_NUM_15' undeclared (first use in this function); did you mean 'PIN_NUM_PD'?
 #define PIN_NUM_PD   GPIO_NUM_15
                      ^~~~~~~~~~~
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:152:20: note: in expansion of macro 'PIN_NUM_PD'
     gpio_set_level(PIN_NUM_PD, 0);
                    ^~~~~~~~~~
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c: In function 'MCU_PDhigh':
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:78:22: error: 'GPIO_NUM_15' undeclared (first use in this function); did you mean 'PIN_NUM_PD'?
 #define PIN_NUM_PD   GPIO_NUM_15
                      ^~~~~~~~~~~
../lib/eve/eve_arch_esp32/EVE_MCU_ESP32.c:158:20: note: in expansion of macro 'PIN_NUM_PD'
     gpio_set_level(PIN_NUM_PD, 1);
                    ^~~~~~~~~~
cc1.exe: some warnings being treated as errors
[832/838] Building C object esp-idf/eve_arch_esp32/CMakeFiles/__idf_eve_arch_esp32.dir/__/source/EVE_HAL.c.obj
ninja: build stopped: subcommand failed.
ninja failed with exit code 1


Hi all,

I've just tested this AN on my ESP32 and I had the same errors (ESP IDF 4.0.1)
In order to get it compiled I changed the following in the code:

- in file EVE_MCU_ESP32.c I added:
Code: [Select]
#include "driver/gpio.h"
- in file edian.h I placed the following lines in remark in order to suppress the warnings about redefinition:
Code: [Select]
//#define __bswap16     __bswap_16
//#define __bswap32     __bswap_32

After changing this I successfully compiled and flashed my ESP32 and the demo works fine.
Luckily this AN exists because it would have been too much work to get started!
Thanks for this!

PS: I also had to change the EVE_config.h to add my 3.5 QVGA display.
Logged

BRT Community

  • Administrator
  • Hero Member
  • *****
  • Posts: 732
    • View Profile
Re: BRT_AN_025 Beta - Portable MCU library for EVE
« Reply #7 on: July 01, 2020, 03:46:07 PM »

Hello korstiaan,

Thank you for your comments, we have passed these on to the developer to update the files according for release.

Best Regards,
BRT Community
Logged

korstiaan

  • Newbie
  • *
  • Posts: 14
    • View Profile
BRT_AN_025 Beta - Recover from SLEEP
« Reply #8 on: August 23, 2020, 12:46:29 PM »

Hi,

I'm currently testing with the BT81X chip.
It all works fine BUT if my ESP32 restarts when the BT81X was in SLEEP mode, the program won't start and gets stuck at the first display list in the function EVE_Init(void).
So, it hangs in the
Code: [Select]
EVE_LIB_AwaitCoProEmpty
I solved it by adding the following code inside the HAL_EVE_Init(void) after HAL_ChipSelect(0) and before the // Reset the display

Code: [Select]
    // Set active, needed when ESP restarts when BT81X was in SLEEP mode
    HAL_HostCmdWrite(0, 0x00);
    MCU_Delay_500ms();

Now the startup works fine and does not block when the BT81X was in SLEEP mode before the ESP32 restart.
I do not understand why the reset display won't work or is it the good way, but by adding this it works.

Complete beginning now looks like:

Code: [Select]
void HAL_EVE_Init(void) {
    MCU_Init();

    // Set Chip Select OFF
    HAL_ChipSelect(0);

    // Set active, needed when ESP restarts when BT81X was in SLEEP mode
    HAL_HostCmdWrite(0, 0x00);
    MCU_Delay_500ms();

    // Reset the display
    MCU_Delay_20ms();
    HAL_PowerDown(1);
    MCU_Delay_20ms();
    HAL_PowerDown(0);
    MCU_Delay_20ms();

Logged

BRT Community

  • Administrator
  • Hero Member
  • *****
  • Posts: 732
    • View Profile
Re: BRT_AN_025 Beta - Portable MCU library for EVE
« Reply #9 on: August 24, 2020, 04:02:09 PM »

Hello,

Glad to hear you have found a suitable solution to the issue you were seeing!
We will keep this in mind for the full release of BRT_AN_025.

Best Regards,
BRT Community
Logged

korstiaan

  • Newbie
  • *
  • Posts: 14
    • View Profile
BT81x sometimes no reaction
« Reply #10 on: August 25, 2020, 01:14:02 PM »

Hi,

I 'm currently testing the library with a large display-list and now and then display gets stuck.
After further investigation it seems to block inside the EVE_LIB_AwaitCoProEmpty() -> HAL_WaitCmdFifoEmpty() function.

This is code where it gets stuck forever:

Code: [Select]
uint8_t HAL_WaitCmdFifoEmpty(void) {
    uint32_t readCmdPointer;

    // Wait until the two registers match
    do {
        // Read the graphics processor read pointer
        readCmdPointer = HAL_MemRead32(EVE_REG_CMD_READ);
    } while ((writeCmdPointer != readCmdPointer) && (readCmdPointer != 0xFFF));

    if (readCmdPointer == 0xFFF) {
        // Return 0xFF if an error occurred
        return 0xFF;
    } else {
        // Return 0 if pointers became equal successfully
        return 0;
    }
}

More specific, it gets stuck inside the do-while loop.

I'm sending very large display-lists (displaying QR-codes) and they take a while.

But any idea why it hangs there forever?
What is the good way to solve this?

For the moment I solved it like this:

Code: [Select]
uint8_t HAL_WaitCmdFifoEmpty(void) {
    uint32_t readCmdPointer;
    uint8_t retry = 0;

    // Wait until the two registers match
    do {
        // Read the graphics processor read pointer
        readCmdPointer = HAL_MemRead32(EVE_REG_CMD_READ);
        retry++;

    } while ((writeCmdPointer != readCmdPointer) && (readCmdPointer != 0xFFF) && (retry < 250));

    if (retry == 250) {
        printf("retry HAL_WaitCmdFifoEmpty");
    }

    if (readCmdPointer == 0xFFF) {
        // Return 0xFF if an error occurred
        return 0xFF;
    } else {
        // Return 0 if pointers became equal successfully
        return 0;
    }
}

I exit the loop if it takes to long.

Logged

Rudolph

  • Sr. Member
  • ****
  • Posts: 389
    • View Profile
Re: BRT_AN_025 Beta - Portable MCU library for EVE
« Reply #11 on: August 25, 2020, 08:48:35 PM »

You can not send more then 4k in one go and even if you send less than 4k you still need to keep
an eye on the resulting size of the display list itself.
Logged

BRT Community

  • Administrator
  • Hero Member
  • *****
  • Posts: 732
    • View Profile
Re: BRT_AN_025 Beta - Portable MCU library for EVE
« Reply #12 on: August 26, 2020, 03:38:15 PM »

Hello,

Rudolph is correct.

You should not edit the WaitCmdFifoEmpty() function to timeout as its intended purpose is to wait until the read and write pointers are equal, quitting out of this function early may result in unpredictable behaviour.

It is likely that there are issues with your Display List, you should ensure there is no Display List overrun in your code.
Best Regards,
BRT Community
Logged

korstiaan

  • Newbie
  • *
  • Posts: 14
    • View Profile
Re: BRT_AN_025 Beta - Portable MCU library for EVE
« Reply #13 on: August 27, 2020, 06:22:23 AM »

Hi,

Yes it is long (> 1000x EVE_VERTEX2F for drawing points) but is static, no changes.
At the end I always use EVE_LIB_AwaitCoProEmpty
It runs 4 times/sec. during sometimes more than 1hour ( > 14400 times) without any problem and then out of the blue it gets stuck inside this function?

What should I add and where to avoid this then?
Logged

Rudolph

  • Sr. Member
  • ****
  • Posts: 389
    • View Profile
Re: BRT_AN_025 Beta - Portable MCU library for EVE
« Reply #14 on: August 27, 2020, 01:16:19 PM »

Right now it looks like you are running into the problem that you are putting too much into the command-FIFO.

You have this:

EVE_LIB_BeginCoProList();
EVE_CMD_DLSTART();

all commands

EVE_DISPLAY();
EVE_CMD_SWAP();
EVE_LIB_EndCoProList();
EVE_LIB_AwaitCoProEmpty();

Try this:

EVE_LIB_BeginCoProList();
EVE_CMD_DLSTART();

first portion of commands

EVE_LIB_EndCoProList();
EVE_LIB_AwaitCoProEmpty();

EVE_LIB_BeginCoProList();

second portion of commands

EVE_DISPLAY();
EVE_CMD_SWAP();
EVE_LIB_EndCoProList();
EVE_LIB_AwaitCoProEmpty();

I am not actively using the MCU library from BRT_AN_025 but my own.
But I just tried this with the test programm I made a while back and it works,
it splits the display-list generation in two parts.

You still need to check the size of the display list that the command co-processor created from what is send to the command-FIFO.

Before you start a new list, read out REG_CMD_DL and then print this out somewhere in the new display list.
This is the size of the previously generated list.
If you are getting close to 8k, you have a problem.
« Last Edit: August 27, 2020, 01:33:23 PM by Rudolph »
Logged
Pages: [1] 2