Go Down

Topic: arduino for vfd (Read 2 times) previous topic - next topic


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.


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;



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


May 23, 2012, 02:15 am Last Edit: May 23, 2012, 02:22 am by floresta Reason: 1
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.


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.
        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.



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.

Go Up