7

I'm looking for a way to control a VGA screen with a PIC. External components are OK, so a VGA chip with I2C or SPI or something is okay too.

Requirements:

  • Resolution: max 1024x768, no minimum
  • Language: C (C18 compiler) or Jalv2
  • Only text, no graphics necessary (but it would be okay if it had that too)
  • One colour is enough, so DA converting is out of the scope of this question

In my project I have a text buffer which I want to have on a screen. You can compare it to using an LCD display for text displaying, but now with VGA.

  • What are you trying to do? A PIC does not have any video hardware, nor is there any de-facto standard video hardware used with PICs. Any software will be specific to a particular hardware setup. – Dave Tweed Jan 08 '13 at 14:03
  • In my project, I will have a buffer of text. I want that text on the screen. I want to have the option of VGA output instead of an LCD screen, for when I want to connect the device to a beamer or so. I know it is [possible](http://tinyvga.com/), but that's with ASM, and I want a C/Jalv2 library. But as an answer to your question: I want to put a text buffer on the screen. –  Jan 08 '13 at 14:08
  • 1
    The right PIC might be able to produce VGA signals with careful coding, but that won't be easy. What hardware do you intend to provide between the PIC and the VGA output? – Olin Lathrop Jan 08 '13 at 14:24
  • I actually didn't think of that, so no restrictions within the reasonable. It's also OK if there a VGA chip is available. Is there? (also, I edited the post to make this clear) –  Jan 08 '13 at 14:33
  • 2
    A text buffer of what dimensions? Can you dedicate most of the processor's power to servicing the display? Off the top of my head I'm not aware of self-contained "VGA chips" but you could make a self contained SPI or serial display slave with either a small FGPA or a second microcontroller, either one with a very high clock rate and/or DMA (some of the ARM cortex parts perhaps) or one designed for odd tasks such as a parallax propellor. If you are okay with limited colors, your elecrical interface can be just a few resistors. – Chris Stratton Jan 08 '13 at 15:32
  • I would change the dimensions to as big as the solution can handle, but I need at least 60 characters horizontal and 16 vertical. I can dedicate most of the controller's power to servicing the display. This question is meant to build an I2C slave. I don't quite get what you mean with FGPA? –  Jan 08 '13 at 15:37
  • +1 for Parallax Propeller! Really nice and really powerful microcontroller, but the development process is a bit quirky. On the downside, it' around $7 and requires external EEPROM and crystal for VGA. It can do quite a few colors using just resistors for DAC. – AndrejaKo Jan 08 '13 at 15:42
  • Sorry, forgot to mention that one colour is enough. Edited the post & sorry for any caused confusion. @ChrisStratton why would I use a parallax propellor instead of a PIC? –  Jan 08 '13 at 15:44
  • 2
    One, to just offload the very busy task of constantly repainting the display to leave your primary processor free to contemplate what should be on the display. Two, because it's faster, has multiple cores, and people have done video displays with it. An FPGA would give even more flexibility, but has a high learning curve and is substantially more expensive including support components. – Chris Stratton Jan 08 '13 at 15:49
  • Okay, you can submit that as answer. Do you have a link to a working thing with the parallax interfacing a VGA screen? Please share! I will accept it unless there will be better answers (using a PIC for example, which would be cheaper). –  Jan 08 '13 at 15:51
  • 2
    @Camil Staps Take a look at code for the [Propeller Demo Board](http://www.parallax.com/Store/Microcontrollers/PropellerDevelopmentBoards/tabid/514/CategoryID/73/List/0/SortField/0/Level/a/ProductID/340/Default.aspx) for example. It does PS/2 keyboard and mouse, displays on Composite output and VGA, samples from a microphone and plays back, all at the same time. Another place to look is the [Object Exchange](http://obex.parallax.com/objects/category/3/?n=100). There are many VGA objects there available for free. Also there are VGA demos which come with the IDE too. – AndrejaKo Jan 08 '13 at 16:02
  • Ooh, that Object Exchange is a very nice thing, thanks for linking! Now just waiting for the parallax as an answer / a PIC-based answer / another answer. –  Jan 08 '13 at 16:12
  • As much as I like the Propeller chip (I got one of their Professional Development Boards, when they were on sale for $100), if you want to use the Propeller as a peripheral so you off-load the main processor, then the Propeller won't work very well without same additional memory. The Propeller has only 32K of global RAM, and you really need a complete frame buffer: 1024x768 = 768K bytes so the video can be refreshed continuously. – tcrosley Jan 08 '13 at 19:25
  • How do you come to 768Kbytes? I'd say `1024 * 768 / (6*8) = 16384`, so 16.4Kbytes, since I'd use a 5x7 font. You don't need one byte per pixel, right? Also, the 1024x768 was a maximum, fewer is fine too. –  Jan 08 '13 at 21:17
  • @tcrosley - actually I don't think this application requires a frame buffer at all. Instead, one can use a character buffer (64*16=1K), and do on-the-fly rastering to pixels while scanning the display. This would be comparable to running a PC display in text mode rather than bitmap graphics mode. Add a little cursor control logic and set it up to interface to the interactive portion via a serial port or mailbox registers/fifos... – Chris Stratton Jan 10 '13 at 15:12
  • @ChrisStratton You're quite right, I had forgotten he only wants to do test. Then the Propeller looks like a good solution. The chips are only [$8 apiece in single quantities](http://www.parallax.com/tabid/142/List/0/CategoryID/18/Level/a/SortField/0/Default.aspx), and you can get them in a DIP package. – tcrosley Jan 10 '13 at 16:19
  • DarioG on the Microchip.com forums made a video generator from a DSPIC and posted the project for others to use. http://www.microchip.com/forums/m880978.aspx – user4574 Mar 31 '16 at 19:14

2 Answers2

3

If it's not overkill for your application, you could add an ISA interface to your PIC and pick up an old video card somewhere.

However, supercat points out there's no PC to run the video BIOS, so probably this wouldn't work.

I did find a post on hackaday doing a similar thing with an AVR that might be good for inspiration.

Phil Frost
  • 56,804
  • 17
  • 141
  • 262
  • Ooh, nice! Certainly have to think about this for future projects, thanks for linking & +1! I'm afraid it's an overkill for this project though.. –  Jan 10 '13 at 14:22
  • Nice indeed, forgot all about that. I think there may even be VGA cards which can function with only the 8-bit ISA connected; there certainly are hercules, EGA, etc cards which might be able to be reprogrammed to the needed timings. – Chris Stratton Jan 10 '13 at 15:16
  • A sufficiently-antiquated VGA card should work with an 8-bit bus, but the I/O requirement for even an 8-bit bus is going to be sufficiently huge that one may as well spring for 16-bit access. A problem one is apt to have with VGA cards, though, is finding out what initialization sequence is required for any particular card. Even cards which are "100% VGA compatible" will often have to be initialized in various non-standard ways prior to use. Since every VGA card includes a BIOS ROM, this is not aproblem when the card is plugged into a PC; the PC will run the code in the ROM, which will... – supercat Jan 10 '13 at 17:09
  • ...perform the appropriate initialization for any registers which did not exist on the original VGA. Unless you plan on writing an 8086-emulation library for your PIC, however, the initialization routines supplied in the ROM are apt to be quite useless. – supercat Jan 10 '13 at 17:10
  • @supercat you are probably right, I forgot about the video BIOS. – Phil Frost Jan 10 '13 at 17:12
  • @PhilFrost: There are times when interfacing with ISA-bus devices can work out pretty well without using a totally outrageous number of pins (e.g. if I recall, an 8-bit device which maps to 4 I/O addresses would require 8 bits for data, 2 for address, /IORD, and /IOWR. Twelve bits.) An 8-bit VGA card would require at absolute minimum 8 data, 17 address, /IORD, /IOWR, /MEMRD, /MEMWR. Thirty bits. Maybe one could omit /IORD, and in some cases perhaps /MEMRD, but still--that's a lot. – supercat Jan 10 '13 at 17:18
  • @supercat: plenty of microcontrollers manage to interface with ISA devices anyway. Shift registers for the win. – Phil Frost Jan 10 '13 at 17:21
  • @PhilFrost: Clocking out 32 bits for every display operation doesn't seem like a recipe for speed. I suppose one could use shift registers for some bits while keeping the data, the lower eight address bits, and /MEMWR as dedicated ports. The VGA could set the number of characters per virtual row to a 128 (independent of the number of displayed characters), so no row would cross a 256-byte boundary. If one was only going to use text, one could use 16-bit mode but use a shift register for the upper data bus; that would expedite writing many characters with the same color. – supercat Jan 10 '13 at 17:56
1

It is likely that the circuitry required to add a VGA display to a PIC will exceed the cost and complexity of using a different chip which could provide a display and also do whatever the PIC was going to be doing, or else using something like a Raspberry Pi to provide the display and having it communicate with the PIC via a UART or something similar (I think the Raspberry PI has at least one UART among its I/O pins).

If your goal is to build yourself a VGA subsystem so you can learn how such things work, a VGA interface at 640x480 requires the ability to clock out about 32 million pixels/second. That's going to be a fair bit beyond the abilities of an "unassisted" PIC; you probably wouldn't have to add much hardware to a PIC to allow it to output text if you didn't mind having the display hogging up the processor during the majority of each frame, but the PIC likely wouldn't have time for anything else; each scan line would require that it execute a 160-instruction sequence something like:

movf  POSTINC0,w,c
movwf PORTC,c

starting on just the right cycle, and running without interruption [hardware would blindly grab character data from PORTC at the moment it was supposed to be there, feed it through a character-shape ROM, and load it into a shift register].

If you did something like that, it might be possible for a 32MHz PIC to generate 80x25 text using something like a fast (25ns) 32Kx8 ROM to hold character shapes and serialize them, a 3-bit counter to clock out the pixels of each character, and a few miscellaneous gates; one could probably use one of the PIC's PWM modules to handle horizontal sync. This approach would provide an 80x25 matrix of tiles which could each be any of 256 shapes; each shape would be 8x16 pixels, and any combination of 256 colors [for simplicity, figure the colors would probably be RRRGGGBB or something like that]. If one had trouble finding a fast enough 32Kx8 ROM, one could use a fast 32Kx8 RAM instead, and provide a mechanism for feeding data into it on system startup.

supercat
  • 45,939
  • 2
  • 84
  • 143
  • But Raspberry Pi doesn't do VGA. – AndrejaKo Jan 10 '13 at 16:06
  • @AndrejaKo: Ah, okay. If you need VGA in particular, there are probably still some other single-board computers which could do the job for less than the cost of engineering a custom solution. Going the PIC route may be educational, though. The quantity of circuitry shouldn't be unreasonable, and you could probably still find everything you need in easy-to-hand-solder through-hole parts. BTW, adding some counters, an off-chip RAM, and a little glue logic would make it possible to have the video generated continuously without PIC involvement, with the caveat that the PIC... – supercat Jan 10 '13 at 16:43
  • ...would have to properly time its display writes to ensure that they coincided with the times display data was available; adding a bit more circuitry could ease that requirement. – supercat Jan 10 '13 at 16:47