...
IT WORKS!!! *fireworks and explosion sounds*

It is absolutely rock solid and not one pixel jitters at all. I would have never thought of putting a xtal in there to "tighten" up the clock.
...

Yay! Congrats!

But where's the victory photos?

...
I have a number of VGA projects planned that will be of interest to AAC members and hobbyists in general. We will begin with a primitive "Pong" game and then take it from there.
...

I'm still waiting for that "one chip serial->VGA driver"! The one that accepts serial input and writes 80char x 40lines colour text to the VGA, and can draw simple lines etc.

That would put you on the map.

 

RB, you've had a head start on me but it's in the works, 640 x 480, text and graphics. Monochrome for now.

 

I won't accept 80x40 text. I want the ability to place text on the screen at graphic resolution, in a range of sizes. But just to show how reasonable I am, I'll take it if the text comes in only a few discrete sizes, and I only need horizontal or vertical orientation, though angles would be nice to have.

"Draw simple lines" must include circles and arcs. I think it would be unfair to ask for arbitrary shapes, though.

 

RB, you've had a head start on me but it's in the works, 640 x 480, text and graphics. Monochrome for now.

That sounds wonderful! I'm not sure what you mean by the "head start" as I'm not designing one, I'm too busy with commercial product work for the next year or two.

I'm happy to offer suggestions for a serial data protocol, but a lot of what I would suggest for the actual display function would be based on the standard and proven 640x480 SVGA type.

I won't accept 80x40 text. I want the ability to place text on the screen at graphic resolution, in a range of sizes. But just to show how reasonable I am, I'll take it if the text comes in only a few discrete sizes, and I only need horizontal or vertical orientation, though angles would be nice to have.
...

Angles?!! Oh come on you're just being mean.

The 640x480 is the most common and well supported screen type, and the 80x25 80x40 etc text types are also a standard that fits 640x480 very well.

If the device allows pixels to be written as graphics, especially a "byte" of horizontal pixels, it's very easy to the user to implement a "graphic font" of any type they want. That does not need to be part of the VGA generator IC. Like most traditional display standards it only really needs one fixed-size fast displaying font.

...
"Draw simple lines" must include circles and arcs. I think it would be unfair to ask for arbitrary shapes, though.

I'll disagree with that too, the screen driver IC doesn't need to produce complex graphics, and it's actually counterproductive as it limits to one way of doing things.

For example if you are using a 320x240 LCD/TFT in an application, the TFT display does not make circles! You write text to screen with the display's inbuilt font, or if you want any graphics you write pixels to the display, entirely under the control of your app. A "line" function inside the display is easy to implement and quite useful, but even that is an external task with most displays.

So personally I would prefer a functionality of a "VGA driver IC" to be very similar to the functionality of all the common graphics displays, so with your micro project you have a choice; "Does this project need a 320x240 LCD or a 640x480 VGA screen?" and the code you use in your project is very similar.

 

By "head start", I mean, didn't you already build a PIC to VGA, as posted at the beginning of this thread?

 

I was partly enjoying hassling the guy over his plan to build the VGA driver, but I do think there's a serious point. I'm imagining having a small processor (PIC16Fsomething) driving what might be quite sophisticated graphics. Of course as we all know, Turing proved that any processor can run any algorithm, but to be realistic, you have to match the processor to the job. The job becomes easier, or the processor can do more, if the most complicated stuff is outsourced, so if there's going to be a graphic controller at all, why not ask for it to have more than the absolute minimum of capabilities? Let the processor give simple instructions, and let the graphic controller do the hard work.

 

By "head start", I mean, didn't you already build a PIC to VGA, as posted at the beginning of this thread?

Yeah, but it's not really useful for much. I wanted to see if the PIC 18F could do 10 megapixels/sec output, as that is the top limit of what the SPI module can output. Which it could do (and even some simple line colours), but the PIC has little timeslice left for doing processing so it's not worth working on a serial->VGA project using a PIC 18F.

But you were working with a high powered much higher speed processor, which makes it a viable (and extremely cool) project.

...
The job becomes easier, or the processor can do more, if the most complicated stuff is outsourced, so if there's going to be a graphic controller at all, why not ask for it to have more than the absolute minimum of capabilities? Let the processor give simple instructions, and let the graphic controller do the hard work.

I agree totally from an end user perspective that more features is better than less features! But as a designer it can be beter to have a minimal set of "standard" features that work really well, and it's also less work for the designer which can be the difference between success and giving up on the project.

To just write text and pixels (and maybe lines) only needs one or two bytes to be sent by the serial, so it keeps comms fast and simple, which is good for a small micro controlling it. Once you add too many graphic features in the display the serial comms becomes longer and more complex and slower. That's part of the reason that commercial LCDs etc are quite simple and don't try to do graphics internally. A lot of LCD modules now just accept pixels, they don't even have internal fonts.

But of course it's MrChips' baby and it's going to be up to him what features are included. I'm just one little voice here.

 

Here are the results so far of my VGA Scope.
This is not a computer simulation. This is a real-time signal of a 4KHz sine wave.
I still have to do the frequency spectrum and so many other neat ideas.

 

That certainly looks nice!

 

It sure does! Congrats!

The font and resolution (which is the 640x480 you mentioned before?) look great.

I noticed you even made a little mouse icon? Very cool.

Were yuo still planning to make the serial->VGA single chip driver project?

 

Thanks guys.

The goal was 640 x 480 but I'm running at 512 x 480 now. I'm running at half the available pixel rate so there is room for SVGA.

With the arrow cursor I plan to use a mouse to select buttons on the screen. A touch sensitive screen would be nice but the idea is to keep the cost down.

As for the requests for various graphics and font features, it ain't gonna happen. Sorry.
This is not going to be a "do it all" graphics controller. At least this time around you will get the following:

512 x 480 graphics, monochrome
8 x 12 character font
cursor
buttons
basic line drawing functions - lines, rectangles, filled rectangles

I haven't figured out how to do color as yet.

I'm sure you can understand putting restrictions. My applications are for specific electronic and scientific instrumentation:

digital oscilloscopes
waveform analyzers
spectrum analyzers
transistor curve tracer

As for a serial to vga controller, this would be counter-intuitive. The ARM chip I am using would run circles around any PIC. There is lots of processing power remaining and hence the single chip can do much more. I will continue to think about this and perhaps find the lowest cost ARM chip for this purpose. Under $10 is still possible.

 

...
This is not going to be a "do it all" graphics controller. At least this time around you will get the following:

512 x 480 graphics, monochrome
8 x 12 character font
cursor
buttons
basic line drawing functions - lines, rectangles, filled rectangles

Those features are great, and would be anough to allow many projects.

...
As for a serial to vga controller, this would be counter-intuitive. The ARM chip I am using would run circles around any PIC. There is lots of processing power remaining and hence the single chip can do much more. I will continue to think about this and perhaps find the lowest cost ARM chip for this purpose. Under $10 is still possible.

Huh? But that was the whole point! How are people going to use the display? If it is a one chip solution that accepts serial commands (and only one wire needed to drive it!), anyone on the forum can connect the chip to any of their existing microcontroller projects, regardless of what micro they use or what language they prefer. It would be a very popular and cool serial->VGA chip. And something you could sell as a chip, or chip+PCB.

But if it's just a code library for an ARM chip then you limit your user base to the maybe one in a thousand people on the forums who actually use ARM chips and have the skills and desire to make use of your library in their own ARM projects.

 

Thanks for the comment. I will see what I can do.
I have not looked at any graphics protocol but HP-GL is the first that comes to mind.
What's your opinion?

 

I see the big user base being people like Basicstamp and Arduino users. Probably 200 or 300 thousand potential customers for you just in those two groups, then add in another 200 thousand hobby PIC and AVR users.

These people are already competent in simple serial comms, ie; put the byte in the UART and it gets sent to the display device.

My suggestion would be to make your own protocol and keep it very simple, with most commands just one or two bytes. Many people are familiar with text LCDs, where you write the address for row and column, and after that each byte you write is one text character which also auto increments the position. Only 2 bytes to write row and column (with spare bits for colour later). Then one byte for each text character after that.

And for line graphics, 2 byte commands to send X1, X2, Y1, Y2 and it would draw a line.

To send 8 pixels, 2 byte commands for X and Y, then one byte writes the 8 pixels (with an auto X or Y increment ready for the next 8 pixels). This allows custom fonts and icons etc.

Basically you need to keep it brutally simple. Also send the minimum bytes for simplicity and to speed up drawing times when using simple microcontrollers!

I would REALLY avoid anything like checksums, handshaking, "packets" or any "proper protocol" that makes bloated and scary complex comms.

As a starting point you could make it default to "command" if no serial is received for say 1mS. Then it starts with one or two command bytes, followed by any number of data bytes.

All the user needs to do is send the 2byte command and if needed send the data bytes with no delays. Brutally simple and any person can write their own code, on any platform.

For ideas you could google for popular accessory display products already receiving serial from Stamps and Arduinos, to see the simple serial commands that people are already using with other display etc accessories.

 

Oh, it's an ARM chip, not a PIC! I'm not entirely sure what an ARM is capable of doing, but I was skeptical about a PIC doing this job. Now I'm not.

I agree with Roman Black--you can make up the interface any way you want, but keep it simple. Remember that the user will have a processor with limited capability. I continue to think that if you can figure out ways to give this thing graphical ability beyond the rock-bottom level, you should, because the user's processor would really get bogged down on anything involving math.

 

Thanks for the feedback. I will look it over. I am very experienced with developing comm protocols and agree with what you say about checksum, handshake, simplicity and efficiency.

I have one question.

Would you prefer readable text only or binary?
For example, an x,y point can be specified using text such as 400,500 or as 4 bytes.

 

Definitely binary. It takes less bytes, and in someones (small) code their variables will be binary and you can just UART the variable as one or two bytes.

If you use text the user must convert all variables to text strings.

Also, in binary there will probably be spare bits (say using a 16bit var for X pixel address 0-639) so you can use the spare bit(s) for type of command, or additional data like colour, or pixel on/off etc.

That's still easy for the user, they copy the binary variable, set or clear a bit and put it in the UART.