I am supposed to write a Device Driver (Firmware) for a VFD module (replacement for LCD). I am new to VFD. I am looking for some reference material and / or source for the same. Let me know, if anybody has pointers for the same.
I am supposed to write a Device Driver (Firmware) for a VFD module (replacement for LCD). I am new to VFD. I am looking for some reference material and / or source for the same. Let me know, if anybody has pointers for the same.
I found this code a while ago, originally in chinese (???) and babelfish translated it, the comments are translated, not mine, hence the bad english. It is sample code for the PS6311. Our project was to decode what was on a DVD Recorder display to work out what mode and status it had.
; VFD DISPLAY CONTROL SUB PROGRAM (VFD 11 BYTE 16 SEG) INI_VFD: ; Initialization PS6311 CLR VFD_STB MOV A, #3AH ; Demonstrates the pattern establishment order character:
11, 17 section of LCALL OUTDATA SETB VFD_STB NOP RET
WR_VFD: ; Writes the demonstration data to PS6311 CLR VFD_STB MOV A, #70H ; Data establishment order character: The normal work, the address add 1 way, writes demonstration data LCALL OUTDATA SETB VFD_STB NOP CLR VFD_STB MOV A, #0C0H ; Address establishment order character: 0 starts LCALL OUTDATA MOV R2, #21H MOV R1, #5FH ; from the address; The demonstration data puts on monolithic integrated circuit RAM 5FH ~ 7FH WR_VFD1: MOV A, @R1 LCALL OUTDATA INC R1 DJNZ R2, WR_VFD1 SETB VFD_STB NOP CLR VFD_STB MOV A, #0BFH LCALL OUTDATA ; Display control order character: Demonstrates, pulse width 14,/16 SETB VFD_STB RET
RD_KEY: ; Reads the PS6311 keyboard data (17) CLR VFD_STB MOV A, #76H LCALL OUTDATA LCALL INDATA MOV KEY_BUF1, A ; The key value data-carrier storage first byte gives KEY_BUF1 LCALL INDATA MOV KEY_BUF2, A ; The key value data-carrier storage second byte gives KEY_BUF2 LCALL INDATA MOV KEY_BUF3, A ; The key value data-carrier storage third byte gives KEY_BUF3 SETB VFD_STB CLR VFD_STB RET
OUTDATA: MOV R0, #08 ; Transmits byte SETB VFD_DOUT OUTDATA1: CLR VFD_CLK RRC A MOV VFD_DOUT, C SETB VFD_CLK DJNZ R0, OUTDATA1 RET
INDATA: MOV R0, #08 ; Reads in byte SETB VFD_DOUT INDATA1: SETB VFD_CLK CLR VFD_CLK MOV C, VFD_DOUT RRC A DJNZ R0, INDATA1 RET
Noritake/Itron do VFD modules that are software compatible with the ubiquitous HD44180 LCD driver chip. So they can simply drop-in as replacements. There are additional controls for intensity, but not hard to adapt existing LCD driver code to control them.
Some VFD modules (especially from Noritake) are intended as direc replacements (except electrical specs like current consumption) for th standard LCD modules. You haven't said that this is what you mean b "replacement for LCD". If it is, then there will be plenty of cod available depending on your processor and whether you want a high leve language implementation.
A little more detail will advance your query.
This message was sent using the comp.arch.embedded web interface o
Then why the !$%^ are you posting to comp.os.vxworks and comp.os.linux.development.systems. Your breach of standard Usenet edicate doesn't make you or your company (or your nation) look good. Bigots need few excuses!
Please post in just one group and wait for a response. I know you think you are an important person [most people do]. But cluttering Usenet with irrelevant post is going to help drive people with answers away. Try to google "Usenet FAQ". For instance,
"
formatting link
"
There are many more, but as you are an important person I have tried to save you the time. Most of the information you require could be found through a little searching with google. Especially, you can use google groups to see if the subject was discussed in a usenet group (comp.os.vxworks, etc). VFDs are not discussed that frequently in comp.os.vxworks. I think your question is way off topic for posting in c.o.v given that you don't require an OS.
I have set followups to "comp.arch.embedded,sci.electronics.design". I am not sure that they are relevant... but I wouldn't want to overstep my liberty.
I would email this directly, but I want all the other nice people in comp.os.vxworks, comp.os.linux.development.system, comp.arch.embedded, and sci.electronics.design to know that this thread is cross posted so they can make an informed decision upon replying.
fwiw, Bill Pringlemeir.
--
A mind that is stretched to a new idea never returns to its original
dimension - Anonymous
vxWorks FAQ, "http://www.xs4all.nl/~borkhuis/vxworks/vxworks.html"
I did not ask for Linux or VxWorks Device Driver Source for VFD. However, It does not really matter for me for which operating system the driver was written. All I wanted was to get the feel of programming the VFD, its operations, features and functionalities from the Software perspective. In other words some C or Assembly Code that programs the VFD irrespective of Operating System.
I can understand your anger and your expression.
Please read my initial e-mail on this subject one more time.
What possible use is this monstrously cross-posted and information-free article supposed to have? It quotes nothing, has no context, and even lacks sentences. It simply annoys the majority of readers.
If you must play on the foul google usenet interface, at least learn to use what is there in a reasonable manner. That involves using the reply mechanism at the top of a message, rather than that at the bottom. Spend some time reading the links below.
--
Some informative links:
news:news.announce.newusers
http://www.geocities.com/nnqweb/
http://www.catb.org/~esr/faqs/smart-questions.html
http://www.caliburn.nl/topposting.html
http://www.netmeister.org/news/learn2quote.html
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.