Pages: [1] 2   Go Down
Author Topic: arduino for vfd  (Read 2449 times)
0 Members and 1 Guest are viewing this topic.
Offline Offline
Newbie
*
Karma: 0
Posts: 30
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Hi,
Using now an Atmega 328P arduino uno to get the same noritake itron vfd CU20045-UW5A to work . Followed the LCD example 12.1 in assembly from Mazidi's AVR microcontroller's text, having read up on all the requirements to get a 14-pin LCD to work, which is very similar to the 14-pin vfd I'm using. I had to alter the code a bit for it to compile in avrstudio5. I have a number of questions:

1)I previously had a simple blinking program on the board from arduino.cc IDE, yet when I try to upload the hex file for eg 12.1 onto the board using tools>arduino upload in avrstudio5, and getting the avrdude verification with a thank you note, I still see the blinking program I had on.

2) I  used the portB 8bit single port sketch I derived from eg12.5, which compiles. I'm getting data pin 0 has 0volts, data pin 1 has 4.8volts unlike the other data pins, and the other data pins 3.8volts, logic 1 for activation; the rs, en pins both sit at 4.8volts, w/r pin at grd, and vss and vdd are at 0 and 5 volts resp...... nothing shows up.  I take it digital pins 2->9 represent portB data pins? There seems to be some issue with dpins 0 and 1.  I take it all pins should be high for anything to occur; wondering what could be causing these voltages on these pins?
 
3) Another thought here. You'd want to think the LCD script should apply equally well to a VFD in terms of hex file generation for the processor to execute. Do you think there may be timing differences in terms of when data is written when the enable pin is high or low.

* Microdigitaled.pdf (289.23 KB - downloaded 39 times.)
Logged

Western New York, USA
Offline Offline
Faraday Member
**
Karma: 36
Posts: 4307
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

So Mazidi is still cranking out the microprocessor textbooks... too bad he doesn't have enough time to comment his example programs. 

Quote
I have a number of questions:
So do I.  Why don't you take a look at this thread http://arduino.cc/forum/index.php/topic,102266.0.html and see if you can figure out my questions.

Don
Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 30
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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.1 KB - downloaded 37 times.)
Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 30
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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 (367.93 KB - downloaded 19 times.)

* vfd apparatus.jpeg (767.44 KB, 2448x3496 - viewed 50 times.)

* IMG_20120521_143951.jpg (232.14 KB, 768x1024 - viewed 42 times.)

* IMG_20120521_144038.jpg (232 KB, 768x1024 - viewed 40 times.)
Logged

Western New York, USA
Offline Offline
Faraday Member
**
Karma: 36
Posts: 4307
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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

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


Quote
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
Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 30
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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 (238.83 KB - downloaded 25 times.)
Logged

Western New York, USA
Offline Offline
Faraday Member
**
Karma: 36
Posts: 4307
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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
Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 30
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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

Western New York, USA
Offline Offline
Faraday Member
**
Karma: 36
Posts: 4307
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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
« Last Edit: May 22, 2012, 07:22:05 pm by floresta » Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 30
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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

Western New York, USA
Offline Offline
Faraday Member
**
Karma: 36
Posts: 4307
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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.

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

Don
« Last Edit: May 23, 2012, 05:28:35 pm by floresta » Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 30
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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 (102.79 KB - downloaded 23 times.)
* ciodio48 first part.pdf (126.75 KB - downloaded 27 times.)

* timing diagram AVR.jpeg (1241.07 KB, 2288x3388 - viewed 40 times.)
Logged

Western New York, USA
Offline Offline
Faraday Member
**
Karma: 36
Posts: 4307
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
   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?

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

Code:
//*******************************************************
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.


Quote
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


« Last Edit: May 25, 2012, 12:27:41 pm by floresta » Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 30
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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 (104.51 KB - downloaded 27 times.)
Logged

Western New York, USA
Offline Offline
Faraday Member
**
Karma: 36
Posts: 4307
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

How about this:

Before:

Code:
//*******************************************************
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:
Code:
//*******************************************************
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
« Last Edit: May 25, 2012, 05:37:27 pm by floresta » Logged

Pages: [1] 2   Go Up
Jump to: