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 ... 27
16
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.

17
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... :-)

18
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?

19
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. :-)

20
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:
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. :-)

21
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.

22
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?

23
Discussion - EVE / Re: Graphics engine freezing
« on: January 18, 2024, 09:14:52 PM »
They noted the following:
Quote
If 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.

24
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?

25
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:

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

26
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":
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  8) :
- 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

27
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.

28
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.

29
Discussion - EVE / Re: What is the purpose of CMD_REGREAD?
« on: December 29, 2023, 06:08:56 PM »
Hmm, I am going over my EVE_commands.c to add the final few missing function briefs that I started to add earlier.
And I came across CMD_REGREAD again.
After some consideration I decided to comment out my implementation like I already did with CMD_MEMWRITE as
I still can not come up with any real use for these - at least not how I implemented these, following the pattern I implemented
other functions that "return" values using the coprocessor.

While doing a CMD_CALLLIST, CMD_REGREAD is the only way to read a register. Similar to CMD_MEMWRITE.


Okay, but for what purpose exactly?
Using CMD_REGREAD in a snippet in RAM_G at least would make it easier to find the address that CMD_REGREAD wrote to.

30
Discussion - EVE / Re: Graphics engine freezing
« on: December 23, 2023, 07:57:04 PM »
I was playing with a new function that I implemented: EVE_polar_cartesian(uint16_t length, uint16_t angle, int16_t *p_xc0, int16_t *p_yc0)
And right now my display list is pushing EVE a little harder than usual, there are about 700 coordinate pairs calculated, most for line-strips and a couple for points and lines, this results in a DMA buffer of 3324 bytes and a display-list of 4060 bytes.

At some point in between I left it running for a while, even took a bath.
When I came back I noticed this on the display:
"Faults: 0 3"

With the "3" coming from this code I mentioned above:
if(0 != EVE_memRead8(REG_DLSWAP))
{
  reg_dlswap_faults++;
  return;
}

So now I got this as well, sort of.
However, the graphics engine was not frozen, everything was still up and running just fine with display-list updates every 20ms.
I left it like this for some more time before I finally updated the software again.
Whatever this was, the BT815 fully recovered from it and there was no coprocessor fault.

Edit:
It has been a couple of days, I changed some more things and the display up and running again.
Now I attached a screen shot and it shows four faults.
But the important part is, I am not even sure that there was an issue, I did not notice anything and it just kept running.

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