Hello,

The frames are extracted from the GIF using FFMPEG internally. FFMPEG duplicates frames within timestamp gaps based on the output frame rate. Adding "-vsync 0" to the FFMPEG command will preserve the original number of frames in the GIF. This fix will be included in the next version, EAB v2.11.

Ref: https://www.reddit.com/r/ffmpeg/comments/cqwlwo/extracting_frames_from_gif/

Hello,

Please note that the flash chip can still be accessed for reading and writing even without a blob.
Upon successful erasure, the flash chip will be detected as "Blob is NOT present."

Hello,

I would like to open and see, in my PC, the .raw files generated by EVE Asset Builder. This is intended as an utility or checking tool.

For every image I convert with EAB, using ASTC format without compression, I get a bunch of output files. I trash them all, except the .raw, which is the only one I'm interested in, because it will be later copied into the external flash of the BT81x.

I rename the .raw files so the name contains the compression scheme and dimensions. For example, "Icon STOP 4x32x32.raw" means that the contained image is 32x32 with ASTC format 4x4.

The program in my board uses the (modified) filename to load the image, and all works well.

Now I am trying to write a PC program to view those .raw files on my PC. I noticed that the .raw file is 16 bytes shorter than the companion .astc file. This means that the .raw file does not contain the standard astc file header, but I am able to generate this header. So I create a temporary file containing the re-generated header, append the .raw file, and open it with tacentview (a PC program able to display ASTC files).

The image loads, but it is wrong. Inspecting the .raw and the .astc file, I notice that they contain the same data, but in different order. I suppose this is required for the EVE chip BT81x.

My question is: how can I reorder the .raw data, to reconstruct the original .astc file so I am able to view it on the PC? Or, to turn differently the question, what does the EAB to convert an .astc file to a .raw file? (It seems EAB uses astenc.exe, and then, probably, converts the .astc to a .raw file).

This utility would be useful because, without that, I have to keep the original files associated with every .raw file I generate. I.E. if I want to check an image used in my board, I cannot open it directly, I have to keep a "companion" original file (be it the associated .astc or the JPG/PNG I started from).

Thanks in advance to anybody can help me, regards,
linuxfan

Also, I want to express my gratitude to Rudolph for his amazing work. Big thanks for that!

Thank you!


This made me realize that I probably never tried to calibrate my RVT101HVBNWC00-B. :-)
The touch worked ok as is.

TransMatrix1 = 65536;
TransMatrix2 = 0;
TransMatrix3 = 0;
TransMatrix4 = 0;
TransMatrix5 = 65536;
TransMatrix6 = 0;

These are the reset values for the registers, I am getting the same values here with no calibration.

The values I am getting after calibration are all over the place:
REG_TOUCH_TRANSFORM_A : 0x0000FF2F
REG_TOUCH_TRANSFORM_B : 0xFFFFFEAB
REG_TOUCH_TRANSFORM_C : 0x0005CACE
REG_TOUCH_TRANSFORM_D : 0xFFFFFCAA
REG_TOUCH_TRANSFORM_E : 0x00010116
REG_TOUCH_TRANSFORM_F : 0x00044696


And now I know again why I usually keep the RVT101HVBNWC00-B up on the shelf. :-)
It is big.
It is bright.
It is big.

Have you fixed your alignment? The flash destination address that you posted in the other thread was not a multiple of 4096.

Hello,

Thank you for the clarifications, I think in the case that both the older version of the same display and the fact that rerunning the calibration routine results in the display working as expected means we can rule out an issue with the I2C data coming from the touch controller. And similarly it would rule out a hardware issue such as the CTP connector being misaligned.

I would be interested to know if the saved matrix values that you are noting are captured before you write them into the EERPOM or afterwards? This, as you have noted, may be related to an overflow issue or potentially an endianness issue.

Best Regards,
BRT Community

I am trying to update my flash using cmd_flashupdate. But flash doesn't get updated, unless I erase the whole flash memory.

Hi there.
I've been recently testing the method with interrupt handling from the touch panel. Thanks to this, it's possible to practically not send anything to FT/BT81x for most of the time. When an interrupt occurs, only then do I read the TAG. Here's the interrupt configuration:
void EVE_INT_config(void)
{
    EVE_memWrite8(REG_INT_EN,1);                // IRQ on
    EVE_memWrite8(REG_INT_MASK,EVE_INT_TAG);    // EVE_INT_TOUCH|
    EVE_memRead8(REG_INT_FLAGS);                // clear by read flag
}

Then, in loop functions:
if(is_set(FLAGS,_f_tp_irq))
        {
            CurrTag = EVE_memRead8(REG_TOUCH_TAG);
            RESET(FLAGS,_f_tp_irq);
... // the rest of the code
            // refresh the screen by set timDisp to 0
            timDisp = 0;
            EVE_memRead8(REG_INT_FLAGS); // skasuj flagi
            timer_screensaver = time_screensaver; // przeładuj timer wygaszacza ekranu
        }
        // prepare a new display list:
        if(!timDisp)
        {
            timDisp = 50;     
            // start new 'display list'
            start_new_screen();
...// etc
            finish_new_screen();
        }
Also IRQ from pin change:
ISR(INT7_vect)
{
    SET(FLAGS,_f_tp_irq);
}

Thank you for your response to my questions.

I note you mention an older screen does not present this issue, are both of these screens the same RVT101HVBNWC00-B model?

It turned out that the issue also occurs on the older/newer RVT101HVBNWC00-B panel. Currently, I am working on the project, and every time I power it on and restore the saved calibration matrix from EEPROM, I still have to perform calibration. I trigger the calibration with a button on the PCB.

On the occasion of the issue occurring does a re-run of the calibration routine result in accurate matrix values, or for example do you need to power cycle the board?

Running the calibration function solves the problem with the touchscreen panel. It seems like I mostly have to do this almost every time I power it on.

Have you noted any issues around the CTP connector to the displays main PCB?

I haven't noticed any problems with the CTP connector. When I used 7" panels with CTP before, everything worked fine. I'll add that I have the screen rotated 180 degrees, but that shouldn't be an issue.

PS. Perhaps the problem lies elsewhere, for example, I might be experiencing buffer overflow - I need to carefully check the source code again.
Regards,
Karol

Hello,

Thank you for your post.

I note you mention an older screen does not present this issue, are both of these screens the same RVT101HVBNWC00-B model?

On the occasion of the issue occurring does a re-run of the calibration routine result in accurate matrix values, or for example do you need to power cycle the board?

Have you noted any issues around the CTP connector to the displays main PCB?

Best Regards,
BRT Community