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 - david

Pages: [1]
1
I am still interested in that. It would be very nice, if I can get an update about it. Is it a bug in the compiler or with BT815 or am I not using it correctly?

2
Do you have any new information? I am comparing a few different touch controllers (also with host mode) and it would help a lot to have more information about that topic. Did you also try the sample code on a BT817, does it work there (I could not get one yet)?

3
Thanks a lot for clarifying. The display does not support adaptive frame rate. I will try to work around this issue by splitting up the text more (bigger margins between then lines). This worked in my first tests.
I ensured that the flash is in full state, by checking REG_FLASH_STATUS. If I put it in basic state I cannot even see any directly rendered ASTC images from flash. So this one is done correctly.
I will also order a BT817 for testing you mentioned adaptive HSync feature.

Best Regards,
David

4
I have problems with flickering displays, when I try to render fonts with larger sizes (f.e. 32 or 40).
It does not happen if I render just a few characters. It begins at about 6 lines with around 15 letters on each line.
I tried converting the font with EVE Asset Builder with ASTC 8x8 and also tried it with the maximum 12x12.
The total size of the glyph for the font size 40 is 2.2 MB so loading it into RAM is not an option.
I don't have problems with smaller font sizes (tried size 22).
Are there know limitations about the ASTC rendering from flash? In the programming guide I saw the section "Performance" which describes the time needed for specific formats, but I think those are not for ASTC on flash.
For me it looks like the time for reading the data from flash takes to long, but some information about that would be helpful.

Flash: W25Q128JV
BT: BT815
Display: 640x480 with NV3052C display controller
BT clock: 72 MHz
REG_PCLK: tried 3, 2, 1 (flickering gets a bit better with higher display clock)
REG_CSPREAD: 0
Font: Noto Sans (https://www.google.com/get/noto/)
Font size: 40

I found this old thread, which might be a related issue but it was not solved and it was about showing images from flash instead of custom fonts: http://www.brtcommunity.com/index.php?topic=78.msg379#msg379

I can provide photos or code/font files if needed. But I think it is very easy to reproduce that, it happened on the EVE 3 with 7 inch display for me before I just ignored it by showing less text. Just show some more lines of text with a font size 40.

5
I would be very grateful for any help. Did anyone successfully transfer a self compiled touch firmware binary yet?

6
Hello, I am Trying to flash a new firmware for the capacitive touch controller. I am using the BT815 with the EVE Asset Builder 2.2.
I was not successfull with my code in the first place, I sniffed the I2C traffic between the BT815 and the touch controller and it did not address and send the correct data.
That's why I tried to simplify it by removing the whole I2C communication and just reporting static values to the BT815. This is the code I am compiling:
Code: [Select]
int i2c_addr()
{
  return 0x38; // does not matter for my test
}

int setup()
{
  setWAKE(0);
  delay_ms(5);
  setWAKE(1);
  delay_ms(300);
}

void loop()
{
report_touch(0, 400, 300);
delay_ms(5); // also tried without those delays and with id 1 as well
report_touch(0, 200, 100);
delay_ms(5);
}

which results in this:
Code: [Select]
26,255,255,255,32,32,48,0,4,0,0,0,2,0,0,0,26,255,255,255,0,176,48,0,4,0,0,0,5,2,0,0,34,255,255,255,238,178,48,0,120,218,37,142,177,75,195,80,16,198,239,154,182,168,25,204,251,3,58,60,16,165,24,39,59,56,222,209,69,40,217,197,233,189,182,70,180,89,156,20,117,184,172,18,72,157,197,81,40,205,191,32,14,78,29,187,56,73,233,226,238,232,34,196,151,56,220,241,187,143,239,227,59,101,246,233,78,31,66,102,148,163,54,237,152,107,62,35,207,118,38,55,184,43,3,80,166,79,222,80,153,92,191,16,92,62,96,110,67,167,30,72,150,108,186,129,24,197,27,53,229,17,143,36,51,247,46,239,11,36,202,38,188,103,79,185,51,241,157,247,137,127,1,177,199,61,222,16,239,42,31,130,204,120,206,43,66,153,97,197,129,157,51,242,10,124,137,160,74,67,12,18,88,20,24,45,180,178,39,220,167,192,54,169,37,112,254,174,111,233,24,202,18,98,111,220,149,1,109,59,247,22,125,232,174,68,53,127,234,204,148,238,159,37,66,186,100,101,214,85,227,197,26,209,93,95,216,168,55,200,148,91,82,184,246,41,135,105,1,175,236,148,52,76,159,107,21,100,33,99,249,231,55,252,230,31,142,210,130,218,141,63,227,110,93,240,0,0,26,255,255,255,32,32,48,0,4,0,0,0,0,0,0,0
But when I try to get the touch values (the raw ones from REG_TOUCH_RAW_XY) I just get x: 0, y: 0 or x: 65535, y: 65535.
I can see that the BT815 is not communicating via I2C anymore, so the transfer of the firmware seems to work at least in some parts.

I have also a few more questions:
- is the response of int i2c_addr() used over the one in REG_TOUCH_CONFIG (REG_CYA_TOUCH) or which one is priorized?

- is it possible to configure the I2C frequency?

For uploading the Firmware my code looks like this:
Code: [Select]
Gpu_Hal_WaitCmdfifo_empty(host);
Gpu_Hal_WrCmdBuf(host, TOUCH_DATA, sizeof(TOUCH_DATA));
Gpu_Hal_WaitCmdfifo_empty(host);
I tried it right after GPU_ACTIVE_M in setup and also after getting the BT815 ID via REG_ID.
I also tried to reset the touch component with Gpu_Hal_Wr32(host, REG_CPURESET, 2); followed by Gpu_Hal_Wr32(host, REG_CPURESET, 0);

The real code which I tried to compile and run at the first place is this one:
Code: [Select]
int i2c_addr()
{
  return 0x41;
}

int setup()
{
  setWAKE(0);
  delay_ms(5);
  setWAKE(1);
  delay_ms(300);
}

void loop()
{
  while (getINT() == 1) // wait for INT to go low
    ;
  i2c_startread(0x10);
  int n_touches = i2c_read8();
  int touch_index = 0;
  int x_raw;
  while (touch_index < n_touches) {
x_raw = i2c_read16le();
report_touch(touch_index, i2c_read16le(), x_raw & 0x3fff);
touch_index = touch_index + 1;
  }
  i2c_stop();
}

It would be nice, if there are some more information about updating the touch firmware or if someone could test the firmware on top to check if the uploading is the problem.
If it helps I can also provied sniffed I2C traffic of one of the compiled firmwares.

Pages: [1]