Does this display driver exist?

Go To Last Post
11 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm trying to find a display driver that can drive a VGA and/or HDMI output at 1280x720 with 8-bit color. I've found a lot of LCD drivers, but I'm coming up empty on VGA/HDMI drivers. Ideally it would have a built-in frame buffer, but it would also be acceptable if it used external SRAM.

 

If that doesn't exist, would something like an Atmel SAMD have enough horsepower to bit-bang at least the VGA, if not the HDMI? I've never worked with VGA/HDMI before other than the canned libraries on the Propeller so this is all new territory for me.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What does Raspberry Pi use? 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As far as I know the HDMI output on the RPi is integrated into the Broadcom SoC. It looks like 1280x720 is going to be a bit much to ask due to the pixel clock being almost 84 MHz, but I might give it a try with the SAMD driving 640x480, which I could use if I had to. All I want to do is display some large numbers on a VGA screen.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why is 1280x720 going to be a bit much when the hardware does it natively?
With higher video resolutions, it is unlikely you would 'bit bash' it in software - not impossible, but you'd normally do the high speed stuff in hardware which is what the raspi does as do many chips.
Trying to bit bash timing critical things ( like video) becomes difficult with high speed processors such as the ARM cortex A (application) series as they use cache memory. This causes the execution time to be non- deterministic - ie a given set of instructions can take a variable amount of time to execute depending of the state of the pipeline, cache and memory access.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Good point on the caching. I hadn't thought of that. The SAMD is a Cortex-M processor but I still suspect that it might not be as deterministic as an 8-bit AVR. Since this is for a one-off project that popped into my head the best way is probably just to get the data to a Raspberry Pi somehow and use that to drive the screen, but I wanted to explore the possibility of doing it with simpler hardware if possible.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

'Simpler hardware' is a relative term! You're going to need at least 1M of ram for a frame buffer and some means of accessing it. The pi does it pretty simply - the soc and sdcard. And you've got plenty of ram and processing to do high frame rates. There's also the Android tv dongles like the mk802 and later versions. Hook up a Arduino to do the i/o - problem solved.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Simpler in terms of parts, not in terms of implementation complexity. But now that I think about it more, sending data to a Raspberry Pi is going to be a lot easier even if it costs a little more in terms of parts. If anyone knows of an off the shelf VGA driver IC I'd still be interested to hear about it.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The SAMD is a Cortex-M processor but I still suspect that it might not be as deterministic

Cortex M0+ has a 2 stage pipeline. Other Cortex M have a 3 stage pipeline.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Don't bit-bang; use the in-built peripherals. Use SPI and drive it with a DMA channel.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

microcontrollerguy wrote:
I wanted to explore the possibility of doing it with simpler hardware if possible.

How about an FPGA or CPLD, then ... ?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was looking at my FPGA dev board (with VGA port) while I was making the original post, but that would be an expensive sacrifice to put it in a permanent installation, and I don't have a programmer for the standalone FPGA chips. Looks like RPI will be the answer to this one.