16
Discussion - EVE / Re: Using flash for bitmaps
« on: February 20, 2024, 03:44:06 PM »
Have you fixed your alignment? The flash destination address that you posted in the other thread was not a multiple of 4096.
- May 04, 2024, 09:18:29 AM
- Welcome, Guest
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.
17
Discussion - EVE / Re: How often and when read REG_TOUCH_TAG
« on: February 10, 2024, 09:48:08 PM »
My code usually checks for touch events every 5ms and that function does three reads now.
Reading REG_CMDB_SPACE to check if EVE is still busy from the display refresh or if there was a co-processor fault.
Reading REG_CMD_DL as a debug measure to get the size of the last generated display-list.
Reading REG_TOUCH_TAG.
I just did an experiment with a Teensy 4.1 under Arduino as this was wired up to the logic analyzer.
The SPI clock is 16MHz.
I moved out the function call to check for touch events that I placed in the loop() function to outside
the code that checks that 5ms passed.
And all that happens is that I can see with the logic analyzer that the SPI is flooded.
The REG_TOUCH_TAG is read every 12µs.
Now I commented out the reading of REG_CMD_DL which means that REG_TOUCH_TAG is read every 8µs.
Ok, I can get away with not reading REG_CMDB_SPACE since I have an internal flag for the DMA transfer of the display update.
And reading REG_TOUCH_TAG does not interfere with the co-processor.
Now the logic-analyzer traces shows reads of REG_TOUCH_TAG about every 3.6µs.
And the EVE3-50G module which has a BT815 and a GT911 is just fine.
No crash and the touch still works fine.
So no, there does not appear to be a limit on how often REG_TOUCH_TAG can be read.
My display update is every 20ms though, so it really does not help to read the register >5400 times in between. :-)
My main loop does this now, 5ms per step:
read read read display read read read display
And there probably would not be a noticeable difference if I changed that to >read / display< with 10ms steps.
Hmm, I wonder now how long touch events actually are, or rather how short these can get.
I went back to reading REG_TOUCH_TAG every 12µs and added a counter that is set to 1 on registering the touch of a button and gets increased as long as the button is touched.
And I can not get this time realiably below 3000.
Right now the number is 1142 which meant I managed to touch the button for only 13ms.
2161 - 28ms
976 - 12ms
2138
3298
4417
3275
3304
2156
Going back to 5ms timeslots I can not get the counter lower than 3.
And not trying to touch as fast as possible I get closer to 20.
So I guess it is ok to assume that the duration of touch events is at least 10ms.
Reading REG_CMDB_SPACE to check if EVE is still busy from the display refresh or if there was a co-processor fault.
Reading REG_CMD_DL as a debug measure to get the size of the last generated display-list.
Reading REG_TOUCH_TAG.
I just did an experiment with a Teensy 4.1 under Arduino as this was wired up to the logic analyzer.
The SPI clock is 16MHz.
I moved out the function call to check for touch events that I placed in the loop() function to outside
the code that checks that 5ms passed.
And all that happens is that I can see with the logic analyzer that the SPI is flooded.
The REG_TOUCH_TAG is read every 12µs.
Now I commented out the reading of REG_CMD_DL which means that REG_TOUCH_TAG is read every 8µs.
Ok, I can get away with not reading REG_CMDB_SPACE since I have an internal flag for the DMA transfer of the display update.
And reading REG_TOUCH_TAG does not interfere with the co-processor.
Now the logic-analyzer traces shows reads of REG_TOUCH_TAG about every 3.6µs.
And the EVE3-50G module which has a BT815 and a GT911 is just fine.
No crash and the touch still works fine.
So no, there does not appear to be a limit on how often REG_TOUCH_TAG can be read.
My display update is every 20ms though, so it really does not help to read the register >5400 times in between. :-)
My main loop does this now, 5ms per step:
read read read display read read read display
And there probably would not be a noticeable difference if I changed that to >read / display< with 10ms steps.
Hmm, I wonder now how long touch events actually are, or rather how short these can get.
I went back to reading REG_TOUCH_TAG every 12µs and added a counter that is set to 1 on registering the touch of a button and gets increased as long as the button is touched.
And I can not get this time realiably below 3000.
Right now the number is 1142 which meant I managed to touch the button for only 13ms.
2161 - 28ms
976 - 12ms
2138
3298
4417
3275
3304
2156
Going back to 5ms timeslots I can not get the counter lower than 3.
And not trying to touch as fast as possible I get closer to 20.
So I guess it is ok to assume that the duration of touch events is at least 10ms.
18
Discussion - EVE / Re: Modularly load ASTC images
« on: February 02, 2024, 09:16:53 AM »
I have a working implementation of CMD_FLASHUPDATE that you can compare against.
The mentioned alignment requirements are strict, EVE does nothing if these are not met.
That "the program crashes" is not something I would expect from incorrect alignment though.
The mentioned alignment requirements are strict, EVE does nothing if these are not met.
That "the program crashes" is not something I would expect from incorrect alignment though.
19
Discussion - MCU / Re: STM32CubeIDE EVE4 Library Integration
« on: January 26, 2024, 06:10:49 PM »
LL_SPI_Enable() should be at the end of MX_SPI1_Init() in main.c.
I just checked what STM32CubeIDE is generating for me and I also do not have this line,
whatever the idea behind fully configuring a unit and then not activating it in the end is.
Well, STM32CubeIDE, I still have the Code that it generated for the STM32G0B1CET6, took me a bit to find out that the
generated MX_SPI1_Init() neither activated the clock or configured the SPI pins.
And the one working version I have in the other folder has __HAL_SPI_ENABLE(&hspi1); at the end, the generated one does not.
If only you had pick one of the few STM32 controllers I have a Nucleo board with here... :-)
I just checked what STM32CubeIDE is generating for me and I also do not have this line,
whatever the idea behind fully configuring a unit and then not activating it in the end is.
Well, STM32CubeIDE, I still have the Code that it generated for the STM32G0B1CET6, took me a bit to find out that the
generated MX_SPI1_Init() neither activated the clock or configured the SPI pins.
And the one working version I have in the other folder has __HAL_SPI_ENABLE(&hspi1); at the end, the generated one does not.
If only you had pick one of the few STM32 controllers I have a Nucleo board with here... :-)
20
Discussion - EVE / Re: Can BT815 determine the Touch-Controller Type by itself?
« on: January 25, 2024, 07:19:52 PM »
Well, I guess I can measure the time the touch engine needs during startup, my init already waits for REG_CPURESET going to Zero anyways.
I have no solid idea yet on what to name a function that asks for this information though.
Something like EVE_touch_engine_?
() which returns E_OK when a counter was lower than perhaps 10 and
something like E_CTPM_MISMATCH when that counter was above 10.
I have no idea what happens with resistive touch, I am not even sure if I have a FT81x / BT81x module with resistive touch.
Should be a rather short delay as well.
Suggestions?
I have no solid idea yet on what to name a function that asks for this information though.
Something like EVE_touch_engine_?
() which returns E_OK when a counter was lower than perhaps 10 andsomething like E_CTPM_MISMATCH when that counter was above 10.
I have no idea what happens with resistive touch, I am not even sure if I have a FT81x / BT81x module with resistive touch.
Should be a rather short delay as well.
Suggestions?
21
Discussion - MCU / Re: STM32CubeIDE EVE4 Library Integration
« on: January 25, 2024, 06:46:07 PM »
That might be the clock configuration.
But I can't explain that so easily.
I opened the clocktree and just closed it again. :-)
But I can't explain that so easily.
I opened the clocktree and just closed it again. :-)
22
Discussion - MCU / Re: STM32CubeIDE EVE4 Library Integration
« on: January 24, 2024, 06:06:56 PM »
I am not really working with STM32, but my Workspace in STM32CubeIDE is not empty. :-)
Setting up a project for the STM32Wb55RG revealed that my passwort on www.st.com had expired...
Oh, I also still did not implement DMA suppport.
Anyways, I started a new project with the NUCLEO-WB55RG and configured SPI1:
PA5 = SPI1_SCK
PA6 = SPI1_MISO
PA7 = SPI1_MOSI
And two GPIO-Outputs, PA3 and PA4.
I set the driver for SPI and GPIO to "LL".
I have no idea though to what the clocks are configured.
The SPI needs to be (at least initially) set to 11MHz or less.
The code is generated and the project builds.
Now I opened the project in the file explorer and went into /Core/Src/.
I created a folder "EmbeddedVideoEngine" and copied over the files from my library.
The folder EVE_target only needs to have the file EVE_target_STM32.h .
In the "examples" folder are several copies of "tfc.c", "tft.h", "tft_data.c" and "tft_data.h", for the most part these are all the same but the ones
in the "...PlatformIo" folders do not have the "EmbeddedVideoEngine" in the include for "EVE.h".
So I used the files from examples\EVE_Test_SAMC21_EVE2-50G\ and copied them to /Core/Src/.
Refreshing the project in STM32CubeIDE and the files show up.
Building the project fails however, the first error here is:
../Core/Src/EmbeddedVideoEngine/EVE_commands.c:3037:36: error: unknown type name 'int16_t'
And the reason is, my library does not know what a STM32WB is, yet.
Checking the properties/"C/C++ Build"/Settings/MCU GCC Compiler/Preprocessor, there is the symbol "STM32WB55xx" defined.
So the first thing to do is to add this symbol to EVE_target.h so that EVE_target_STM32.h gets included.
And now EVE_target_STM32.h needs to be expanded to load the correct includes:
Building the project again, it still fails, but now the error is:
#error "Please add a define for the desired display to your build-environment, e.g. -DEVE_EVE3_50G"
So there is no display selected.
Back to the properties I added a new symbol: "EVE_EVE3_50G".
-> 18:57:17 Build Finished. 0 errors, 0 warnings. (took 1s.755ms)
In EVE_target_STM32.h also is the configuration for the CS and PD pins as well the SPI to use:
Nice coincidence, I already setup PA3 and PA4 as outputs and selected SPI1. :-)
And I just uploaded the modified EVE_target.h and EVE_target_STM32.h to Github.
But the project won't display anything so far.
So now main.c needs to be modified:
This should at least display one frame.
Usually I would put this in the endless loop, together with the TFT_touch() function from the example.
But the default main.c from STM32CubeIDE does not have even a primitive scheduler and while there is a SysTick_Handler(),
I am not sure to what tick it is configured.
Normally I would go for 5ms ticks, execute TFT_display() every 20ms and execute TFT_touch() every 5ms when TFT_display()
is not executed.
But well, my job was done when it compiled. :-)
Setting up a project for the STM32Wb55RG revealed that my passwort on www.st.com had expired...
Oh, I also still did not implement DMA suppport.
Anyways, I started a new project with the NUCLEO-WB55RG and configured SPI1:
PA5 = SPI1_SCK
PA6 = SPI1_MISO
PA7 = SPI1_MOSI
And two GPIO-Outputs, PA3 and PA4.
I set the driver for SPI and GPIO to "LL".
I have no idea though to what the clocks are configured.
The SPI needs to be (at least initially) set to 11MHz or less.
The code is generated and the project builds.
Now I opened the project in the file explorer and went into /Core/Src/.
I created a folder "EmbeddedVideoEngine" and copied over the files from my library.
The folder EVE_target only needs to have the file EVE_target_STM32.h .
In the "examples" folder are several copies of "tfc.c", "tft.h", "tft_data.c" and "tft_data.h", for the most part these are all the same but the ones
in the "...PlatformIo" folders do not have the "EmbeddedVideoEngine" in the include for "EVE.h".
So I used the files from examples\EVE_Test_SAMC21_EVE2-50G\ and copied them to /Core/Src/.
Refreshing the project in STM32CubeIDE and the files show up.
Building the project fails however, the first error here is:
../Core/Src/EmbeddedVideoEngine/EVE_commands.c:3037:36: error: unknown type name 'int16_t'
And the reason is, my library does not know what a STM32WB is, yet.
Checking the properties/"C/C++ Build"/Settings/MCU GCC Compiler/Preprocessor, there is the symbol "STM32WB55xx" defined.
So the first thing to do is to add this symbol to EVE_target.h so that EVE_target_STM32.h gets included.
And now EVE_target_STM32.h needs to be expanded to load the correct includes:
Code: [Select]
#if defined (STM32WB55xx) /* set with "build_flags = -D STM32WB55xx" in platformio.ini */
#include "stm32wbxx.h"
#include "stm32wbxx_hal.h"
#include "stm32wbxx_ll_spi.h"
#endif
Building the project again, it still fails, but now the error is:
#error "Please add a define for the desired display to your build-environment, e.g. -DEVE_EVE3_50G"
So there is no display selected.
Back to the properties I added a new symbol: "EVE_EVE3_50G".
-> 18:57:17 Build Finished. 0 errors, 0 warnings. (took 1s.755ms)
In EVE_target_STM32.h also is the configuration for the CS and PD pins as well the SPI to use:
Code: [Select]
#if !defined (EVE_CS)
#define EVE_CS_PORT GPIOA
#define EVE_CS GPIO_PIN_4
#endif
#if !defined (EVE_PDN)
#define EVE_PDN_PORT GPIOA
#define EVE_PDN GPIO_PIN_3
#endif
#if !defined (EVE_SPI)
#define EVE_SPI SPI1
#endif
Nice coincidence, I already setup PA3 and PA4 as outputs and selected SPI1. :-)
And I just uploaded the modified EVE_target.h and EVE_target_STM32.h to Github.
But the project won't display anything so far.
So now main.c needs to be modified:
Code: [Select]
/* USER CODE BEGIN Includes */
#include "tft.h"
/* USER CODE END Includes */
Code: [Select]
int main(void)
{
...
/* Initialize all configured peripherals */
MX_GPIO_Init();
MX_SPI1_Init();
/* USER CODE BEGIN 2 */
TFT_init();
TFT_display();
/* USER CODE END 2 */
/* Infinite loop */
/* USER CODE BEGIN WHILE */
while (1)
{
/* USER CODE END WHILE */
/* USER CODE BEGIN 3 */
}
/* USER CODE END 3 */
}
This should at least display one frame.
Usually I would put this in the endless loop, together with the TFT_touch() function from the example.
But the default main.c from STM32CubeIDE does not have even a primitive scheduler and while there is a SysTick_Handler(),
I am not sure to what tick it is configured.
Normally I would go for 5ms ticks, execute TFT_display() every 20ms and execute TFT_touch() every 5ms when TFT_display()
is not executed.
But well, my job was done when it compiled. :-)
23
Discussion - EVE / Re: Can BT815 determine the Touch-Controller Type by itself?
« on: January 23, 2024, 06:23:05 PM »
I really meant how to reset EVEs touch engine and not the CTPM.
It does not seem to reset when writing a 2 to REG_CPURESET or at least there is no delay between writing 0 to REG_CPURESET and reading back 0 from REG_CPURESET.
And I tried to just write 2 to REG_CPURESET - it does not return to 0.
It does not seem to reset when writing a 2 to REG_CPURESET or at least there is no delay between writing 0 to REG_CPURESET and reading back 0 from REG_CPURESET.
And I tried to just write 2 to REG_CPURESET - it does not return to 0.
24
Discussion - EVE / Re: Can BT815 determine the Touch-Controller Type by itself?
« on: January 22, 2024, 07:17:13 PM »
I had an idea to find out which CTPM is attached, but it is not working.
It should take longer to reset when REG_TOUCH_CONFIG is set to 0x0380 for Focaltech but a Goodix CTPM is connected.
EVE_memWrite8(REG_CPURESET, 2U); /* reset touch controller */
// EVE_memWrite16(REG_TOUCH_CONFIG, 0x05d0U); /* switch to Goodix CTPM */
EVE_memWrite16(REG_TOUCH_CONFIG, 0x0380); /* switch to Focaltech CTPM */
EVE_memWrite8(REG_CPURESET, 0U); /* clear all resets */
EVE_memRead8(REG_CPURESET);
Checking back with the logic-analyzer, this first read results in 0x00 already.
At 400kHz it takes at least 25µs to get the first ACK from an I2C chip.
From writing REG_CPURESET to reading it back my code needs less than 10µs,
so the touch controller is not actually resetting.
Well, I noticed that the touch-controller takes longer to come out of reset on power-up.
I modified my startup code to immediately read REG_CPURESET after REG_ID returned 0x7c
and to read REG_CPURESET with no pause over and over again untill it reads 0x00.
RVT50HQBNWC00-B with ILI2132A: ~50µs
EVE3-50G with GT911: ~9ms (touch controller not found on power-up)
So that really looks like a way to check if the expected CTPM is connected.
But how is the touch controller convinced to actually do a reset if writing 0x02 to REG_CPURESET does not work?
It should take longer to reset when REG_TOUCH_CONFIG is set to 0x0380 for Focaltech but a Goodix CTPM is connected.
EVE_memWrite8(REG_CPURESET, 2U); /* reset touch controller */
// EVE_memWrite16(REG_TOUCH_CONFIG, 0x05d0U); /* switch to Goodix CTPM */
EVE_memWrite16(REG_TOUCH_CONFIG, 0x0380); /* switch to Focaltech CTPM */
EVE_memWrite8(REG_CPURESET, 0U); /* clear all resets */
EVE_memRead8(REG_CPURESET);
Checking back with the logic-analyzer, this first read results in 0x00 already.
At 400kHz it takes at least 25µs to get the first ACK from an I2C chip.
From writing REG_CPURESET to reading it back my code needs less than 10µs,
so the touch controller is not actually resetting.
Well, I noticed that the touch-controller takes longer to come out of reset on power-up.
I modified my startup code to immediately read REG_CPURESET after REG_ID returned 0x7c
and to read REG_CPURESET with no pause over and over again untill it reads 0x00.
RVT50HQBNWC00-B with ILI2132A: ~50µs
EVE3-50G with GT911: ~9ms (touch controller not found on power-up)
So that really looks like a way to check if the expected CTPM is connected.
But how is the touch controller convinced to actually do a reset if writing 0x02 to REG_CPURESET does not work?
25
Discussion - EVE / Re: Graphics engine freezing
« on: January 18, 2024, 09:14:52 PM »They noted the following:QuoteIf the DL itself contains an infinite loop, then there is the potential for this to happen.
An infinite loop could be caused by a JUMP /CALL instruction, or if the display list contains no DISPLAY instruction.
It is also worth verifying any direct writes to RAM_DL as there is a possibility of errors occurring here and not being caught by the co-processor.
I have no JUMP / CALL instructions in my display list, DISPLAY is always my last command before CMD_SWAP and I never write to RAM_DL.
Maybe I am pushing a bit too hard, but not hard enough to actually break things.
I increased the time between display updates from 20ms to 25ms and after a while now the counter still sits at zero.
The frame rate for the panel is 73.89Hz.
26
Discussion - EVE / Re: Reading Tag vs External Clock
« on: January 16, 2024, 04:41:48 PM »
There is no CLKINT command in the BT81x, it has been removed from the datasheet.
So there is a good chance that it does not work reliably if it works at all.
That said, I have a RVT70HSBNWC00 and the touch is fine when using CLKEXT without special provisions.
Are your logic and backlight supplies stable and provide enough current?
Really? Even in the moment when you switch on the backlight?
Have you tried calibrating it?
Have you tried reading REG_TOUCH_RAW_XY?
So there is a good chance that it does not work reliably if it works at all.
That said, I have a RVT70HSBNWC00 and the touch is fine when using CLKEXT without special provisions.
Are your logic and backlight supplies stable and provide enough current?
Really? Even in the moment when you switch on the backlight?
Have you tried calibrating it?
Have you tried reading REG_TOUCH_RAW_XY?
27
Discussion - EVE / Re: Graphics engine freezing
« on: January 13, 2024, 11:32:05 AM »
With adding even more stuff to my playground software I get higher error counts, with the display still up and running, reacting to touch.
Right now I see "Faults: 0 109" and this is after several minutes.
I don't know what the actual issue is with REG_DLSWAP not returning to 0 occasionally.
At 50 frames per second it is unlikely that this is an issue with my display list, the update runs through hundreds if not thausands of frames with no issue at all and then I blink and the counter is a increased a little.
And when I happen to observe the counter to increase there is no noticeable glitch, I can't even tell that it is skipping a frame.
I am not using the external flash right now and have this running on a BT815 based display with 800x480.
My buffer sits at 3721 bytes to be transferred over the SPI with DMA, this results in a display list that is 5116 bytes long.
I am using an ESP32-WROOM32 with ESP-IDF and the SPI is running at 16MHz for the display update, reading from the SPI is done with 10MHz.
I just removed the "return" from my REG_DLSWAP test and added saving and displaying the value that is not zero:
I expected a failure when removing the "return" but it just keeps running.
And so far the only value that is returned from REG_DLSWAP is 2.
I modified the code to read REG_DLSWAP a second and a third time if the first read was not zero.
And displayed is:
Faults: 0 118
DL_SWAP: 2 0 0
Faults: 0 134
DL_SWAP: 2 2 2
I also observed
DL_SWAP: 2 2 0
I slowed down the SPI for reading the register to 4MHz and I am still seeing this.
Faults: 0 15
DL_SWAP: 2 0 0
So this is unlikely to be a glitch from reading the register and if it were there should be other values than just 0 and 2.
I reduced the speed for the display update down to 8MHz and counter still gets increased eventually.
I still don't know what this actually is, but so far it looks like the issue is with REG_DLSWAP in the BT815.
It sure looks like REG_DLSWAP is not always getting updated properly.
Faults: 0 262
DL_SWAP: 2 0 0
Faults: 0 347
DL_SWAP: 2 0 0
Faults: 0 354
DL_SWAP: 2 2 2
Faults: 0 411
DL_SWAP: 2 2 2
Faults: 0 435
DL_SWAP: 2 2 0
Faults: 0 439
DL_SWAP: 2 2 0
Faults: 0 531
DL_SWAP: 2 2 2
Faults: 0 537
DL_SWAP: 2 2 0
Faults: 0 616
DL_SWAP: 2 2 2
Odd.
It took a while to get there and it still keeps running with no issue.
And it is not constantly counting up, the value is stable for several seconds, then it ticks up
erratically untill it is stable again.
Faults: 0 702
DL_SWAP: 2 0 0
Faults: 0 783
DL_SWAP: 2 2 0
...
Faults: 0 3460
DL_SWAP: 2 0 0
....
And some readings several hours later:
Faults: 0 14407
DL_SWAP: 2 0 0
Faults: 0 14505
DL_SWAP: 2 2 2
Still going with no issue.
Time to switch to a different controller, the ESP32 is running too much software I have no control over.
Using the same display module and the same FFC I switched to one of my own boards that has an ATSAME51J19A clocked 80MHz.
The display loop is exactly the same, only the hardware abstraction changed for the SPI.
I directly went for 20MHz SPI clock after init.
The touch works just fine, so reading from EVE is not affected, usually this is the first to fail.
The "issue" is the same, REG_DLSWAP occasionally remains at 2 although EVE has about 17ms time to swap in the new display list after one
transfer is done before the next update is started.
And ignoring this does not stop the display from running.
Faults: 0 208
DL_SWAP: 2 2 2
Faults: 0 661
DL_SWAP: 2 0 0
Faults: 1965
DL_SWAP: 2 0 0
Faults: 0 1997
DL_SWAP: 2 2 2
Right now I see "Faults: 0 109" and this is after several minutes.
I don't know what the actual issue is with REG_DLSWAP not returning to 0 occasionally.
At 50 frames per second it is unlikely that this is an issue with my display list, the update runs through hundreds if not thausands of frames with no issue at all and then I blink and the counter is a increased a little.
And when I happen to observe the counter to increase there is no noticeable glitch, I can't even tell that it is skipping a frame.
I am not using the external flash right now and have this running on a BT815 based display with 800x480.
My buffer sits at 3721 bytes to be transferred over the SPI with DMA, this results in a display list that is 5116 bytes long.
I am using an ESP32-WROOM32 with ESP-IDF and the SPI is running at 16MHz for the display update, reading from the SPI is done with 10MHz.
I just removed the "return" from my REG_DLSWAP test and added saving and displaying the value that is not zero:
Code: [Select]
read8 = EVE_memRead8(REG_DLSWAP);
if(0 != read8)
{
reg_dlswap_faults++;
dlswap = read8;
// return;
}
I expected a failure when removing the "return" but it just keeps running.
And so far the only value that is returned from REG_DLSWAP is 2.
I modified the code to read REG_DLSWAP a second and a third time if the first read was not zero.
And displayed is:
Faults: 0 118
DL_SWAP: 2 0 0
Faults: 0 134
DL_SWAP: 2 2 2
I also observed
DL_SWAP: 2 2 0
I slowed down the SPI for reading the register to 4MHz and I am still seeing this.
Faults: 0 15
DL_SWAP: 2 0 0
So this is unlikely to be a glitch from reading the register and if it were there should be other values than just 0 and 2.
I reduced the speed for the display update down to 8MHz and counter still gets increased eventually.
I still don't know what this actually is, but so far it looks like the issue is with REG_DLSWAP in the BT815.
It sure looks like REG_DLSWAP is not always getting updated properly.
Faults: 0 262
DL_SWAP: 2 0 0
Code: [Select]
read8 = EVE_memRead8(REG_DLSWAP);
if(0 != read8)
{
dlswap2 = EVE_memRead8(REG_DLSWAP);
reg_dlswap_faults++;
dlswap = read8;
dlswap3 = EVE_memRead8(REG_DLSWAP);
// return;
}
Faults: 0 347
DL_SWAP: 2 0 0
Faults: 0 354
DL_SWAP: 2 2 2
Faults: 0 411
DL_SWAP: 2 2 2
Faults: 0 435
DL_SWAP: 2 2 0
Faults: 0 439
DL_SWAP: 2 2 0
Faults: 0 531
DL_SWAP: 2 2 2
Faults: 0 537
DL_SWAP: 2 2 0
Faults: 0 616
DL_SWAP: 2 2 2
Odd.
It took a while to get there and it still keeps running with no issue.
And it is not constantly counting up, the value is stable for several seconds, then it ticks up
erratically untill it is stable again.
Faults: 0 702
DL_SWAP: 2 0 0
Faults: 0 783
DL_SWAP: 2 2 0
...
Faults: 0 3460
DL_SWAP: 2 0 0
....
And some readings several hours later:
Faults: 0 14407
DL_SWAP: 2 0 0
Faults: 0 14505
DL_SWAP: 2 2 2
Still going with no issue.
Time to switch to a different controller, the ESP32 is running too much software I have no control over.
Using the same display module and the same FFC I switched to one of my own boards that has an ATSAME51J19A clocked 80MHz.
The display loop is exactly the same, only the hardware abstraction changed for the SPI.
I directly went for 20MHz SPI clock after init.
The touch works just fine, so reading from EVE is not affected, usually this is the first to fail.
The "issue" is the same, REG_DLSWAP occasionally remains at 2 although EVE has about 17ms time to swap in the new display list after one
transfer is done before the next update is started.
And ignoring this does not stop the display from running.
Faults: 0 208
DL_SWAP: 2 2 2
Faults: 0 661
DL_SWAP: 2 0 0
Faults: 1965
DL_SWAP: 2 0 0
Faults: 0 1997
DL_SWAP: 2 2 2
28
Discussion - EVE / Re: Adding German Letters in BT818
« on: January 11, 2024, 05:19:38 PM »
As in using one command to print out "tränenüberströmt" for example? No.
There are two fixed width fonts that have extra characters beyond "Basic Latin",
these are 17 and 19 and the same size regular sets are the fonts 16 and 18.
But you can not use fonts 17 and 19 directly, so this:
EVE_cmd_text_burst(10, 390, 18, 0, "tr nen berstr mt");
EVE_cmd_text_burst(10, 390, 19, 0, " ä ü ö");
Does not work, the fonts only use values from 0...127 and the symbols need to translated from the table
to the correct numbers - see "Table 4-10 ROM Font Extended ASCII Characters" in the datasheet.
I just tried to print out a couple of chars and now I wonder how the first symbol with "Decimal" 128 is supposed to be useable,
as this one translates to zero printing that with CMD_TEXT should fail.
This works:
const char text[] = {127, 127, 4, 127, 127, 127, 1, 127, 127, 127, 127, 127, 127, 20, 0};
EVE_cmd_text_burst(10, 390, 18, 0, "tr nen berstr mt");
EVE_cmd_text_burst(10, 390, 19, 0, text);
But this is not only cumbersome to use, this is rather difficult to read on the 5" with 800x480 I am using.
And 18/19 already is the larger font pair.
I normally stick to fonts 26 to 31.
My recommendation is to use converted UTF-8 fonts with BT81x.
I am using this charmap to only convert a subset from "Basic Latin" and "Latin-1 Supplement":
What I also did back when I "only" had FT813 was to cheat, printed a "o" with a smaller font to a fixed position for "°C".
And I printed an "i" over an "u" to get a "µ", a few pixels low of course.
The third option would be to use images for labels.
I used an image for the text "Prüfplatz" in one project.
New points for the wishlist for the next generation of EVE chips
:
- remove fonts 16 to 25 and put in UTF-8 versions of fonts 26 to 34 with "Latin-1 Supplement"
- vector fonts, perhaps with a command to convert a set of glyphs before using it, so like a font-cache
There are two fixed width fonts that have extra characters beyond "Basic Latin",
these are 17 and 19 and the same size regular sets are the fonts 16 and 18.
But you can not use fonts 17 and 19 directly, so this:
EVE_cmd_text_burst(10, 390, 18, 0, "tr nen berstr mt");
EVE_cmd_text_burst(10, 390, 19, 0, " ä ü ö");
Does not work, the fonts only use values from 0...127 and the symbols need to translated from the table
to the correct numbers - see "Table 4-10 ROM Font Extended ASCII Characters" in the datasheet.
I just tried to print out a couple of chars and now I wonder how the first symbol with "Decimal" 128 is supposed to be useable,
as this one translates to zero printing that with CMD_TEXT should fail.
This works:
const char text[] = {127, 127, 4, 127, 127, 127, 1, 127, 127, 127, 127, 127, 127, 20, 0};
EVE_cmd_text_burst(10, 390, 18, 0, "tr nen berstr mt");
EVE_cmd_text_burst(10, 390, 19, 0, text);
But this is not only cumbersome to use, this is rather difficult to read on the 5" with 800x480 I am using.
And 18/19 already is the larger font pair.
I normally stick to fonts 26 to 31.
My recommendation is to use converted UTF-8 fonts with BT81x.
I am using this charmap to only convert a subset from "Basic Latin" and "Latin-1 Supplement":
Code: [Select]
!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~©«°±²³´µ¹»¼½¾ÄÖ×Üßäëö÷øüWhat I also did back when I "only" had FT813 was to cheat, printed a "o" with a smaller font to a fixed position for "°C".
And I printed an "i" over an "u" to get a "µ", a few pixels low of course.
The third option would be to use images for labels.
I used an image for the text "Prüfplatz" in one project.
New points for the wishlist for the next generation of EVE chips
:- remove fonts 16 to 25 and put in UTF-8 versions of fonts 26 to 34 with "Latin-1 Supplement"
- vector fonts, perhaps with a command to convert a set of glyphs before using it, so like a font-cache
29
Discussion - EVE / What happens when using invalid serial data?
« on: January 05, 2024, 08:37:43 AM »
The "Serial Data Protocol" has three valid combinations for the start of a communication defined:
0 0 - Host Memory Read
1 0 - Host Memory Write
0 1 - Host Command
What happens though in the FT81x / BT81x if the first two bits are 1 1?
Is the byte discarded as invalid and the next byte used as actual start of the frame?
Or is the complete frame discarded as invalid?
Could 0xc0 0x00 0x00 0x00 used for cmd ACTIVE?
Could 0xc0 0x30 0x20 0x00 used to read REG_ID?
Edit: I was too curious to not try this although doing undocumented things does not yield reliable results.
I changed my host command implementation by sending out an extra byte first - unfortunately this does not work at all,
the screen stays black.
Adding a trailing byte after the host command works though, so at least these could be using 32 bit transfers.
My "issue" is with the 24 bits for Host Memory Read/Write though.
0 0 - Host Memory Read
1 0 - Host Memory Write
0 1 - Host Command
What happens though in the FT81x / BT81x if the first two bits are 1 1?
Is the byte discarded as invalid and the next byte used as actual start of the frame?
Or is the complete frame discarded as invalid?
Could 0xc0 0x00 0x00 0x00 used for cmd ACTIVE?
Could 0xc0 0x30 0x20 0x00 used to read REG_ID?
Edit: I was too curious to not try this although doing undocumented things does not yield reliable results.
I changed my host command implementation by sending out an extra byte first - unfortunately this does not work at all,
the screen stays black.
Adding a trailing byte after the host command works though, so at least these could be using 32 bit transfers.
My "issue" is with the 24 bits for Host Memory Read/Write though.
30
Discussion - EVE / Re: Graphics engine freezing
« on: January 04, 2024, 11:52:52 AM »I've attached a screenshot.
That one made me smile.
I just uploaded this two days ago: https://github.com/RudolphRiedel/Electronics_repair/tree/main/kverneland_bale_wrapper_counter_7593
And the coincedence that your product is something for a baler is just amazing.
Quote
(On a side note, is every single post seriously limited by moderator approval or is there just a probationary period?)
Unfortunately so, yes, every single post needs to be approved by a moderator.
To my understanding this is to protect the forum from spam and there already was some.
I sugested a while back to assign posting privileges to "trusted" members of this forum,
and "trusted" could mean after a certain level of approved posts.
I just looked into the "simple machines forum" documentation and there would be a way to do this, there are "post count based membergroup permissions" and it looks like this has been configured as I am posting as "Sr. Member".
And it would be possible to add additional member groups.
Now these member groups can have indidually configured "Board Permissions".
And there even would be the option to setup a member group that has "Approve items awaiting moderation" rights, so this could be done without assigning new moderators.