Hello,
We have been users of the ADV7623 for a number of years. We have developed OSD that does not use the ADI OSD Design tool and instead goes directly to the OSD register map and OSD Ram for OSD operations. We did this to work around many of the limitations imposed in the OSD Design tool. We are now porting this code to work with the ADV7625 OSD. We have found a lot of similarities between the OSD in the two chips so it hasn't been very difficult to do the port.
We understand that you would prefer that we use the Blimp tool for our OSD work but we have way too much invested in the direct OSD code that we have developed to throw it all away and start over in the Blimp tool. We may consider the Blimp tool for future designs but we have to port our existing OSD code from the ADV7623 to the ADV7625 with minimal investment in resources (time and schedule) as we transition our repeater boards to the ADV7625 chip.
We have found one rather significant difference and we are hoping to get some guidance from you. It has to do with the OSD Enable behavior difference between the two chips.
ADV7623 - OSD Enable (OSD map, offset 0x00, bit 7) was very simple, when disabled the OSD was not displayed, when enabled the OSD was displayed based on the enable settings for the various objects (Fboxes, Tboxes, Iboxes). When disabled, we could access the OSD Ram to load new OSD data and we could access the various box enable registers (via I2C) to change them as needed for the next OSD that we wanted rendered.
ADV7625 - OSD Enable (OSD map, offset 0x00, bit 4) when disabled the OSD is not displayed, when enabled (and at least one of the OSD Blend enables is enabled) the OSD is displayed based on the enable settings for the various objects that were last loaded using the Ram Swap. We have found that when the OSD Enable is disabled or the OSD Blend bits are both disabled, access to the OSD Ram is disabled and access to the various object enables starting at offset 0x80 are disabled. In other words, we cannot change the OSD configuration (OSD Ram data or object enables) when the OSD is disabled.
Are we correct in our evaluation that access to the OSD object enable registers (above offset 0x80 via I2C) and the OSD Ram (via SPI) are disabled or unavailable when the OSD is disabled (either OSD Enable is disabled or both OSD Blend bits are disabled)?
Use Case: We have an OSD being displayed on the screen. We then disable the OSD to make it go away for a period of time. Now we want to put up a different OSD. Since we cannot change the OSD until we enable it again, we have to enable the OSD (OSD Enable and at least one OSD Blend must be enabled). When we do this, the previous OSD is immediately rendered on the TV (very quick but very obvious) until we get the new OSD data loaded and perform the Ram Swap.
This is of course unacceptable.
As a work around, when we want to drop the OSD we disable all the OSD objects (loading the object enable controls with zeros, 32 bytes written over I2C bus to disable the Fboxes at offset 0x80:0x87, Tboxes at offset 0xC8:0xCF, and Iboxes at offset 0xf0:0xff). Then we do a Ram Swap and wait for that to complete. Then we disable the OSD Enable. Then when it comes time to put up a new OSD, we enable the OSD Enable, no OSD is rendered because all the objects are disabled, we load the new OSD into the object enables and the OSD Ram and perform the Ram Swap to see the OSD rendered. This works but the disable process is rather lengthy (loading the object enables and waiting for the Ram Swap before disabling the OSD). It used to be so simple on the ADV7623.
So the question is: Is there a better way to transition between states in this use case? In particular, is there a better way to transition between different OSDs where the OSD has to be off for a period of time in between the display of the different OSDs? We would prefer to be able to do what we did with the ADV7623, just simply disable the OSD Enable (very quick operation) and be able to manipulate the OSD object enables and OSD Ram while the OSD is disabled. Then enable it again to display the new OSD.
In a somewhat related question: It seems when we read back data from the OSD register map above offset 0x80 via I2C, we get the first byte as some junk data and then we get the data we expect. After reviewing the Blimp code it appears that this is the correct behavior of the part, but what is the meaning of that first byte, anything of value to me or should I just throw it away?
Thanks in advance for any advice,
BrianP