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

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Rudolph

Pages: 1 2 3 [4] 5 6 ... 27
46
Discussion - EVE / Re: New Release of Windows to EVE Bitmap Viewer 1.4
« on: August 24, 2023, 10:14:58 PM »
This reminded me of your EVE-USB2SPI-KIT-B, are there plans to sell these thru DigiKey or Mouser and perhaps EVE4 series displays as well?
And I would like to buy an EVE4x-40G-IPS for my collection but shipping from Canada directly is a bit expensive while DigiKey and Mouser offer free shipping to EU and handling of the taxes beforehand.
Not asking for free shipping by Matrix Orbital, it's just so conveniant for me to order from Mouser or Digikey and I also can order a bag of other parts at the same time.
Most of my EVE2 and EVE3 series Matrix Orbital displays I ordered from Digikey or Mouser.

Edit:
Mouser is listing the EVE2-USB2SPI-KIT-B now, although there is no stock, yet.

47
Test and Review Area / Re: EVE Asset Builder 2.9.0
« on: August 20, 2023, 10:26:28 AM »
And something else entirely, as I am tinkering with ASTC fonts I noticed that EAB still includes astcenc.exe 2.1 while the latest release is 4.5.0.
I replaced the EVE Asset Builder\tools\astcenc.exe with the apropriate version for my system from the 4.5.0 package and so far it seems to be working fine, I still have to see what happens when using the converted fonts though.

48
Test and Review Area / EVE Asset Builder 2.9.0
« on: August 17, 2023, 06:02:33 PM »
I downloaded and installed EVE-Asset-Builder-setup-2.9_rc1.zip and I have an odd issue.

The button to open the explorer window to select the output folder is not working for me in "Asset Compressor" / "Compress".
When I use the button on the second tab "Validate" though it works, I can select the output folder, I have to confirm twice and
now the output folder is also changed on the "Compress" tab.

49
Discussion - EVE / Cake?
« on: August 15, 2023, 04:58:17 PM »
I just realized, it has been 10 years since the launch of the FT800.

50
Discussion - EVE / Re: Displaing an image from flash
« on: August 09, 2023, 04:41:51 PM »
I have a function that works fine for putting the attached flash in fast mode.
Check EVE_init_flash() from: https://github.com/RudolphRiedel/FT800-FT813/blob/5.x/EVE_commands.c
My EVE_cmd_flashfast() also is a bit different in that it does not only issue the command, it waits for completion, reads back
the return value from Eve and returns that value.

Quote
2. Does the flash need to be detached, attached back and then put into fast mode?

No, it does not, what I usually observe is that the status for the flash is "Basic" after initialization.

Quote
Can it not be put into fast mode straight after initialization (and eventually checked if is in basic mode)?

In my basic example I call my EVE_init(), set the backlight PWM, calibrate the touch.
Then I call EVE_init_flash() and if it returns E_OK, a .xfont file is read from the flash.
So yes, pretty much straight after initialization, at this point no images are loaded to RAM_G and only the initial empy display list is executed.

51
Please either try the last version I attached (and modify the pins if necessary), or attach a version with the modifications that you did, or well, preferably both. :-)

52
Ok, Arduino IDE 1.8.19 it is.
I swapped around the /AppData/Local/Arduino15 folders to make the 1.x one active.
Then I added https://espressif.github.io/arduino-esp32/package_esp32_index.json to "Addtional Boards Manager URLs" and installed the ESP32 package v2.09,
started IDE 1.8.19, opened the projected that is attached above, selected "DOIT ESP32 DEVKIT V1" since that worked with the ESP32 WROOM-32 board when using PlatformIO.
I changed the pins again:
Code: [Select]
#if !defined(EVE_CS)
#define EVE_CS 13
#endif

#if !defined(EVE_PDN)
#define EVE_PDN 12
#endif

#if !defined(EVE_SCK)
#define EVE_SCK 18
#endif

#if !defined(EVE_MISO)
#define EVE_MISO 19
#endif

#if !defined(EVE_MOSI)
#define EVE_MOSI 23
#endif

And it compiles just fine.
I can not get it to upload to the board though, something about the serial connection or the drivers not working.
On the serial monitor I get this though when pushing the reset button:
ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xe
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x0,hd_drv:0x00,wp_drv:0x0
mode:DIO, clock div:2
load:0x3fff0030,len:1184
load:0x40078000,len:13132
load:0x40080400,len:3036
entry 0x400805e4

And still:
A serial exception error occurred: Cannot configure port, something went wrong. Original message: PermissionError(13,
Note: This error originates from pySerial. It is likely not a problem with esptool, but with the hardware connection or drivers.

I hate it when crap like this happens.

For the chance that a different board might behave differently I am trying to buy a new ESP32 board.
But all the ESP32-WROVER boards I can find are using a CH340 USB/Serial chip like the Wroom32 board I already have.

Hmm, I had more boards but I can't find these anymore, like a ESP32-CAM but this one did not have USB at all.


Edit:
I got two new ESP32 boards and while one was advertised as "ESP32 WROVER Development Board" it turned out as WROOM32 board.
So I have two different new WROOM32 boards now.

My old WROOM32 board is still not working, same error, for whatever reason.
One of my new boards is using a CH340C, the other one is using a CP2102. I can upload to both of the new boards just fine.

And I learned something, never ever use "Sketch" / "Add File..." in Arduino IDE 1 in order to edit a file from a sub-folder that is otherwise not getting displayed.
I added EVE_target/EVE_target_Arduino_ESP32.h to change the pins.

And this opportunity to learn something did cost me a number of hours.
The seemingly exact same code worked fine when compiled with PlatformIO and resulted in a watchdog-reset when compiling it with Arduino IDE 1.8.19.
It hang in EVE_cpp_target.cpp / EVE_init_spi() when calling spi_bus_initialize().
And the problem in the end was that when adding the file the Arduino IDE actually copies it to the project folder.
I edited a copy of EVE_target_Arduino_ESP32.h that the code does not use while EVE_target/EVE_target_Arduino_ESP32.h remained untouched and therefore the I/O pins for the SPI were all wrong...ouch.

Now the code works from both the Arduino IDE 1.8.19 and PlatformIO with only a minute detail.
The code compiled with PlatformIO runs a little bit faster since I compile it with -O2 while the default is -Os.


And to my surprise, the Arduino version runs significantly faster now than the native version.
Using the same ESP-IDF based code.
It looks like the ESP-IDF SPI functions in arduino-esp32 are not the same, the pauses between single byte transfers when sending a couple of bytes are shorter.
The pauses are still ridiculously long for a controller running with 240MHz, I measure 9.9µs (PIO Arduino, -O2), 10.0µs (Arduino, -Os) and 13.2µs for (PIO ESP-IDF, -O2).
In contrast I measured 640ns with an ATSAMC21 running 48MHz and 280ns with an ATSAME51 running 120MHz but these are not burdened with a RTOS and my code writes directly to the SPI registers.

The screen update is done using DMA and while the transfer of the data takes the same 113.48µs, the times from CS down to start of the transfer and from end of the transfer to CS up are different.

CS down to start
Arduino: 20.3µs
ESP-IDF: 27.6µs
C21: 860ns

end of data to CS up
Arduino: 5µs
ESP-IDF: 8.4µs
C21: 780ns

I do wonder what is going on there with ESP32.

Another comparision, the 600MHz Teensy 4.1 has 225ns between two SPI.transfer() calls, so going thru the Arduino SPI class.


53
Hi,

I know that platformio it's better than arduino, but i'm used to work with arduino IDE.

I get you, but it is not so much platformio against arduino but using platformio to do arduino programing. :-)
For me this is not exactly about platformio either, more using platformio with vscode as vscode is a much better editor.
Platformio does a few things better than the arduino ide, like supporting more boards out of the box and allowing to set build flags for example.

On the other side there are limits to what you can do with platformio, like there is no Baremetall support for the RP2040, "only" Arduino,
the ATSAM I am mostly using do not have CMSIS/Baremetall support either in the "Atmel SAM" framework, "only" Arduino und Zyphr RTOS.
Next I have two newer STM32 Nucleo boards that I can not use with platformio, yet.
Then there is RX660, S32K, RH850, PIC, probably countless other controllers with no suport or limited support.
Just saying, I believe the gras is greener over here but it is not all green either. :-)

Quote
Trying to compile on Arduino IDE the "hello world" example for an ESP32 i cannot compile, i get theese errors on EVE_cpp_target.cpp, lines 232, 233, and 238. Compiler doesn't know "SPI2_HOST", so i've changed to "VSPI_HOST", and them another compiler error, compiler doesn't know "SPI_DMA_CH_AUTO", after investigating this value can be true or false. Wether i put true or false arduino compiles successfully the example, but after uploading to my Riverdi RiTFT50 it doesn't do anything, black screen.

Can you Rudolph help me to make it work?

Thnak you for your work and help.

Which ESP32 package are you using exactly in what version and with what Arduino IDE?

I checked platform-espressif32 and arduino-esp32.
This sounds like a compatibility issue between one using ESP-IDF 5 and the other using ESP-IDF 4.
However, the latest version of arduino-esp32 is v2.0.9 and it is using ESP-IDF v4.4.4.
And platform-espressif32 added support for arduino-esp32 v2.0.9 with release 6.3.0.
So this really should be the same arduino core that both are using.

Ok, lets see what happens, I am using Arduino IDE 2.1.0 since this is the one I currently have in working condition.
I added https://espressif.github.io/arduino-esp32/package_esp32_index.json to the boards manager and installed the esp32 package v2.0.9.

Ugh, ESP32 board overflow error. :-) First world problems, what board do I actually have? :-)

I selected "ESP32 Wrover Module" for a quick test and apart from a few warnings about missing initializers it compiles.
Fixed these.

I have a "BPI-Leaf-S3" that I only bought for the ESP-S3. And it actually is in the list of boards, nice.
With platformio I usually build for dfrobot_firebeetle2_esp32s3 which is close enough and also in the list.

Checking the pins, EVE_target_Arduino_ESP32.h has other pins configured as I have wired, so I just changed these.
EVE_target_Arduino_ESP32.h is not displayed by the Arduino IDE though since it is in a sub-folder, so you need to add it to the sketch.

Code: [Select]
...
#if !defined(EVE_CS)
#define EVE_CS 10
#endif

#if !defined(EVE_PDN)
#define EVE_PDN 14
#endif

#if !defined(EVE_SCK)
#define EVE_SCK 12
#endif

#if !defined(EVE_MISO)
#define EVE_MISO 13
#endif

#if !defined(EVE_MOSI)
#define EVE_MOSI 11
#endif
...

With platformio I can set these in the platformio.ini and therefore do not need to change that file.

Checking EVE_config.h, it's set to EVE_RVT50H which I also happen to have on my desk now.
The EVE_RiTFT50 is for RVT50xQBxxxxx which is using a BT815.
But I also happen to have one of these. :-)

Still compiles and now I uploaded it to the board - works. :-)

54
Discussion - EVE / Re: What is the purpose of CMD_REGREAD?
« on: May 30, 2023, 07:09:14 PM »
Hello,

Thanks for your feedback, yes we are going through the Programmers Guide to review the data types and we will update them where applicable. As you said, some of the signed/unsigned types are not the optimal ones.

Thank you, I will gladly remove a couple of casts then. :-)

Quote
For the CMD_REGREAD, sorry meant to also mention CMD_MEMWRITE in that reply. You could use the CMD_REGREAD and CMD_MEMWRITE so that you can do reads and writes with low latency between them.

Oh, CMD_MEMWRITE.
I implemented it, again as standalone command like I still have CMD_REGREAD.
And then I commented it out and tagged it as pointless.
I did not even get around implementing it with support for more than 4kiB of data.
Ok, I admit the low latency argument gives this command purpose, at least when using it with well below 4kiB of data.
But I still can not come up with any real use case, outside of perhaps testing the chip that is.
I like to make EVE cry, obviously. :-) But certainly not when doing an actual application.

55
Discussion - EVE / Re: What is the purpose of CMD_REGREAD?
« on: May 25, 2023, 08:19:13 PM »
As you said, in most application cases where the MCU wants to read or write, a standard SPI write would be most efficient.
There can be cases where it may be beneficial such as to reduce latency. e.g. if you want to do a read immediately after an operation which uses the co-processor, then waiting for the command to complete and then doing a SPI read would have more latency than adding a REGREAD command in your list of commands. For latency, one case may be reading the REG_CLOCK.

Ah, yes, thank you.
That is probably not something I will ever use but latency is a good argument.
Then I maybe should change how my function currently works as right now I have it implemented as stand-alone command.
And thinking about it, I would rather use CMD_MEMCPY to read some register as it can be anywhere in the list of commands.
CMD_REGREAD would be something for the end of the command-list since it writes to RAM_CMD and then you need to find out to where exactly.
As I am using REG_CMDB_WRITE (I dropped FT80x support), I am not keeping track of where in RAM_CMD EVE currently is,
so I could not even make my EVE_cmd_regread() function return the offset for reading out the value later.

Quote
You could also write many registers together even if not in adjacent registers (e.g. call CMD_PCLKFREQ and then write the display registers)

Yes - but what do you mean in context of CMD_REGREAD?

Quote
For RAM_JBOOT, this is not designed to be accessed from the host MCU directly and so should only be used with the recommended methods (such as the custom touch settings in the BT817 datasheet)

I am aware, but I still had to try out if using CMD_REGREAD is working differently in this region. :-)

Quote
Yes, we have implemented the commands in BRT_AN_025 directly and so they just add a dummy value which is replaced by the co-processor. We tend to use helper functions instead which then wrap those into more useful commands where you get the value back from the function (via return or pointer). We will look at adding some more of the EVE_LIB functions as helpers in the examples which we are producing for BRT_AN_025 to make these easier to use though, and so thanks for your feedback on this point.

I also find the documentation for these odd, or rather the given C function prototypes.

I implented
void EVE_cmd_fontcachequery(uint32_t *p_total, int32_t *p_used);
and not
void cmd_fontcachequery( uint32_t total, int32_t used );

My function does not write the values to RAM_CMD, it writes two 0UL and then reads from RAM_CMD and
writes back the retreived values if the pointers are not NULL.

Additionally, using "int32_t" for "used" does not seem to make any sense here.
Even your own example code agrees with me on this:

Code: [Select]
uint32_t total, used;
uint16_t ram_fifo_offset = rd16(REG_CMD_WRITE);
cmd_fontachequery(total, used);
total = rd32(RAM_CMD + (ram_fifo_offset + 4) % 4096);
used = rd32(RAM_CMD + (ram_fifo_offset + 8) % 4096);

It should not be possible for "used" to ever have a negative value.

Please review every single signed parameter and change it to unsigned when applicable. :-)
I wrote this at least once before in some other post here, a signed radius parameter for CMD_CLOCK makes no sense and there are likely more examples to be found.

56
Discussion - EVE / What is the purpose of CMD_REGREAD?
« on: May 21, 2023, 03:49:32 PM »
What is CMD_REGREAD supposed to be used for?
It does not seem to have any use when building a display-list and outside of display list handling it is more efficient to read from the address directly.

I am playing with EVE_cmd_regread() and EVE_memRead32() on a BT817 - the results are the same for the most part.

Code: [Select]
for(uint8_t index=0; index < 32; index++)
{
    test1[index] = EVE_cmd_regread(0x302000UL + (index*4));
    test2[index] = EVE_memRead32(0x302000UL + (index*4));
}

Some of the not documented registers seem to be pretty usefull, like 0x3021A8UL + 0x3021ACUL, I wonder why these are not documented.
Reading from the not documented REG_DATESTAMP returned a string: "2019-10-28_2.5.3"
Reading from for example 0x303000 returns 0xdeadbeef.
Reading from 0x309218 returns 3, whatever that means. :-)

Reading from RAM_JTBOOT (0x30b000) is returning inconsistent results between EVE_cmd_regread() and EVE_memRead32(), not like EVE_cmd_regread() is executed with higher privilege, more like what is returned for this memory region is not actually accessible for both functions.

The region from 0x309000 to 0x30914e has a few documented registers like REG_TRACKER and REG_FLASH_SIZE,
it is not mentioned in the memory map though, "Table 5-1 BT817/8 Memory Map".


I also had a look at the code for BRT_AN_025.
The functions EVE_CMD_REGREAD(), EVE_CMD_GETPROPS(), EVE_CMD_FONTCACHEQUERY(), EVE_CMD_GETIMAGE() and EVE_CMD_GETPTR()
are not implemented to do anything usefull and all these write out the parameters to EVE that are return parameters.
There is EVE_LIB_GetProps() though.

EVE_CMD_PCLKFREQ() does write the parameter "factual" although this is a return parameter.
EVE_CMD_FLASHFAST() does write the parameter "result" although this is a return parameter.
EVE_CMD_MEMCRC() does write the parameter "result" although this is a return parameter.

57
Discussion - EVE / Re: CMD_PCLKFREQ requires the flash BLOB?
« on: May 18, 2023, 11:49:42 AM »
Hi Rudolph,
Thanks for your detailed information, we will review your feedback,
Yes, the main difference is that having the BLOB and Flash in full speed prevents the command from setting a value which exceeds the spec of the PLL frequency. Without these it may set a value which exceeds the allowable spec and so may affect reliable operation.

Best Regards, BRT Community

Thank you for the confirmation!
As I wrote, I never encountered the issue but at the very least my code is running more robust now after I changed it to not use CMD_PLKFREQ anymore.
Not that CMD_PLKFREQ is not working, but as I provide a library for anyone to use I can not rely on the content of an external flash that might not even be there.
I do not even have flash initialization in my init function so it can be done if required.

58
Discussion - EVE / Re: CMD_PCLKFREQ requires the flash BLOB?
« on: May 18, 2023, 09:29:04 AM »
I have a BT817 from Riverd like that you refer to, so far it has worked very well with the GDSTx library in teensy 4.1.

I strongly disagree with the "very well" for the Gameduino library and would call that barely working.
That is my low-level assessment from what is actually going on with the SPI.

Quote
In order to experiment with that situation that you mention,

What situation?
My post is a question to Bridgetek regarding the claim in the programming guide that CMD_PLKFREQ needs the flash BLOB to be in place while in my experience it works fine with a completely empty external flash.
These are the first 15 lines.

The rest of my post is information regarding how REG_PCLK_FREQ works in the BT817/BT818 now plus a suggestion on how to improve it for a future device.


Quote
you will have a guide on how to use your library in the arduino ide environment (preferably 1.8.19, since 2 seems to me to be an unfinished job and with many errors still), wiring, and what extra device is required to be able to use the onboard flash memory that the display has?

While I do support Arduino in general, I do not support the "IDE, there are good reasons why large Arduino projects like Marlin are developed with PlatformIO.
Regardless, attached is a "HelloWorld" example that I have up and running for the Teensy 4.1 board and a RVT50HQBNWC00-B.
And it compiles for the UNO as well.

Here is what I did to make this work:
- created a folder "EVE_HelloWorld_Arduino_IDE"
- copied "EVE_Test.cpp" from https://github.com/RudolphRiedel/FT800-FT813/tree/5.x/examples/EVE_HelloWorld_Arduino_PlatformIO
- renamed "EVE_Test.cpp" to "EVE_HelloWorld_Arduino_IDE.ino"
- copied all files from https://github.com/RudolphRiedel/FT800-FT813/tree/5.x
- copied a couple of "EVE_target_Arduino_xxx.h" files from https://github.com/RudolphRiedel/FT800-FT813/tree/5.x/EVE_target
- modified EVE_target.h: "#include "EVE_target/EVE_target" -> "#include "EVE_target"
- modifed EVE_config.h by adding a "#define EVE_RVT50H"

For Arduino IDE 2.x fewer steps should be necessary.

The pinout for the Teensy 4.1 is SPI default:
SCK 13
MISO 12
MOSI 11

The CS and PD pins are defined in EVE_target_Arduino_Teensy4.h:
#define EVE_CS 10
#define EVE_PDN 9

There is not much in the .ino but this would for example support DMA transfers on the Teensy 4 with two more lines.

Ok, one more.

- created a folder "EVE_Test_Arduino_IDE"
- copied all the files from "EVE_HelloWorld_Arduino_IDE", except "EVE_HelloWorld_Arduino_IDE.ino"
- copied the files from https://github.com/RudolphRiedel/FT800-FT813/tree/5.x/examples/EVE_Test_Arduino_PlatformIO/src
- renamed "EVE_Test.cpp" to "EVE_Test_Arduino_IDE.ino"

This now runs my basic example code that I use for all the examples, the display code is in "tft.c".
It runs with 50 frames per second and only needs 3µs for the display update on the Teensy 4.1 as DMA is used.

There is a test for the external flash included in this but it is deactivated by default.
At the top of "tft.c" there is this:
#define TEST_UTF8 0

Change this to:
#define TEST_UTF8 1

In TFT_init() you find this:
Code: [Select]
#if (TEST_UTF8 != 0) && (EVE_GEN > 2)   /* we need a BT81x for this */
    #if 0
        /* this is only needed once to transfer the flash-image to the external flash */
        uint32_t datasize;

        EVE_cmd_inflate(0, flash, sizeof(flash)); /* de-compress flash-image to RAM_G */
        datasize = EVE_cmd_getptr(); /* we unpacked to RAM_G address 0x0000, so the first address after the unpacked data also is the size */
        EVE_cmd_flashupdate(0,0,4096); /* write blob first */
        if (E_OK == EVE_init_flash())
        {
            EVE_cmd_flashupdate(0,0,(datasize|4095)+1); /* size must be a multiple of 4096, so set the lower 12 bits and add 1 */
        }
    #endif

    if (E_OK == EVE_init_flash())
    {
        EVE_cmd_flashread(MEM_FONT, 61376, 320); /* copy .xfont from FLASH to RAM_G, offset and length are from the .map file */
    }

#endif /* TEST_UTF8 */


That "#if 0" needs to be changed to "#if 1" to write a flash image with an UTF-8 font to the external flash of the module.
Let it run once and change it back to "#if 0".

The top line of the screen that reads "EVE Demo" is displayed with the UTF-8 font from the external flash.


Edit: I changed an include line in the EVE_target_Arduino_xxx.h files to make the whole process less complicated.

Now if there would be a way to set defines globally with the Arduino IDE it would not even be necessary to change EVE_config.h and the pins defined in the target files could be changed as well without changing the target files.

I tested this with Arduino 1.8.19 and 2.1.0 now.
Installing 2.1.0 and switching between these is painfull though with Teensy. I had to rename ../Appdata/Local/Arduino15 first or otherwise 2.1.0 would not even start. And starting 1.8.19 with the new folder offers no Teensy option when it is installed for 2.1.0.
Attached are slightly modified archives with the target headers in their sub-folder and EVE_target.h not modified.

Edit2: just noticed that I left the UTF-8 test active with the flashing inactive, changed tft.c to the original version

59
Discussion - EVE / Re: 1.2V regulator quiescent current draw
« on: May 04, 2023, 10:36:53 PM »
I believe that table is not incorrect, but a bit misleading.
I believe this desribes ranges around 1.8V, 2.5V and 3.3V for all VCCIOn voltages.
I do wonder why this is structured as it is, why isn't the voltage range just from 1.62V to 3.6V?

60
Discussion - EVE / CMD_CLEARCACHE with not empty display list
« on: April 27, 2023, 09:56:08 PM »
I am experimenting with making EVE cry in order to test recovering from co-processor faults.

And this might be one for the Bridgetek bug-tracker.
It takes over 12ms from issuing CMD_CLEARCACHE to getting a co-processor fault.
When reading REG_CMDB_SPACE 12ms after CMD_CLEARCACHE is done the result is 0x0FF8.
When reading REG_CMDB_SPACE 13ms after CMD_CLEARCACHE is done the result is 0x0FC3.

In contrast I am getting a co-processor fault after 20µs when issuing EVE_cmd_setscratch(43), did not check how fast actually.

I do not have an issue with CMD_CLEARCACHE, for one it is documented that the display list needs to be empty, my function EVE_cmd_clearcache() clears out both of the display list before issuing CMD_CLEARCACHE and then I can not recall that I ever used this command.
I just found this peculiar and perhaps this is something worth looking into.

Pages: 1 2 3 [4] 5 6 ... 27