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

Pages: [1]
1
Discussion - EVE / Loading Image into RAM_G Example
« on: July 29, 2022, 02:30:04 PM »
Hello,

I'm currently trying to write an image to RAM_G and display it on a display using BT817.  I've converted the png to and EVE bitmap and then a C array using EAB, but I think I'm missing something when loading it into RAM_G.

Code: [Select]
void write_ram_g(uint32_t image_size)
{
printf("Writing to RAM_G... ");
cmd_loadimage(RAM_G, OPT_FULLSCREEN);
for (int i = 0; i < image_size; i += 4)
{
uint32_t write_data = (flash_image[i+3] >> 24) | (flash_image[i+2] >> 16) | (flash_image[i+1] >> 8) | flash_image[i];
Send_CMD(write_data);
}
UpdateFIFO();
Wait4CoProFIFOEmpty();
printf("complete\n");
}

void verify_ram(uint32_t image_size)
{
for (int i = 0; i < image_size; i++)
{
printf("%d\n", rd8(RAM_G + i));
}
}


void screen_logo()
{
printf("Writing...\n");
write_ram_g(4250);
printf("Displaying... ");
Send_CMD(CMD_DLSTART);
Send_CMD(CLEAR_COLOR_RGB(255, 255, 255));
Send_CMD(CLEAR(1, 1, 1));
cmd_setbitmap(RAM_G, ARGB1555, 252, 72);
Send_CMD(BEGIN(BITMAPS));
Send_CMD(VERTEX2II(10, 10, 0, 0));
Send_CMD(END());
Send_CMD(DISPLAY());
Send_CMD(CMD_SWAP);
UpdateFIFO();
printf("done\n");
}
I'm using write_ram_g() to cycle through the bytes in the C array and write them starting at address 0, verify_ram() to print the relevant RAM_G to TeraTerm, and screen_logo() to display the image with a white background.  I can see the white background, but the printed RAM_G is the same as default and no image appears. 

It's clear to me that the image isn't being loaded into RAM_G, does anyone have an in-depth example they could point me to to load a C array into RAM like this?  I am new to loading anything into RAM/flash with the BT817.

2
Discussion - EVE / Re: Touch Returns Incorrect Tag/Track Value
« on: July 29, 2022, 02:18:14 PM »
I'm using a Nucleo-F446RE board with some jumper wires connecting to a FFC breakout board:
https://www.amazon.com/uxcell-Converter-Couple-Extend-Adapter/dp/B07RWNFKCR

I imagine this one isn't super premium, but yeah I lowered my sclk from 24MHz to 12MHz and that did the trick.  Your guess makes sense though.

3
Discussion - EVE / Re: Touch Returns Incorrect Tag/Track Value
« on: July 26, 2022, 03:55:51 PM »
Got it working!  Turns out my MCU's SPI clock was a little too fast for the display to handle.  I didn't even think to try slowing it down because my writes and everything were working.  I was reading more register values, such as REG_ID, and noticed those were actually following the same pattern as the tags.  In hindsight it seems like the problem was caused by the display not being able to drive the data line low as fast as my MCU wanted.

4
Discussion - EVE / Re: Touch Returns Incorrect Tag/Track Value
« on: July 25, 2022, 08:42:28 PM »
I am using a CFAF800480E1-050SR-A2 (resistive) display with a BT817 EVE4 processor.  I've also now ported one of my previous demo functions to the new project with the BRT_AN_025 library but can't get it to run continuously.  For example, when I put this simple screen-clearing code in a while(1) and run/debug, the loop will run all the way through once and then get stuck. 

However, with my old project, this was never an issue.  I'm sure it would be good to solve this secondary issue, but my main priority is getting rid of the tag errors I discussed earlier.  Would I be able to send my code to the support team and have them take a look at it?

Edit: Upon further debugging with the old project, I've determined that my functions used to write/read work fine.  I've been reading various register values then printing them back to the display using cmd_number, and they match the defaults as specified in the user guide.  The only registers where the results are incorrect are REG_TOUCH_TAG and REG_TRACKER.  Is there any other register or setting that would affect how those register values behave?

5
Discussion - EVE / Re: Touch Returns Incorrect Tag/Track Value
« on: July 25, 2022, 06:36:00 PM »
Hi, I added the provided eve_calibrate to my project but when I tap on the third dot, it stops flashing and the example screen never shows.  If I comment out the call to calibrate, the example screen shows but no touches are registered.  The calibrate screen registers touches however.

For context, I am using an STM32F446RE processor, and I have been able to have touches register without a calibration routine with my previous code.  I based my project on Matrix Orbital's example:
https://github.com/MatrixOrbital/EVE-Basic-Demo-STM32

6
Discussion - EVE / Re: Touch Returns Incorrect Tag/Track Value
« on: July 25, 2022, 03:55:37 PM »
Hello, would you mind including eve_calibrate as well?  I can't seem to find it in the EVE-MCU-BRT_AN_025 library.

7
Discussion - EVE / Re: Touch Returns Incorrect Tag/Track Value
« on: July 22, 2022, 08:23:52 PM »
Sure, here's some of the code I've been using on my MCU:

To draw two buttons:
Code: [Select]
//Draw first button with tag = 30
Send_CMD(TAG(30));
cmd_button(Display_Width()/4-40, Display_Height()*3/4-40, 80, 80, 30, OPT_FLAT, "30");

//Draw second button with tag = 31
Send_CMD(TAG(31));
cmd_button(Display_Width()*3/4-40, Display_Height()*3/4-40, 80, 80, 30, OPT_FLAT, "31");
To take the value from a slider object and display it as a number:
Code: [Select]
  start_display_list(128,128,128);
  uint32_t tracker = rd32(RAM_REG + REG_TRACKER);
  val = tracker >> 16;
Send_CMD(TAG(31));
cmd_slider(0, Display_Height()/2, Display_Width(), Display_Height()/12, OPT_FLAT, val, 31);
cmd_track(0, Display_Height()/2, Display_Width(), Display_Height()/12, 31);
cmd_number(Display_Width()/2, Display_Height()/4 + 50, 30, OPT_CENTER, val);
finish_display_list();
HAL_Delay(30);
The Send_CMD function:
Code: [Select]
void Send_CMD(uint32_t data)
{
  wr32(FifoWriteLocation + RAM_CMD, data);                         // write the command at the globally tracked "write pointer" for the FIFO

  FifoWriteLocation += FT_CMD_SIZE;                                // Increment the Write Address by the size of a command - which we just sent
  FifoWriteLocation %= FT_CMD_FIFO_SIZE;                           // Wrap the address to the FIFO space
}
So far the Send_CMD, cmd_xxxx functions have been working perfectly fine for drawing and registering touches, it's just the tag/tracker values are messed up like I've described.

8
Discussion - EVE / Touch Returns Incorrect Tag/Track Value
« on: July 22, 2022, 05:19:19 PM »
I am working on a project with a display with a BT817.  I've been working on getting touch functionality implemented, but I keep finding that objects will return the wrong tag. 

I first noticed this when I had two buttons, one with tag 30 and another with tag 31.  Pressing either button would return the tag 31, so I figured that somehow the 30 tag was being overwritten.  However, after changing that button to tag 10, it returned 15 instead.

So to get a sense of how the expected tag mapped to the received one, I held my finger on a button, and in a while loop incremented the button tag and printed out the results.  The pattern I got was seemingly random, with some values shown below:

Sent TagReceived Tag
11
23
33
46
57
67
77
812
913
1015
1115
1214
1315
1415
1515
...and so on.

The only values where the expected tag matched the actual tag are 0, 1, 3, 7, 15, 31, 63, 127, and 255.  In other words, when all bits below the most significant 1 are also 1.

After converting these values to binary, I eventually noticed a pattern: every bit I received was the result of an OR operation with the expected bit and the next highest bit.  So bit0 = bit0 | bit1, bit1 = bit1 | bit2, etc.

I've noticed this pattern with tags for touch objects, as well as the return value for any track object I draw.  Aside from leaving me with only a few valid tags, this means any slider/dial/scrollbar objects are extremely glitchy, as they are being redrawn with  the same values I saw appearing for the tags.

Can anyone help me understand why this is happening?  I'm glad I found the pattern but I don't understand where it's coming from or how to fix it.

Pages: [1]