Using CMD_SNAPSHOT2 to copy the rendered font to RAM_G and then analyzing it worked. Waiting to ensure the font was rendered and then waiting for it to get copied to RAM_G was a bit tricky. I ended up checking the INT_SWAP flag in REG_INT_FLAGS to tell when the frame had been rendered after drawing the bitmap and then again after the call to CMD_SNAPSHOT2. Perhaps that is overkill and there is a better way to check when the steps are complete.

For anyone who found this thread and needs the baseline information, here is what I calculated for the ROM fonts. The baseline is in pixels from the bottom of the bitmap. I also calculated the cap height as the distance from the bottom of the bitmap to the top of "flat" capital letters. Perhaps it should be calculated from the baseline. You can adjust these numbers as needed. In both cases, I used '1' as the reference glyph since it is flat (and is present in some reduced character set fonts I use).

Font #	Baseline	Cap Height
16	1	8
17	0	8
18	4	14
19	0	16
20	2	10
21	3	4
22	4	16
23	4	17
24	5	23
25	7	31
26	3	14
27	4	17
28	5	20
29	5	23
30	7	30
31	10	41
32	12	51
33	17	69
34	22	89

mike

I decided to try and determine the baselines myself, at runtime. Using the font metrics, I could multiply the line stride by the font height to determine how many bytes are in each character's bitmap. Then I could jump to the end of a bitmap and read each row from the bottom to the top until I detected a non-zero pixel. That would be the baseline. Since the line stride tells me how many bytes are in each line, it seemed easy enough to do. After testing, this method does work for a custom font I uploaded in L4 format. However, it doesn't work for built-in fonts. Or at least it doesn't work for font 31. I haven't checked the others yet.

The problem is the font format. Despite the BT817/8 datasheet saying font 31 is an L4 format font, the metrics block says it is COMPRESSED_RGBA_ASTC_8x8_KHR. The datasheet also says the line stride should be 18, but the metrics say it is a whopping 80 bytes per line!

Now I don't know what to do. Perhaps I'm reading the wrong metrics block, but all the other values seem reasonable.

What is the meaning of line stride in an ASTC compressed font? Can I use it to determine the start of each row of the bitmap? Or is it only useful when multiplying against the font height to determine the size of each character?

Is there a way I can extract a single line from the bitmap so I can determine if any pixels are set without decompressing the entire character? Or if the entire character must be decompressed, can I use the BT817/8 to decompress it into RAM_G where I can then examine it row, by row?

Or better yet, can someone provide the baseline metrics for all the ROM fonts and I can hard code those values into my program and only runtime-calculate the baselines for my custom fonts.

Thanks,
mike

Thank you. That is important to know. The 10x difference between a typical current draw of 0.2mA and a max current draw of 2mA during power down is significant. Especially when powered by batteries.

mike

Hi Rudolph,
Yes, now that I look at it closer, I see that each of the three ranges applies to each supply: VCCIO1, VCCIO2 and VCCIO3. It is only an accident of formatting that each VCCIO is on a separate line. I should have noticed this.

And yes, it is weird that there are voltage gaps in the acceptable ranges. Is 2.1V or 2.9V really not allowed?

I'm still hoping someone can answer my primary question regarding Iq for the 1.2V regulator.

mike

Hi David,
Thanks for the reply. I set up a test and created one rectangle using SCISSOR and CLEAR and compared it to a rectangle using BEGIN(RECTS) with a line width of 16 * 1. I see a little bleed into the surrounding pixels when I use BEGIN(RECTS). It's subtle, but the edges definitely aren't as crisp as when I use SCISSOR.

So I guess, if I want the sharpest possible rectangles (and I don't know if that is truly necessary), I need to use SCISSOR.

I should note that the output from my BT817 goes through a chip that converts the signal to HDMI where it is displayed on a small monitor. I'm not using the monitor's native resolution, either. I'm displaying at 480p and the monitor is native 720p. That said, I can always identify which rectangle was made with SCISSOR and which was made with BEGIN(RECTS), even when I swap their screen locations.

mike

Thank you. AN_336 helps. It says that HOFFSET should be Back Porch + Sync Pulse + (Front Porch - X), where X >= 1. This also applies to SYNC0 and SYNC1. Where ever you see the Front Porch, you should use (Front Porch - X). Table 3.1 and Figure 3.2 show this.

I was using the BT817_8 datasheet (version 1.1 - the same as the one you link to). It is different. Table 4-14 from the datasheet is similar to Table 3.1 in the app note, but does not say to reduce the front porch. The Display Parameter column of Table 4-14 says HOFFSET = Front Porch + Sync Pulse + Back Porch. The Front Porch is used without being reduced. The verbiage in the Description column says HOFFSET < HCYCLE - HSIZE, but that does not agree with what is shown in the Display Parameter column.

This discrepancy is also seen in Figure 4-6. Figure 4-6 is similar to the app note's Figure 3.2. However, the figure in the app note shows a reduced value for the Front Porch. The figure in the datasheet shows the full duration of the Front Porch.

Based on what you are saying, the app note is correct and the datasheet should be corrected.

The app note says X (the value used to reduce the front porch) must be >= 1. Is there any further restriction on this or is it always acceptable to use X=1?

Thank you for the clarification,
mike

Yes, I have a bridge chip for the HDMI interface. I use a TFP420.

As an example, here is the VESA timing for 640x480 @60MHz:

pixel clock = 25175000
horizontal active pixels = 640
horizontal blank = 160
horizontal front porch = 16
horizontal sync = 96
vertical active lines = 480
vertical blank = 45
vertical front porch = 10
vertical sync = 2

Given this timing, I set the BT818 registers as follows:
HCYCLE = 800
HSIZE = 640
HOFFSET = 160
HSYNC0 = 16
HSYNC1 = 112
VCYCLE = 525
VSIZE = 480
VOFFSET = 45
VSYNC0 = 10
VSYNC1 = 12

I can get output using these timing values (and PCLK twice as fast as required and CSPREAD disabled), but I want to be able to handle general cases as well - where timing information is extracted from the display using DDC and it is not known in advance. Here are my questions:

1) Does the BT818 render each line during the blanking period (HOFFSET)?
2) Why does HCYCLE need to be greater than HSIZE + HOFFSET, instead of greater than or equal to HSIZE + HOFFSET? I don't see any cycles in the Figure 4-6 RGB Timing Waveforms from the datasheet that would allow HOFFSET < HCYCLE - HSIZE.
3) Is the blanking period (HOFFSET) not sufficient for rendering?
4) If it is not sufficient, how do I calculate how much addition time is required?