1
Discussion - EVE / Re: SOLVED - EAB, ASTC output files: how can I see the content of a ".raw" file?
« on: March 22, 2024, 10:34:42 AM »
Thank you for this idea - didn't come to my mind.
- May 17, 2024, 07:28:47 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.
Pages: [1]
2
Discussion - EVE / Re: EAB, ASTC output files: how can I see the content of a ".raw" file?
« on: March 21, 2024, 05:46:16 AM »
Thank you for your interest.
In fact, my customers already use eab_tools in batch mode, controlled by a custom program written by me.
Problem is, when they send me a converted file to check, I can not see it; and I don't want to ask my customers to send me the source files.
In fact, my customers already use eab_tools in batch mode, controlled by a custom program written by me.
Problem is, when they send me a converted file to check, I can not see it; and I don't want to ask my customers to send me the source files.
3
Discussion - EVE / Re: EAB, ASTC output files: how can I see the content of a ".raw" file?
« on: March 19, 2024, 06:07:41 AM »
Really nobody can give me a hint?
4
Discussion - EVE / SOLVED - EAB, ASTC output files: how can I see the content of a ".raw" file?
« on: February 21, 2024, 06:47:48 AM »
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
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
5
Discussion - EVE / Re: Display ASTC images directly from BT817 flash
« on: December 21, 2023, 10:50:05 AM »
Thank you all for the help. I tried to lower the frame rate, and to use REG_AH_HCYCLE_MAX. Both helped in giving more time to the GPU, but failed on a more thorough test.
So I decided to always copy the images in RAM first.
While playing with registers I activated the HSF filter: awesome! Now my 800x480 LCD shows perfectly round circles instead of ellipses. This HSF filter is clever and transparent - good job.
Regards,
linuxfan
So I decided to always copy the images in RAM first.
While playing with registers I activated the HSF filter: awesome! Now my 800x480 LCD shows perfectly round circles instead of ellipses. This HSF filter is clever and transparent - good job.
Regards,
linuxfan
6
Discussion - EVE / Re: Display ASTC images directly from BT817 flash
« on: December 17, 2023, 06:08:44 AM »
> That is only partially correct ... Interesting would be the next command
The next command reads the chip ID from REG_ID register (0x302000): if the content is not 0x7C the whole wakeup sequence (reset, set CLK...) is repeated.
So I assume the chip runs at 60 MHz.
>> I am not able to tell what the frame rate is
> It either is 61.58Hz with 60MHz clock or 73.89MHz with 72MHz clock.
Uhm... how do you calculate that? I thought that I should take the PCLK and divide it first for display width and then for display height (grossly). I obtain a frame rate of about 78 Hz (which is 30MHz divided by 800 then by 480), so I thought I could lower it down to 30 FPS to give more time to the GPU.
Is my reasoning correct? I mean - I should lower the framerate in order to ease the GPU job?
The next command reads the chip ID from REG_ID register (0x302000): if the content is not 0x7C the whole wakeup sequence (reset, set CLK...) is repeated.
So I assume the chip runs at 60 MHz.
>> I am not able to tell what the frame rate is
> It either is 61.58Hz with 60MHz clock or 73.89MHz with 72MHz clock.
Uhm... how do you calculate that? I thought that I should take the PCLK and divide it first for display width and then for display height (grossly). I obtain a frame rate of about 78 Hz (which is 30MHz divided by 800 then by 480), so I thought I could lower it down to 30 FPS to give more time to the GPU.
Is my reasoning correct? I mean - I should lower the framerate in order to ease the GPU job?
7
Discussion - EVE / Re: Display ASTC images directly from BT817 flash
« on: December 15, 2023, 07:06:25 AM »
I've sent the images via email as you suggested.
For your comfort, I also post them here. The images are 8x8 ASTC.
The initialization of the display is as follows:
#define DispWidth 800L // REG_HSIZE
#define DispHeight 480L // REG_VSIZE
#define DispHCycle 928L // REG_HCYCLE...
#define DispHOffset 88L
#define DispHSync0 0L
#define DispHSync1 48L
#define DispVCycle 525L
#define DispVOffset 32L
#define DispVSync0 0L
#define DispVSync1 3L
#define DispPCLK 2
#define DispSwizzle 0
#define DispPCLKPol 1
#define DispCSpread 0
#define DispDither 1
The main clock is external, set by writing 0x44000000 during initialization. I am not able to tell what the frame rate is, using the above parameters - I just copied them from an example and they work.
For your comfort, I also post them here. The images are 8x8 ASTC.
The initialization of the display is as follows:
#define DispWidth 800L // REG_HSIZE
#define DispHeight 480L // REG_VSIZE
#define DispHCycle 928L // REG_HCYCLE...
#define DispHOffset 88L
#define DispHSync0 0L
#define DispHSync1 48L
#define DispVCycle 525L
#define DispVOffset 32L
#define DispVSync0 0L
#define DispVSync1 3L
#define DispPCLK 2
#define DispSwizzle 0
#define DispPCLKPol 1
#define DispCSpread 0
#define DispDither 1
The main clock is external, set by writing 0x44000000 during initialization. I am not able to tell what the frame rate is, using the above parameters - I just copied them from an example and they work.
8
Discussion - EVE / Re: Display ASTC images directly from BT817 flash
« on: December 14, 2023, 05:31:01 AM »
> what sizes your images are, are they all 752x168 (based on filename)?
> Is your flash set for fast mode
Thank for your reply.
Yes, images have all the same dimension 752x168 and yes, the flash is in full mode.
In fact, not touching the C program but simply skipping instruction, any single image works correctly, but two or more together do not.
> Is your flash set for fast mode
Thank for your reply.
Yes, images have all the same dimension 752x168 and yes, the flash is in full mode.
In fact, not touching the C program but simply skipping instruction, any single image works correctly, but two or more together do not.
9
Discussion - EVE / Display ASTC images directly from BT817 flash
« on: December 13, 2023, 05:08:15 PM »
Hi all.
I have three images in ASTC format ready in the flash memory attached to BT817. Each image starts on a 4k boundary.
If I, stepping through my program, generate a DL with only one of the three images, it works normally.
As soon as I use two or three images, the BT817 gets crazy, messe up the screen with flashes and other anomalies.
I I first copy the three images in RAM_G, of course in appropriate non-overlapping adresses, it works.
My display list is as follow:
// copy in ram 3 images, and get their address
handles[1] = resou_bitmapastc("STS 8x752x168.raw", 0);
handles[2] = resou_bitmapastc("ST 8x752x168.raw", 0);
handles[3] = resou_bitmapastc("ASS 8x752x168.raw", 0);
Gpu_CoCmd_Dlstart();
coCmd(CLEAR_COLOR_RGB(255,255,255));
coCmd(CLEAR(1, 1, 1));
coCmd(COLOR_RGB(255,255,255));
coCmd(BEGIN(BITMAPS));
coCmd(BITMAP_HANDLE(0));
Gpu_CoCmd_SetBitmap(handles[1], resou_lastt, resou_lastw, resou_lasth); // resou_lastX are correct
coCmd(VERTEX2F(18*16, 53*16));
coCmd(BITMAP_HANDLE(1));
Gpu_CoCmd_SetBitmap(handles[2], resou_lastt, resou_lastw, resou_lasth);
coCmd(VERTEX2F(18*16, 250*16));
coCmd(BITMAP_HANDLE(2));
Gpu_CoCmd_SetBitmap(handles[3], resou_lastt, resou_lastw, resou_lasth);
coCmd(VERTEX2F(18*16, 412*16));
coCmd(END());
coCmd(DISPLAY());
Gpu_CoCmd_Swap();
Gpu_Hal_WaitCmdfifo_empty();
The above works, because the images are first copied in RAMG. But if I don't copy them, and use
Gpu_CoCmd_SetBitmap(0x800000 | FLASH_ADDR / 32, .....)
only one image at a time can be displayed correctly. No two or three images together work. I can say this because, running step-by-step my program, I can execute instruction for just one image, and then skip right to the instruction for DISPLAY().
Please note that the three commands "coCmd(BITMAP_HANDLE(X));" were added later: at first I didn't use them, and then added them to see whether they could help (but they didn't).
What am I doing wrong?
Thank you for help and regards.
I have three images in ASTC format ready in the flash memory attached to BT817. Each image starts on a 4k boundary.
If I, stepping through my program, generate a DL with only one of the three images, it works normally.
As soon as I use two or three images, the BT817 gets crazy, messe up the screen with flashes and other anomalies.
I I first copy the three images in RAM_G, of course in appropriate non-overlapping adresses, it works.
My display list is as follow:
// copy in ram 3 images, and get their address
handles[1] = resou_bitmapastc("STS 8x752x168.raw", 0);
handles[2] = resou_bitmapastc("ST 8x752x168.raw", 0);
handles[3] = resou_bitmapastc("ASS 8x752x168.raw", 0);
Gpu_CoCmd_Dlstart();
coCmd(CLEAR_COLOR_RGB(255,255,255));
coCmd(CLEAR(1, 1, 1));
coCmd(COLOR_RGB(255,255,255));
coCmd(BEGIN(BITMAPS));
coCmd(BITMAP_HANDLE(0));
Gpu_CoCmd_SetBitmap(handles[1], resou_lastt, resou_lastw, resou_lasth); // resou_lastX are correct
coCmd(VERTEX2F(18*16, 53*16));
coCmd(BITMAP_HANDLE(1));
Gpu_CoCmd_SetBitmap(handles[2], resou_lastt, resou_lastw, resou_lasth);
coCmd(VERTEX2F(18*16, 250*16));
coCmd(BITMAP_HANDLE(2));
Gpu_CoCmd_SetBitmap(handles[3], resou_lastt, resou_lastw, resou_lasth);
coCmd(VERTEX2F(18*16, 412*16));
coCmd(END());
coCmd(DISPLAY());
Gpu_CoCmd_Swap();
Gpu_Hal_WaitCmdfifo_empty();
The above works, because the images are first copied in RAMG. But if I don't copy them, and use
Gpu_CoCmd_SetBitmap(0x800000 | FLASH_ADDR / 32, .....)
only one image at a time can be displayed correctly. No two or three images together work. I can say this because, running step-by-step my program, I can execute instruction for just one image, and then skip right to the instruction for DISPLAY().
Please note that the three commands "coCmd(BITMAP_HANDLE(X));" were added later: at first I didn't use them, and then added them to see whether they could help (but they didn't).
What am I doing wrong?
Thank you for help and regards.
Pages: [1]