8051 to DVI interface?

I am working on an 8051-based project that needs a
display. Normally I would just use a small character-
based LCD display, but in this case I am thinking of
going with something a bit more impressive; a standard
flat-panel PC monitor.

This is a small-volume project with no particular cost,
space, environmental or power constraints. The display
is mostly static with a few small areas that change
infrequently. 640x480 would be acceptable, but 1024x768
would be a lot easier to find monitors for. I am also
willing to spring for a fast 100 Mips 8051 if that will
help.

My first thought was having a counter clock data out of
fast RAM into DACS and thus make a VGA signal, with the
8051 updating another bank of RAM and making a fast bank
switch during vertical retrace, but then I started
thinking about DVI interfaces. Normally a PC throws a
lot of fast data at a DVI interface, but would it hold
a static picture with a much slower refresh rate? Or
could I run RAM fast enough to hit a 60Hz refresh?

Another possibility would be some sort of display chip;
does anyone know of one suitable for a slow 8-bit micro?

I am working on an 8051-based project that needs a
display. Normally I would just use a small character-
based LCD display, but in this case I am thinking of
going with something a bit more impressive; a standard
flat-panel PC monitor.

This is a small-volume project with no particular cost,
space, environmental or power constraints. The display
is mostly static with a few small areas that change
infrequently. 640x480 would be acceptable, but 1024x768
would be a lot easier to find monitors for.

Click to expand...

Most Monitors will scan-convert most VGA resolutions.
That's because PCs boot first in 25 line DOS, and then
there is 'safe mode' booting.....

I am also willing to spring for a fast 100 Mips 8051 if that will
help.

My first thought was having a counter clock data out of
fast RAM into DACS and thus make a VGA signal, with the
8051 updating another bank of RAM and making a fast bank
switch during vertical retrace, but then I started
thinking about DVI interfaces. Normally a PC throws a
lot of fast data at a DVI interface, but would it hold
a static picture with a much slower refresh rate? Or
could I run RAM fast enough to hit a 60Hz refresh?

Another possibility would be some sort of display chip;
does anyone know of one suitable for a slow 8-bit micro?

Click to expand...

Not many around for 8 bit uC - volumes are too small
for a chip supplier.

This is designed to sit in usage between monochrome CHAR based LCD modules,
and full Graphics/Pictures Embedded PC apps.
Interface is a superset-variant of the old ANSI escape controls,
(Adds Colour and Font/Scale controls), over a simple serial link.

Wow, what an understatement. It took me over a month of playing with
the ML403 just to get to the stage where I knew where to look for
[xyz]. FPGA tools are unique, quirky and really take some serious
experience to use properly.

Wow, what an understatement. It took me over a month of playing with
the ML403 just to get to the stage where I knew where to look for
[xyz]. FPGA tools are unique, quirky and really take some serious
experience to use properly.

Click to expand...

Mm I started with digilab-2 from Digilent, webpack, couple of hours.
hehe
;-)

Really? It took me an entire day (actually more than an 8-hour working
day) to install ISE and EDK. Much of that time was downloading almost
1GB of mandatory service packs.

Click to expand...

Well I hope you noted the ';-)' smily.....
Yes I had a very hard time with the X software too, and sometimes still.
It has improved a bit (9.1 running now on Linux).
I also use the Quartus from Altera, sometimes it helps to try your design
on both..
OTOH it really did not take that much time once the soft was running, but
I come from a hardware background, so for example Verilog is natural to me.
I do not consider myself an expert on FPGA, but I get along.

Sure, but I'm still curious about whether other people had
difficulties.

Yes I had a very hard time with the X software too, and sometimes still.

Click to expand...

It's really hard to hit the ground running with these tools. For
example, I wanted to start small, by just building a piece of sample
PowerPC code from the EDK CD-ROM and loading it onto the FPGA (already
configured by SystemACE from the CF card). In order to build the code,
EDK checked dependencies and tried to build the bitstream. It
discovered that the Ethernet, I2C and 16550 UART had no license, so I
had to cut out those cores and add the opb_uartlite. In the process I
discovered several places where the GUI fails to make all the correct
changes - you have to edit the mhs files, etc. Of course I only found
this through having the build process fail, checking the files and
editing stuff, trying the build again, ...

I THEN discovered that the synthesis process dies executing
synthesis.sh (I think due to conflict with a newer version of cygwin
on my PC). Found a workaround for that, manually running the relevant
command and then retrying the build operation.

Then the uartlite driver is misnamed, the directory and filename
version numbers don't match. I had to modify the sample code to use
uartlite instead of ns16550, too. Etc, etc. It all feels very much not
ready for primetime.

In summary, it took me two days to build and download "hello world!".
Having example code on the disk that ALL requires further buyware
cores is stupid, IMHO - people need to have a working build
environment so they can use it as a basis for their own projects.

I come from a hardware background, so for example Verilog is natural to me.

Click to expand...

It's funny you say this, because I was going to say I come from
primarily a software background, and VHDL is not too alien to me.

My difficulties rarely come from code bugs, etc. It's more a case of
"I need to simulate this piece of code. Where do I put the stimulus
file, how is it formatted, where do I go in the GUI for this massive
program?" And the time to build everything... at least half an hour to
build the entire project. Wow.

Wow, what an understatement. It took me over a month of playing with
the ML403 just to get to the stage where I knew where to look for
[xyz]. FPGA tools are unique, quirky and really take some serious
experience to use properly.

I'm happy to hear it, and baffled as to why you would think it
remotely relevant. A "course" presumably includes an "instructor" who
has used the tools before. Contrast getting up and running using only
Usenet and free support from Xilinx.

Read my other replies in this thread. As you can see, almost none of
my problems stem from the problems of writing VHDL or C; they're all
setup and IDE familiarity issues.

This is designed to sit in usage between monochrome CHAR based LCD modules,
and full Graphics/Pictures Embedded PC apps.
Interface is a superset-variant of the old ANSI escape controls,
(Adds Colour and Font/Scale controls), over a simple serial link.

It's funny you say this, because I was going to say I come from
primarily a software background, and VHDL is not too alien to me.

Click to expand...

I bought a book about ADA many years ago, did read it, but never used it,
it is still on the shelf,
VHDL reminded me strongly of that book
So I thought 'better stay clear if I can'.
That said, I have seen people do really nice things in VHDL, but it
is so much more work to type ...

My difficulties rarely come from code bugs, etc. It's more a case of
"I need to simulate this piece of code. Where do I put the stimulus
file, how is it formatted, where do I go in the GUI for this massive
program?" And the time to build everything... at least half an hour to
build the entire project. Wow.

Click to expand...

I run Linux, and the next thing I did was run the webpack tools from a script,
with a sort of makefile.
That fixed the GUI issues (no GUI).
An other thing I did was write my own driver in Linux for the Digilab parIII cable.
ftp://panteltje.com/pub/p3j-0.2.tgz

One thing about the X software, I had this filter design, and entered it in webpack
(the old version 8.x do not remember exact sub-version).
It then told me about some register that needed stuffing into something else, and that this
was a bug in webpack, and the next version would fix the bug.
As I needed the filter _now_ that was a bit of a problem.
I tried some code changes, and always got this error, an error that made no sense in
any way actually.
So I asked around, and nobody knew what this was...
So then I thought OK, then I will need to go Altera...
So I entered the design in Quartus, it reported a typo, I fixed the typo, and it synthesised.
Then that made me think, so next day I took the fixed design, and entered it in webpack.
It also synthesised.
So the _syntax checking_ of X software is not up to snuff, or maybe not even present, it will then
make its own design, and get stuck, and report an error on a very deep level that you cannot
possibly trace back to what you did wrong.
And I could not even remember the stupid typo when I wanted to.

So what you actually spend a lot time doing is indeed learning to work around or avoid
X software issues.

Many many years ago I had a Sinclair ZX81 with a BASIC that would check syntax every input line,
you could not enter the line if it had a syntax error.
X will perhaps have to write everything from the start all over again to make it more user
friendly.
It is the same thing with their online-shop.
Microchip shows us how to make an online shop.
X redirects to distributors... that many times have no stock, with very high prices and
long lead times....
In my view they would sell a lot more if you could actually buy things from them directly
and those were in stock

No - Vga text mode (all PCs boot in this first), is 80x25 lines, of 8x16
pixel chars, so that's 640x400.
640x480 just bumps over a standard RAM boundary.

How do you generate the VGA signals?

Click to expand...

Frame and line sync are relatively easy, just chains of dividers in
a CPLD. Dual port RAM access is more complex, but you can just access in
flyback times for a simpler system, a la first generation PCs.

First generation PCs, (like the 6845) also used a character Font ROM,
and they can get by with much less RAM (back then, RAM was expensive),
plus you could not run early RAM at pixel-clock speeds.

If monochrome is OK, a few of the latest uC can do reasonable pixel
rates out of their SPI ports - not quite 2000 chars on a screen, but
some hundreds is doable.

In summary, it took me two days to build and download "hello world!".
Having example code on the disk that ALL requires further buyware
cores is stupid, IMHO - people need to have a working build
environment so they can use it as a basis for their own projects.

Click to expand...

Did you feed that back to Xilinx ?
Typically this outcome stems from simple laziness to test their systems
fully : as most of their PCs will have all the fruit, they
_think_ it all works fine.....

Working sample code is a great learning platform, (and it has to cut
support bandwidth), so it's surprising how many vendors do a poor job here.

I am working on an 8051-based project that needs a
display. Normally I would just use a small character-
based LCD display, but in this case I am thinking of
going with something a bit more impressive; a standard
flat-panel PC monitor.

This is a small-volume project with no particular cost,
space, environmental or power constraints. The display
is mostly static with a few small areas that change
infrequently. 640x480 would be acceptable, but 1024x768
would be a lot easier to find monitors for. I am also
willing to spring for a fast 100 Mips 8051 if that will
help.

My first thought was having a counter clock data out of
fast RAM into DACS and thus make a VGA signal, with the
8051 updating another bank of RAM and making a fast bank
switch during vertical retrace, but then I started
thinking about DVI interfaces. Normally a PC throws a
lot of fast data at a DVI interface, but would it hold
a static picture with a much slower refresh rate? Or
could I run RAM fast enough to hit a 60Hz refresh?

Another possibility would be some sort of display chip;
does anyone know of one suitable for a slow 8-bit micro?

Want to reply to this thread or ask your own question?You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.