...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
I tried this and these connections...still midnight.
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.
delay_us(.020); // Delay 20 ns for address set-up time.
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); // Enable pin low for 230 ns after sending instruction set.
}
//*******************************************************
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.
delay_us(.020); // Delay 20 ns for address set-up time.
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 data sent.
}
Dave.
I tried this and these connections...still midnight.
What you now have completed are the routines that you need to send Instructions and Data to the LCD controller. Next you have to fix up the initialization routine. As I mentioned in reply #8 your data sheet makes a reference to 'initialization by commands' but it does not seem to specify what those commands should be. The sequence of instructions that you have in the program that you attached to reply #13 may work, but you have to make sure that you do not send them to the LCD controller too quickly. This is where the time it takes the LCD controller to deal with an instruction has to be implemented and you get those times from the VFD Instruction table on pages 3 and 4.
When you get that fixed up I suggest that you first try to write a single character to the display and then put the processor in an endless loop. You want to make sure that a correctly written character is not overwritten by something else if your string writing routine is not working as you expect.
Next I would use a loop to send 80 different displayable characters to the display and again end by putting the processor in an endless loop. I usually start with the ASCII code for a '/' and increment it each time around. If you put a 200mS delay in the loop you can see what is going on. This is particularly interesting with LCDs, especially those with less than 80 characters.
In your 'gotoxy' routine you have confused the memory addresses in the LCD controller with the instruction that is used to set those addresses. The addresses are 7-bit values so 0x80, 0xC0, 0x84, and 0xD4 are not valid addresses and you will not find those addresses mentioned anywhere in most (there are exceptions) LCD data sheets. You really should identify where any magic numbers come from.
As far as your photographs are concerned the quality is good but the wires look like red spaghetti. It is impossible to follow any specific wire to see where it starts and where it ends.
Don