Simple OLED driver

Brendan Cassidy said:

OLED display connected via a serial port (this is an existing piece of hardware we are stuck with).

It's a small display 64*96 requiring only 5-10 frames per second (a preview display), expecting the data in BGR565 format..

...

It seems that the VPBE is not going to help me, or have I got that worng?

What does the serial interface look like for the OLED display?  Is this something like a SPI interface?

If so, I would agree the VPBE will not be appropriate for that type of interface.  Perhaps I'm not understanding the serial protocol correctly.

Hi Brandon

Unfortunately, you probably are understanding correctly!

We have a display with integrated SSD1332 controller.  This is mounted on a board with a PIC processor.

The DM335 communicates with the PIC via Async RS232 - far from ideal, but we are stuck with that design.

I have also realised that it is the VPBE that handles the OSD, we were hoping to use that OSD.

Is there a way of picking up the data after the VPBE and then passing it to my display?
Sounds like a silly question, but some times there are data paths that are not apparent on the simplified block diagrams.

Or any suggestions for OSD?
We could do it manually, the requirements are simple, it's just an extra job to do!

Thanks.

Brendan Cassidy said:

I have also realised that it is the VPBE that handles the OSD, we were hoping to use that OSD.

Is there a way of picking up the data after the VPBE and then passing it to my display?
Sounds like a silly question, but some times there are data paths that are not apparent on the simplified block diagrams.

I certainly understand your request and it does come up every now and again.
Unfortunately the OSD in the VPBE only outputs to the external interfaces and there is not a way to pick that back up by sending the output of the OSD back to DDR, or something similar.

Brendan Cassidy said:

Or any suggestions for OSD?
We could do it manually, the requirements are simple, it's just an extra job to do!

The only suggestions I would have would incur additional expense with external devices (which might not work anyway) or do it in software running on the ARM9.
My thought on the external device would be to capture the data from the VPFE output and somehow either get it back into the DM355 via a serial port or if there was another path to your LCD controller device, the PIC processor.
That doesn't sound too attractive and would definitely add cost.

Your display resolution isn't too big, nor the frame rate, so a software solution might be possible, although certainly not ideal.

Thanks for your comments Brandon,

Looks like it's a software solution....

So now I have had some time to think about this and let things settle down a bit, here is what I think we have to do.

So the block diagram is a simplified view of what I need to do.

To get the data from the VPFE to the display driver I could do a simple mem copy then do a scale down, colour convert and apply my OSD layer before sending the data on to the display.

OR....

Can the V4L2 devices help me?

I have been looking at the documentation and am a little confused, but it looks as though I could:
Use one of the frame buffer devices to receive the Ycbcr data, say /dev/fb/1

My display driver reads the frame buffer, asking for that data in RGB565 at 96x64.

Possibly, making used of /dev/fd/0 for my OSD layer.

It this approach a sensible one? or am I really as confused as I feel?

FYI, Linux Frame Buffer driver (often referred to as FBDev) and V4L2 (Video for Linux 2) are standardized Linux drivers.  You can probrably find documentation on the user level APIs these drivers define on the internet; in addition, you will also find documentation on them under the Linux Kernel tree included with the DM355 DVSDK  (e.g. ti-davinci/Documentation).  Finally, I believe you  will also find some minor documentation on these drivers under the PSP directory (.../dvsdk_1_30_00_41/PSP_XX_XX_XX_XXX/).

Brendan Cassidy said:

Can the V4L2 devices help me?

I have been looking at the documentation and am a little confused, but it looks as though I could:
Use one of the frame buffer devices to receive the Ycbcr data, say /dev/fb/1

My display driver reads the frame buffer, asking for that data in RGB565 at 96x64.

Possibly, making used of /dev/fd/0 for my OSD layer.

 

It this approach a sensible one? or am I really as confused as I feel?

As Brandon mentioned, there is no way of using the VPBE hardware (which the /dev/fb/ would be using) to implement the OSD without having the data actually displayed out of the device through the VPBE, so the existing display drivers will not be of much help in implementing your OSD. Of course if you had some way of adapting the VPBE output to work with the display you could use it, but there is no way of getting the display output back into DDR to be sent out in your OLED driver without feeding it back in through another interface (optimally the CCDC which you are already using).

Thanks to Bernie and Juan for the feedback.

Is it a correct assumption then that for example /dev/fb/1 is "hard-wired" via DMA to the VPBE.

so any data written to this device will always end up at the VPBE and so out to the TV out connector (in the decode demo case).

Is it no possible to treat these as a sort of virtual device such that a writer thread sends data in to be converted and a reader thread can access the converted data in the frame buffer memory?

If this is not possible using the davinci-fb driver then what about the V4L drivers.

Or perhaps it's time to abandon this approach and just roll my own conversion.

Views form the more experienced will be much appreciated.

Brendan Cassidy said:

Is it a correct assumption then that for example /dev/fb/1 is "hard-wired" via DMA to the VPBE.

so any data written to this device will always end up at the VPBE and so out to the TV out connector (in the decode demo case).

This is correct for the drivers as they are, of course you have access to the source so you could rewrite the driver to do whatever you want, but you will find that the hardware it uses can only output the OSD mixed video to the VENC (i.e. the TV out connector or an external digital device) which is what Brandon and I were trying to get at earlier. The same applies to the V4L2 drivers, this is really a hardware limitation as opposed to a Linux driver limitation.

Bernie Thompson said:

This is correct for the drivers as they are, of course you have access to the source so you could rewrite the driver to do whatever you want, but you will find that the hardware it uses can only output the OSD mixed video to the VENC (i.e. the TV out connector or an external digital device) which is what Brandon and I were trying to get at earlier.

Yes, I can see that and am resigned to this fact.

Bernie Thompson said:

The same applies to the V4L2 drivers, this is really a hardware limitation as opposed to a Linux driver limitation.

The $64000 question is what are the mechanisms to achieve the desired effect?
I'm still trying to get my head around this (and my head now hurts).

But ultimately, if the TMS320 hardware cannot help, then it requires ARM cpu cycles to do the work no matter where the work is done.
A conversion done by hand is fairly straight forward, overlaying a simple OSD should also be simple-ish, given my low screen resolution.

Brendan Cassidy said:

The $64000 question is what are the mechanisms to achieve the desired effect?

The VPBE's OSD module uses hardware to mix the pixels together as you define by the driver, it is basically a massive summation/averaging operation so it is easy to do in parallel fashion with custom hardware. In software you have to go pixel by pixel and blend the OSD and the video together if you wanted to have the exact same functionality, if all you want is to have a simple OSD on top of (not blended with) the video than you can just copy your OSD data into your video window using the CPU, or even the DMA for extra performance. As you mention, given your small resolution this should be very possible on the ARM, though less efficient than using the VPBE with a more typical display, using a software OSD in a case like this seems to be the easiest route.