VFDs

Hi Matt,

Using dot matrix, you have to multiplex the Row and give a command on the columns. It 'is itself very easy, but you have to make sure about the current specification of your dot led matrix. The most important thing is the compromize between the current of each led on one Row and the rom multiplexage. In normal use, you drive LED with static 10mA or 20mA, but in the dot matrix case you need to drive something between 50mA and 100mA dynamic PWM current by led. So, your CPLD CMOS specification will not be able to drive so much PWM current. You have to use line driver or MOS-FET N and P after your CPLD.

If you will play on 3.3V, you have to work with a transistor having a small Rds (Drain Source Resistor), not more 1.5 Ohm.

We are doing a dot matrix module for our SPARTAN-3 rapid prototyping platform. I will receive the PCB in two weeks, I can send you a sample of our dot matrix board if you want.

Let me know

Laurent

I looked at using various VFDs for use in audiophile radio several years ago.

They are quite a significant cost, and quickly rises with number of pixels.

I liked the idea of graphic VFDs, and the ones with driver chip-in-glass looked nice but these are essentially HV shift registers and the pixel to bit position mapping is rather inconvenient. The sales rep stretched the truth by saying they can be driven by an AVR. I worked out that it would have to be spending c. 85% of its time shifting in the pixels.

A colleague managed to drive such a display with c. 5% of CPU time, by using DMA to transfer the bits. However, that was with an H8. This was not economical in the radio.

Your project certainly sounds feasible. VFDs want supply rails applied in particular order, and can be destroyed if scanning stops (just as TV tubes don't like the electron beam to stop. So I feel hardware is better than software-driven refresh since the latter could crash. Logic gates can handle the bit-to-pixel mapping far better than software.

Will you be using this CPLD with a micro, and if so what type? How would you like the micro to access the pixels? Memory mapped? How fast will the display be expected to change? Will you be wanting animations, smooth scrolling, etc?

=_NextPart_000_0071_01C396E4.F56A9A60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Laurent,

I am using a Noritake Itron VFD module which has its own in glass = driving module and an Atmel Micro on the pcb which does all the hard = work. You have to send it some setup commands and then the data which is = fairly simple stuff. The problem I am finding, is that these modules = want to be set a load of commands once, and of course cpld/fpga runs off = a clock. So you have to right your code is such a way that the signal = which is clocking the data into the VFD is inhibited after the data has = been excepted.

After a good days work on it I have got a single character to be = displayed, progressing from this wont be that difficult although I thimk = that graphics may be out of the question.

In the end I hope to write a package which will have a number of = functions to make it easier for others to program this type of VFD = module. i.e. print("string", cursor_pos, font size)

For interest, here is the VFD I am using: GU254x32D-K610A4 - =

Thanks for your interest,

Matt=20

matrix

CPLD.