arduino for vfd

Appreciate your response and honesty. Addressing the link you provided, I provide the following information. I have been on this apparently simple task at work for quite some time (since April 12th.), first trying to get a PIC18f458 to operate the display, and because of numerous connectivity and uploading problems, switched to the uno. Fairly new to embedded programming and using forums and the PIC and the arduino; so pardon my non-use of code tags last time around; had to look up what that was. Anyhow, for the program I uploaded , I used the portB 8bit single port sketch I derived from the egs, which compiles; all the sketches when modified, do. I'm getting:
data pin 0 3.1mV
data pin 1 has 4.9volts
other data pins 4.06volts, (logic 1 for activation)
the rs,en pins sit at 4.9volts,
w/r pin at grd, and vss and vdd are at 0 and 5 volts resp......still nothing shows up on the display. I take it digital pins 2->9 represent portB data pins? There seems to be some issue with dpins 0 and 1 unlike the other data pins; I take it these should be high for anything to occur. An interesting thing though; when i take the connector off the back of the display and check the voltages on the arduino they are in the significantly small:
data pin (digpin9)= 0 3.1mV data pin 1 (DP8)= 4.9volts the other data pins are in the hundreds of mV range (less than 1V).

I also uploaded this program to another uno and I got the same scenario, so this could imply that the code itself is generating this occurence on DPin 9.
Additionally, this same vfd worked when using a borland C program with a CIODIO48 board (hence the ribbon) placed within a card slot working in conjunction with the CPU of a windows 98 OS which was shown to me sometime in November of last year, so I know it works.
I'm not sure what next to consider doing to resolve this problem since I'm not quite sure what all the requirements may be in order for the display to respond; I think I've covered everything; can you assist me to get this vfd working? Appreciate.
M.

CODE lcd-vfd display.pdf (131 KB)

Hi again,
Attempted to attach a number of files at the same time (missed the more attachments link). didnt see them as attached, except for the source code so sending them here.

C20045-UW5A adatlap.pdf (368 KB)

I'm getting:...

Measuring the voltage of the various microprocessor pins rarely yields any useful information. For example with a properly operating LCD program the Enable pin is almost always low (0 volts). To transfer information to or from the LCD this pin is pulsed high (5 volts) for perhaps a microsecond or so. A voltmeter will never react to this signal, you must use an oscilloscope to detect whether it is there or not.

I take it digital pins 2->9 represent portB data pins?

Digital pins 0 - 7 correspond to the Port D data pins 0 -7
Digital pins 8 - 13 correspond to the Port B data pins 0 - 5
Analog pins 0 - 5 correspond ot the Port C data pins 0 - 5

It looks like this might be your problem.

There seems to be some issue with dpins 0 and 1 unlike the other data pins; ...

Correct. These pins, which correspond to PD0 and PD1, function as RxD and TxD when the UART is in use. They are permanently connected to the USB interface on the Arduino and therefore are not totally unencumbered when the UART is not in use.

That's one of the reasons that I use a Boarduino for most of my work. When you disconnect the programming cable the USB interface is no longer connected to the microprocessor.

Don

Hello Don,
Thanks for your response. Based on the information you provided, I rewired the the uno from the ribbon connector to the uno, as you indicated, and changed the program to reflect those changes for a 2port 8pin mode connection uploaded and still nothing. (Just to be sure, I take it #define LCD_RS 0....LCD_EN 2 lines mean the control lines from the ribbon connector go to digPins 0,1 and 2 of PortB, right? That's how i have them.).
Also did a careful comparison of the eg2.7, 4bitmode single port and eg 2.5 8bit mode double port, and reread the section for the various ways of displaying character data, and tried to do a 8bitmode single port sketch. Basically, I've just been experimenting with different variations of the code and comparing them with the requirements in the specs for the vfd for writing the info.
Even requested from the super if he could pull up the source code to reconnect the CIODIO48 to check the display for functionality....
In addition to the mountain of code i've written in MPLABv8.84 and the PIC18, plus C++ source code, here's what I've come up with and utilized thus far from Mr. Mazidi's and arduino's site, all of which compiles and the 'YES' one gives me everything nicely (unlike yesterday) as you pointed out, the enable pin active low, active highs (3.7volts and higher) on the data pins, and the other pins as should be.

Arduino Sketches.pdf (239 KB)

You are asking me to slog through ten pages of uncommented code - something which I absolutely will not do.

I would have trouble with my own code, even if it were just written yesterday, if it wasn't commented. As it now stands I can go through commented assembly language code written for a processor that I haven't used in 20 years with no trouble at all.

Also, your posts would be easier to comprehend if you were to divide them up into several paragraphs with one concept per paragraph.

How about a circuit diagram or at least a description of how you have things connected. Here's an excerpt from one of my programs (written several years ago) to give you an idea:

//             The numbers shown next to the ATmega168 are the
//              Arduino pin numbers, not the IC pin numbers. 
//
//                 ATmega168                       LCD module
//                ----------                      ---------- 
//               |          |                    |          |
//               |       PD7|7  -------------> 14|DB7       |
//               |       PD6|6  -------------> 13|DB6       |
//               |       PD5|5  -------------> 12|DB5       |
//               |       PD4|4  -------------> 11|DB4       |
//               |       PD3|3  -------------> 10|DB3       |
//               |       PD2|2  ------------->  9|DB2       |
//               |       PD1|1  ------------->  8|DB1       |
//               |       PD0|0  ------------->  7|DB0       |
//               |          |                    |          |
//               |       PB4|12 --------------> 6|E         |
//               |          |          Gnd ---> 5|RW        |
//               |       PB2|10 --------------> 4|RS        |
//               |          |                    |          |
//                ----------                      ---------- 

// These are the connections between the LCD module and the Arduino pins - you can 
//   use any Arduino pin for any LCD signal, in any order, as long as you make sure 
//   that your hardware connections agree with this list (or vice versa).

uint8_t  lcd_RS_Pin     = 10;
uint8_t  lcd_E_Pin      = 12;
uint8_t  lcd_DB0_Pin    =  0;                    // pin 0 has possible conflict with UART Rx
uint8_t  lcd_DB1_Pin    =  1;                    // pin 1 has possible conflict with UART Tx
uint8_t  lcd_DB2_Pin    =  2;
uint8_t  lcd_DB3_Pin    =  3;
uint8_t  lcd_DB4_Pin    =  4;
uint8_t  lcd_DB5_Pin    =  5;
uint8_t  lcd_DB6_Pin    =  6;
uint8_t  lcd_DB7_Pin    =  7;

Don

I apologize if I overwhelmed with the amount of code; it was an error on my part.

Against my better judgement I have taken a look at some of your uncommented code. Here are the problems that I have found so far:

You are adapting code that was written for a different processor running at a different speed but you haven't taken those differences into account. This leads to the first two problems.

The ATmega32 has four 8-bit I/O ports so any of them can be used for the data lines when you are using the 8-bit LCD interface. The ATmega328 as implemented on the Arduino has only one 8-bit I/O port (Port D) but in more than one case you are trying to use another port for your data.

You are specifying an 8 MHz clock frequency but your Arduino is running at 16 MHz. This means that all of your delays are only half as long as you think they are. It's always OK (as far as the LCD module is concerned) to use a longer than necessary delay, but a too short delay can cause problems.

Also:

The 8-bit initialization routines are based on examples shown in the LCD controller datasheets but they do not implement the 'Initialization by Instruction' sequence that is recommended in the datasheet. These steps work most of the time for LCDs and your VFD controller may not be as intolerant as the LCD controller. On the other hand your datasheet mentions the possible need for 'Initializing by Commands', but doesn't give the technique. It's in the middle of page 11 in really fractured English.

    Remarks 
         There is a possibility that reset doesn’t work by slow start power supply. 
         Therefore the initializing by commands needs.

The 4-bit initializations are just plain wrong. They are attempting a trick maneuver to implement the 'Initialization by Instruction' sequence but I doubt if the timing requirements are being met.

The 8-bit routines to send data and commands do not properly implement the timing diagram in section 10.3 of the datasheet. I did not look at the 4-bit routines.

That should keep you out of trouble for a while.

Don

Don,
The diagrams you presented were very clear on everything. Unfortunately, the vfd still does not respond after wiring it up exactly as illustrated.
I'm using only the programs with 8 bit mode programs, in particular the two entitled 'YES' and 'DON', 12.5.3 and 12.5.4 resp.
I know you mentioned your non-use of voltage measurements, but when nothing came on, I checked the voltages on the pins on the connector at the back of the display. Noticed active high voltages when I had r/s and en from the display going to digpins 8 and 10, according to your earlier post for PortB pin positions, and the code for #definitions for the 'YES' sketch. Now, all pins, (except vcc ofcourse) including r/s are active low with the new wiring scheme.
The super reinstalled the original CIODIO-48 back into the computer he used to run his program; even his program did not get it to work, although on disconnecting the vfd and checking the scope for the appropriate high/low signals for the write part of the instruction set, his program appears to be at fault, which does not yet rule out the unit; he’s working on that.
Have analyzed this last post you sent and changed the clock speed 16MHz for the desired delays.
I’m trying to come up with a function to address the timing issue as far as sending data and commands, to work that into the code.
Will let you know what I come up with. Apologize for not responding sooner.
Dave.

Why don't you just post the code that you are using rather than having us try to pick out the appropriate version out of a pile of inappropriate versions. That way we will be sure that we are talking about the same code.

Did you fix this part? Did you even identify the problem? You don't need new functions, just fix the existing ones.

The 8-bit routines to send data and commands do not properly implement the timing diagram in section 10.3 of the datasheet.

Don

05-25fri-12
Good Morning Don,
The code I'm working with (12.5.4) is posted.
I have been comparing the required timing for the vfd on pg 16 of it's datasheet, with that for the uno on the atmega datasheet, pg104 which deals with the timer counter and the output compare registers. Also using the simpler diagram in the textbook which compares the data signals with the signals on the en, r/w, r/s pins, just like for the vfd timing diagram.
I've also sent a snippet of the first part of the code which worked with the CIODIO-48 board the first time around.
I think there is correspondence with this in terms of the initiatialization sequence. It seems to me that the realization of the timing diagram in the vfd datasheet is obtained from the 'void SendDataToDisplay' subroutine; in particular the last part. Was looking at the way this same routine is supposedly realized in the Arduino code, in terms of the interactive timing of the signals on the en r/w,r/s pins and when data is written. In fact I really don't see any lines corresponding in the arduino code that would address the timing issue as is done in the CIODIO code, except the lcd_print (char*str) which I think is insufficient.
I'm also keeping in mind my ultimate objective which is for the program to sense signals for various parameters (altitude, airspeed,airpressure,mach,...) and display any 3 on the first 3 rows of the display, with the 4th used to enter new information, which is automatically sent to row 1 with previous information 'stepping down' to rows 2 and 3, row 4 remaining void for new info.
Pardon my sending this again. Posted a reply earlier and the system kept bouncing me back out with an end-of-time-session response. Attempted here again.

Modified eg 12.5.4 .pdf (103 KB)

ciodio48 first part.pdf (127 KB)

I have been comparing the required timing for the vfd on pg 16 of it's datasheet, with that for the uno on the atmega datasheet, pg104 which deals with the timer counter and the output compare registers.

Why?

Also using the simpler diagram in the textbook which compares the data signals with the signals on the en, r/w, r/s pins, just like for the vfd timing diagram.

That is where at least one error is. Here is a relevant part of your code, properly displayed in the forum post using the 'code' button.

//******************************************************* 
void lcdCommand( unsigned char cmnd ) 
{ 
  LCD_DPRT = cmnd; 
  LCD_CPRT &= ~ (1<<LCD_RS);          // LCD_RS pin of PortB is cleared. 
  LCD_CPRT &= ~ (1<<LCD_RW);           // LCD_RW pin of PortB is cleared. 
  LCD_CPRT |= (1<<LCD_EN);           // LCD_EN pin of PortB is set. 
 delay_us(1); 
  LCD_CPRT &= ~ (1<<LCD_EN);          // LCD_EN pin of PortB is cleared. 
 delay_us(100); 
} 

//*******************************************************

I see that you have added some comments, but they really are not appropriate. Anyone who is reading your code, even an assembly language person like me, can tell that your second line of code clears the LCD_RS pin. Your comment is telling what is being done whereas it really should be telling why it is being done. In other words the comment should tell why the bit is being cleared.

You have left out three comments and the two relating to the delays are quite important. Take a look at those delays and compare them to the timing diagram. Then take another look at the timing diagram and see which of the delays on that diagram is not being implemented.

It would also be appropriate to include a generalized comment at the top which explains what the function as a whole does.

I'm also keeping in mind my ultimate objective which is for the program to sense signals for various parameters (altitude, airspeed,airpressure,mach,...) and display any 3 on the first 3 rows of the display, with the 4th used to enter new information, which is automatically sent to row 1 with previous information 'stepping down' to rows 2 and 3, row 4 remaining void for new info.

Let's just get 'Hello World' working first. After you get that working the rest will be simple.

Where is the circuit diagram?

Don

Here's what I've come up with so far, based on what you posted last and looking at the vfd timing diagram. Am leaving early this evening, but would look at this again later on to hopefully get the first part done. Wont have the unit with me. Have a very pleasant Memorial Holiday and thanks thus far for putting up with me.
Regards,
Dave.

Program to operate a Vacuum Fluorescent Display.pdf (105 KB)

How about this:

Before:

//******************************************************* 
void lcdCommand( unsigned char cmnd ) 
{ 
  LCD_DPRT = cmnd; 
  LCD_CPRT &= ~ (1<<LCD_RS);          // LCD_RS/LCD_RW pins of PortB are cleared... 
  LCD_CPRT &= ~ (1<<LCD_RW);           // ...as required to send commands to LCD. 
  LCD_CPRT |= (1<<LCD_EN);           // LCD_EN pin of PortB is set (pulsed)for internal latching to send a command. 
 delay_us(.02);        // delay 20 ns for LCD module to run a command. 
  LCD_CPRT &= ~ (1<<LCD_EN);          // LCD_EN pin of PortB is cleared after sending a command. 
 delay_us(.26);        // delay 260ns between commands sent. 
} 

//*******************************************************

After:

//******************************************************* 
void lcdCommand( unsigned char cmnd ) 
{ 
  LCD_DPRT = cmnd;                    // set up data lines
  LCD_CPRT &= ~ (1<<LCD_RS);          // RS low, select 'instruction' register
  LCD_CPRT &= ~ (1<<LCD_RW);          // RW low, 'write' data to LCD

// pulse the Enable pin - data is transferred on the falling edge
  LCD_CPRT |= (1<<LCD_EN);            // Enable high
  delay_us(.02);        	      // Enable must be high for at least 230nS
  LCD_CPRT &= ~ (1<<LCD_EN);          // Enable low
  delay_us(.26);                      // Enable must be low for at least 230nS
} 

//*******************************************************

Now compare this to the timing diagram in the data sheet (NOT in the textbook) and find out what is missing and/or wrong.

I haven't looked at the rest of your code yet.

Don

Hello and Good morning sir,
I have 3 concerns.

  1. I looked at the timing diagram and compared it to the lcdCommand routine. Data is sent on the high-to-low enable signal AND when the register select and RW signals are low. From a diagram I drew up based on the high-to-low enable signal duration, this appears every 660 (230x3)ns. Seems to be related to the time for an instruction to be run as shown in the table of page 3 of the data sheet; so I'm putting the delay at 666ns between commands sent which is significantly smaller than that for an LCD as given in the text (100us).
  2. Which brings me to the next concern. How IS the delay worked out from the timing diagrams, in general? I take it the first delay is for the enable pin signal duration and the second the delay between commands and for the display to run the command? For example where does the program in the text come up with 1us and 100us for the 1st and 2nd delays respectively?
  3. How are the delays for the various routines obtained in general, like for LCD_data and the LCD_init; are they chosen as rounded figures relative to the times on the diagrams between successive highs and lows? How does the author come up with 2000ms in the LCD_init routine?
  4. We placed the connecting ribbon with the CIODIO in another computer last week. I connected the unit directly to the arduino using jumpers and the wiring scheme which. What i noticed is that when i connected all the jumpers in order from digital pin12 to digital pin2 of the arduino to the corresponding pins on the display and uploaded the program, there wasn't a problem; when i then connected digital pin1 to pin 7 of the display and tried to upload, I get the error 'avrdude: stk500_getsync(): not in sync: resp=0x00' which is said to refer to a communication problem with the board; was wondering what could be causing this?
    ...and still nothing with these changes uploaded.

Program VFD 05.pdf (124 KB)

I have 3 concerns.

Which of the 4 that you have listed is not a concern?

(1)

I looked at the timing diagram ...

What timing diagram are you referring to. You haven't posted a link to the data sheet that you are using. If it is the same as mine you should be looking at Figure 10.3 on page 16.

...compared it to the lcdCommand routine.

What lcdCommand routine are you referring to?

Data is sent on the high-to-low enable signal AND when the register select and RW signals are low.

Not quite correct. Data is sent to the LCD module under these conditions. The register select then determines whether the data goes to the instruction register or to the data register.

Seems to be related to the time for an instruction to be run as shown in the table of page 3 of the data sheet;

No. The instruction time on page 3 is the time that you must wait after you have sent one instruction to the LCD and before you send the next one. We are talking about the timing between the various signals that you send to the LCD in the process of generating an instruction.

(2) and (3)
Since you have your delays confused I don't think I can attempt to answer these yet.

[Edit]: Don't forget that the author (who probably didn't write the code himself) was dealing with an LCD and not a VFD. You would have to compare the delays that he used with the data sheet for the device that he used.

(4)
When you get the ...getsync(): not in sync: ... error there is usually a communications failure between your computer and your Arduino.

Take another look at reply #14, specifically this part:

Now compare this to the timing diagram in the data sheet (NOT in the textbook) and find out what is missing and/or wrong.

Post your corrected code and we will proceed from there but do not send any more code in PDFs. Post the code as part of your forum entry as I did in reply #14.

Don

You have left out three comments and the two relating to the delays are quite important. Take a look at those delays and compare them to the timing diagram. Then take another look at the timing diagram and see which of the delays on that diagram is not being implemented.

I looked at the timing diagram over and over again, plus researched extensively on how to implement the timing diagram in terms of the program delays.The timing diagrams for the LCD's I looked at are very similar in terms of the particular time intervals involved in signal generation, with difference occurring for the address set up time prior to enable going high. Came up with these 2 sites: (Optrex Corporation 174436, 1 datasheet pdf) and (http://jjackson.eng.ua.edu/courses/ece480/lectures/LECT07.pdf---pg.7); settled on the latter in terms of the flow chart for the 1st delay.
Having put that into the program and uploaded, still nothing. Here's the change.

CODE:
void lcdCommand( unsigned char cmnd )
{
LCD_DPRT = cmnd; // Ready data lines for command signals
LCD_CPRT &= ~ (1<<LCD_RS); // RS low to select the command register
LCD_CPRT &= ~ (1<<LCD_RW); // RW low to write commands.
LCD_CPRT |= (1<<LCD_EN); // Enable pin set to latch data on the falling edge.
delay_us(41000); // Enable high for 41 ms for LCD module to run a command.
LCD_CPRT &= ~ (1<<LCD_EN); // LCD_EN pin of PortB is cleared after sending a command.
delay_us(100); // Delay 100us between commands sent.
}

void lcdData( unsigned char data )
{
LCD_DPRT = data; // Ready data lines for data.
LCD_CPRT |= (1<<LCD_RS); // RS pin set to select the Data register.
LCD_CPRT &= ~ (1<<LCD_RW); // RW low to write commands.
LCD_CPRT |= (1<<LCD_EN); // Enable pin set to latch data on the falling edge.
delay_us(100); // Delay 100us between data sets.
LCD_CPRT &= ~ (1<<LCD_EN); // LCD_EN pin of PortB is cleared after sending data byte.
delay_us(100); // Delay of 100us.
}

/CODE

Have you substituted an LCD for your VFD? You have posted two broken links that contain timing diagrams that are essentially identical to one another and to those for all other LCDs. Why are you not using the timing diagram for your VFD? The timing diagrams for your VFD are very similar to those of LCDs in terms of the signal sequence but the times are significantly different. At least one of the parameters specified on the VFD diagram does is not show up on the LCD diagrams.

In any case your basic problem is that you still do not understand the relationship between whichever Timing Diagram you choose to follow and the code that you are attempting to use to implement that diagram. Specifically, you do not understand how the delays in the program relate to the information on the Timing diagram. This is evident by the values used in and the comments accompanying these two statements:

delay_us(41000);                         // Enable high for 41 ms for LCD module to run a command.
...    
delay_us(100);                           // Delay 100us between commands sent.

Take a look at the comments (not the values) in the corresponding statement in the the 'After' code shown in Reply #14. You must compare those comments to the Timing Diagram that I used, the one for the VFD, for them to make any sense. After you do that you should be able to fix the errors that still exist and find out what is missing.

.........

Your reply #17 above shows two functions that should be identical except for one statement (well, two statements the way you have implemented things). The timing for the 'write' operation is identical for instructions (the correct name for what you are calling commands) and for data.

Quiz: Why does the timing diagram show specific levels for E and R/W while the same diagram shows simultaneous high and low levels for RS?

.........

You obviously haven't used the 'code' tags correctly. Here's how:

  1. Enter your text.
  2. Copy and paste your code in the appropriate location.
  3. Highlight the code portion.
  4. Click on the 'code' button which looks like '#'.

You also obviously didn't check your links before submitting your post. You should do this while you are previewing your post so you can correct any problems before you submit the post.

Don

Hello Don,
1)

Have you substituted an LCD for your VFD?

Don't have one; sent for 2 online yesterday 16x2 and 20x4, 5x7 dot matrix, arduino compatible.

The timing diagrams for your VFD are very similar to those of LCDs in terms of the signal sequence but the times are significantly different. At least one of the parameters specified on the VFD diagram does is not show up on the LCD diagrams.

I honestly don't see which one it is; I've compared each diagram and what I do see is that the LCD diagram gives the tEr and tEf (enable rise and fall times). I also see, as mentioned before, the tAS (address set up time) for the LCD is 40ns as compared to the 20ns, which I thought was the difference you were referring to.
Based strictly on the timing diagram for the vfd I have revised the two functions as follows, uploaded and nothing yet:

void lcdCommand( unsigned char cmnd )
{
  LCD_DPRT = cmnd;	                   // ready data lines	
  LCD_CPRT &= ~ (1<<LCD_RS);        // RS low (ref.quiz:lower line on the timing diagram)to select the Instruction register. 
  LCD_CPRT &= ~ (1<<LCD_RW);      // RW low to write instructions. 
  LCD_CPRT |= (1<<LCD_EN);          // Enable pin high to latch data on the falling edge.
  delay_us(.23);	                         // Enable pin high for 230 ns to enable latching of instruction set.			
  LCD_CPRT &= ~ (1<<LCD_EN);      // LCD_EN pin of PortB low after sending an instruction.
  delay_us(.23);	                         // Delay 230 ns between instructions sent.	
}

//*******************************************************
void lcdData( unsigned char data )
{
  LCD_DPRT = data;		       // ready data lines	
  LCD_CPRT |= (1<<LCD_RS);       // RS pin high (ref.quiz:upper line on the timing diagram)to select the Data register.	
  LCD_CPRT &= ~ (1<<LCD_RW);  // RW low to write instructions. 
  LCD_CPRT |= (1<<LCD_EN);      // Enable pin set to latch data on the falling edge.
  delay_us(.23);                        // Enable pin high for 230 ns to enable latching of data set. 				
  LCD_CPRT &= ~ (1<<LCD_EN);  // LCD_EN pin of PortB low after sending data byte.
  delay_us(.23);	                    // Delay 230 ns between instructions sent.	
}

In any case your basic problem is that you still do not understand the relationship between whichever Timing Diagram you choose to follow and the code that you are attempting to use to implement that diagram. Specifically, you do not understand how the delays in the program relate to the information on the Timing diagram.

You are correct; I do not understand how exactly to implement the timing diagram for the device in terms of the delays required in the program. That's the reason why I came onto this forum for help in understanding how this is done in general so that I may simply do it on my own for any device when given the specifications sheet and it's timing diagrams, in addition to learning as much as can be garnered about every other aspect of successfully interfacing any microcontroller to any peripheral. I was given this task to do for quite some time now, and have tons of code variations for it, first with the PIC18F458, and when that fell through because of outmoded connection issues, now with the arduino uno.

You must compare those comments to the Timing Diagram that I used, the one for the VFD, for them to make any sense. After you do that you should be able to fix the errors that still exist and find out what is missing.

If I'm not mistaken, what could be missing (and which would replace the second delay), is with reference to these links:

  1. LCD Tutorial for interfacing with Microcontrollers: Checking LCD busy flag - Rickey's World of Microcontrollers & Microprocessors):

?BF - the Busy Flag

The Busy Flag is a status indicator flag for LCD. When we send a command or data to the LCD for processing, this flag is set (i.e BF =1) and as soon as the instruction is executed successfully this flag is cleared (BF = 0). This is helpful in producing and exact ammount of delay. for the LCD processing.

To read Busy Flag, the condition RS = 0 and R/W = 1 must be met and The MSB of the LCD data bus (D7) act as busy flag. When BF = 1 means LCD is busy and will not accept next command or data and BF = 0 means LCD is ready for the next command or data to process

  1. http://www.8051projects.net/lcd-interfacing/busyflag.php:
#define F_CPU 16000000UL

#include <avr/io.h>    		
#include <util/delay.h>		

#define	LCD_DPRT  PORTD	     // configuring PortD for data
#define	LCD_DDDR  DDRD		
#define	LCD_DPIN  PIND 	
#define	LCD_CPRT  PORTB           // utilizing PortB pins for the control.	
#define	LCD_CDDR  DDRB 		
#define	LCD_CPIN  PINB 		
#define	LCD_RS  0 		            // control pin assignments.	
#define	LCD_RW  1 			
#define	LCD_EN  2 			
#define      LCD_D7  3
//*******************************************************
void delay_us(unsigned int d)
{
  _delay_us(d);
}
//*******************************************************
void LCD_busy()
{
     DDRD = DDRD &= ~ (1<<LCD_D7); //Make D7th bit of LCD as input
     DDRB = DDRB |= (1<<LCD_EN);    //Make port pin as output
     LCD_CPRT &= ~ (1<<LCD_RS);    //Selected instruction register
     LCD_CPRT   |= (1<<LCD_RW);    //We are reading
     while(LCD_D7){                        //read busy flag again and again till it becomes 0
       LCD_CPRT &= ~ (1<<LCD_EN);  //Enable H->L
       LCD_CPRT |= (1<<LCD_EN);
     }
}
//*******************************************************
void lcdCommand( unsigned char cmnd )
{
  LCD_DPRT = cmnd;	               // ready data lines	
  LCD_CPRT &= ~ (1<<LCD_RS);    // RS low (lower line on the timing diagram)to select the Instruction register. 
  LCD_CPRT &= ~ (1<<LCD_RW);   // RW low to write instructions. 
  LCD_CPRT |= (1<<LCD_EN);      // Enable pin high to latch data on the falling edge.
  delay_us(.23);	                      // Enable pin high for 230 ns to enable latching of instruction set.			
  LCD_CPRT &= ~ (1<<LCD_EN);   // LCD_EN pin of PortB low after sending an instruction.
  LCD_busy();                            // Wait for LCD to process the instruction.		
}

//*******************************************************
void lcdData( unsigned char data )
{
  LCD_DPRT = data;			
  LCD_CPRT |= (1<<LCD_RS);      // RS pin high (upper line on the timing diagram)to select the Data register.	
  LCD_CPRT &= ~ (1<<LCD_RW); // RW low to write instructions. 
  LCD_CPRT |= (1<<LCD_EN);     // Enable pin set to latch data on the falling edge.
  delay_us(.23);                       // Enable pin high for 230 ns to enable latching of data set. 				
  LCD_CPRT &= ~ (1<<LCD_EN); // LCD_EN pin of PortB low after sending data byte.
  LCD_busy();                         // Wait for LCD to process the instruction.	
}

This compiles but when uploaded, still nothing.
Dave.

...I know you said don't post anymore pdf's but this is what I've been looking at for comparison.

timing diags lcd-vfd.pdf (107 KB)

Have you substituted an LCD for your VFD?

Don't have one; sent for 2 online yesterday 16x2 and 20x4, 5x7 dot matrix, arduino compatible.

That is what I thought. If you do not have an LCD and you do have a VFD then why were you using the timing diagrams for an LCD?

I also see, as mentioned before, the tAS (address set up time) for the LCD ...

Please tell me how this delay is accounted for in your code. It should be somewhere in here:

{
  LCD_DPRT = cmnd;	                   // ready data lines	
  LCD_CPRT &= ~ (1<<LCD_RS);        // RS low (ref.quiz:lower line on the timing diagram)to select the Instruction register. 
  LCD_CPRT &= ~ (1<<LCD_RW);      // RW low to write instructions. 
  LCD_CPRT |= (1<<LCD_EN);          // Enable pin high to latch data on the falling edge.
  delay_us(.23);	                         // Enable pin high for 230 ns to enable latching of instruction set.	
  LCD_CPRT &= ~ (1<<LCD_EN);      // LCD_EN pin of PortB low after sending an instruction.
  delay_us(.23);	                         // Delay 230 ns between instructions sent.  
}

Believe me, you do not want to attempt to deal with the busy flag until you can get the device functioning with simple time delays between instructions.

Don