Thanks, I've updated my code to calculate REG_PCLK_FREQ according to the new instructions instead of using CMD_PCLKFREQ.

I still have to calculate the values based on twice my desired PCLK frequency, but perhaps that is because I'm using the internal clock and not the external oscillator.

Can you please comment on the HOFFSET < (HCYCLE - HSIZE) constraint based on my example above. I can't see how it is possible to meet that constraint when you are using VESA timings or timings provided by the display over DDC. When using those timings, HOFFSET = (HCYCLE - HSIZE). HOFFSET is the sum of all blanking pixels and HSIZE is the active pixels. In order for HCYCLE > HOFFSET + HSIZE, there would need to be extra PCLK cycles not assigned to either active or blanking pixels. If you were to arbitrarily increase HCYCLE to more than HOFFSET + HSIZE, you would also need a PCLK frequency higher than the one in the VESA timings.

I did experiment with increasing HCYCLE and leaving HOFFSET and HSIZE as-is, but the display didn't like it. It had a difficult time syncing.

Thanks,
mike

If I compare the REG_PCLK_FREQ values in table 4-11 to the value set by calling CMD_PCLK_FREQ, I see they are the same. I tested all the values in the table and CMD_PCLK_FREQ gives the same REG_PCLK_FREQ value as shown in the table. So CMD_PCLK_FREQ appears to be behaving correctly if the table is also correct. However, both the table and CMD_PCLK_FREQ conflict with the definition for REG_PCLK_FREQ[10:9] listed immediately above table 4-11. Which is correct: CMD_PCLK_FREQ and table 4-11 or the description of bits REG_PCLK_FREQ[10:9].

Regarding the HOFFSET < (HCYCLE - HSIZE) requirement, what is the recommended procedure when you are retrieving timings from the display over DDC? For example, I have a display that reports a preferred timing of:
    74.25 MHz pixel clock
    1280 active horizontal
    370 total horizontal blanking period
    110 horizontal front porch
    40 horizontal sync
    720 active vertical
    30 total vertical blanking period
    5 vertical front porch
    5 vertical sync

The total number of pixels per frame is (1280 + 370) * (720 + 30) = 1237500
74.25 MHz / 1237500 = 60 frames per second

Looking only at the horizontal part,
    HSIZE = 1280
    HOFFSET = 370
    HSYNC0 = 110
    HSYNC1 = 150

To make HOFFSET < (HCYCLE - HSIZE), I'd have to make
    HCYCLE > 1650 [1280 + 370]
but if I did that, then the timing value of 74.25MHz wouldn't be correct.

This above is just one example, but all the standard VESA timings work the same way. They assume (hactive + hblank) * (vactive + vblank) * framerate = pixel clock. There's no room for extra pixel clock cycles.

What's the preferred way to manipulate the supplied timing values to meet the HOFFSET < (HCYCLE - HSIZE) constraint? Reduce the front porch to 0? Maybe make both front and back porch 0 thus reducing HOFFSET to just the sync duration?

As for the test card, I'm doing:
CMD_DLSTART
CMD_TESTCARD
CMD(DISPLAY())
CMD_SWAP

mike

I should probably mention another weird thing, in case it is relevant. I only use single mode SPI, not dual or quad. The fastest I can run the SPI clock is 8 MHz. If I try 9 MHz or faster, I get garbled responses from the BT818.

mike

The on-chip oscillator's accuracy isn't very good, but it's good enough that I can render at 640x480 if I request double the normal PCLK value. At this point, my bigger concern is the lack of output on the R[0..7] pins. Not being able to display red is rather annoying. I am interested to see what the R&D engineer has to say. I'd really like to get things usable enough that I can develop on my board since it might be a while before the chip supply recovers and I can build a new version.

I don't know if there have been multiple updates to the BT818, but REG_DATESTAMP reports "2019-10-28 2.5.3" on mine.

mike

I've got a BT818 on a board of mine and I'm seeing some weird things with respect to the PCLK timing.

1)
The REG_PCLK_FREQ register values don't agree with the datasheet when set by CMD_PCLKFREQ. For example, if I request a frequency of 36 MHz, REG_PCLK_FREQ gets set to 0x461. If you were to interpret that according to the data sheet, you'd get a frequency of 36 MHz, but the range (found in bits 10:9) are 10. That implies a range of 80 - 160 MHz. If we repeat the exercise, but with a frequency of 72 MHz, REG_PCLK_FREQ is 0x8c1 which has a range of 00 which is 20 - 40 MHz.

I think the real range bits are found in bits 11:10, not 10:9. But even then, the range for 36 MHz would be 01, which is 40 - 80 MHz. 36 MHz is below that. Similarly, a clock of 72 MHz gives a range value of 10, which is 80 - 160 MHz. 72 MHz is also below that range.

I'm not sure what's going on here, but the datasheet does not seem to agree with the results from CMD_PCLKFREQ.

2)
When I put a scope on the PCLK output, pin 39, I see a clock that is about half what was programmed. Does data get clocked out on both rising and falling edges? And if so, is that standard? I'm running the output of the BT818 into a TFP410 to create an HDMI signal and I think that chip expects only one pixel per clock cycle, not two. Can anyone explain to me what's going on here?

Thanks,
mike