Atmega 16 pin output jitter when LCD updates

Go To Last Post
5 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,
I've got an atmega16, programming with codevision. I have four inputs pins reading analog inputs - these pins are updated once per second. I have 4 output pins driving fets which right now are powering leds. I have an LCD on portd. When the system is in run mode, the LCD updates based on a counter in timer 0 overflow. When the LCD updates, it causes a jitter in two of the output pins, portc.6 and portc.7. The leds (when on) will blink slightly when the lcd updates. I have looked everywhere for something in the program to cause the jitter. I have put large caps in the circuit. There are two other outputs, portc.5 and portc.4. These pins are not affected. The only thing that I have found to stop this is to disable the lcd update.

Does anyone know something about these pins which might be affected by the lcd function? Any other ideas to try?

thanks - below is my lcd update routine.

// RUN time LCD update routine
        if (CAL==0 & T5_dn==1 & POWERSAVE==0)
        {  
        // Update the LCD display once every three seconds
        // =============================================== 
        
        lcd_clear();
                      
        lcd_gotoxy(0,0);
        lcd_puts("E ");
        itoa(EAST,STRING);
        lcd_puts(STRING);
              
        lcd_gotoxy(8,0);
        lcd_puts("W ");
        itoa(WEST,STRING);
        lcd_puts(STRING);
                                          
        lcd_gotoxy(0,1);
        lcd_puts("U ");
        itoa(UP,STRING);
        lcd_puts(STRING);
                           
        lcd_gotoxy(8,1);
        lcd_puts("D ");
        itoa(DOWN,STRING);
        lcd_puts(STRING);
                
        }
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'd like to add something to this. This problem is related to the code which turns on PORTC.6. Below is the code which turns on PORTC.6 (named WESTCMD) None of the values shown in this code snippet are affected by the LCD_UPDATE code. But yet when this code runs, the value of PORTC.6 (WESTCMD) goes to zero for a moment.

// Determination of azimuth motor run forward
        // ==========================================
        AZERROR=WEST-EAST;              
        TIME_OK=(h>5 & h<22);
        SUN_OK=((EAST>MIN_SUN)|(WEST>MIN_SUN)|(UP>MIN_SUN)|(DOWN>MIN_SUN));                                   
        WEST_START=(AZERROR>ERROR);
        WEST_STOP=(AZERROR<-1*ERROR);                          
        
        T1_en=((TIME_OK)&(~EASTCMD)&(~WEST_STOP)&(LIMWEST)&(SUN_OK))&(WEST_START | T1_en);
        WESTCMD=T1_dn;    
        // ==============================================================
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

portc6 & portc7 alternative uses are for TOSC1 and TOSC2, so I don't see that as an issue.

Does the LCD code run within an interrupt handler?

You have told us what controls pc6 , but not what controls pc7?

What causes the // Determination of azimuth motor run forward to run?

Is the LCD code something that you had to shoehorn to make it work? Is it 4 bit or 8 bit & on which bits do you control EN,RS & do you use R/W?

Also in if statement

if (CAL==0 & T5_dn==1 & POWERSAVE==0){};

was/is it your intention to do a bit-wise AND or a logical AND , as in

if (CAL==0 && T5_dn==1 && POWERSAVE==0){};

Whilst they either "might" work in this particular case, IMHO the latter is less obfuscated and less likely to cause bugs down the track.

.....grrrrrrrrr why doesn't the code format work?

Charles Darwin, Lord Kelvin & Murphy are always lurking about!
Lee -.-
Riddle me this...How did the serpent move around before the fall?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Regarding & versus &&. I have it backwards. All of my logic items are bits, so I don't need bitwise, just logic.

I have isolated the problem as such. PORTC.7 is not directly affected nor is PORTC.6. The logic for WESTCMD is changing each time the LCD UPDATE code is run. If I disable the update loop, the value of WESTCMD stays constant (or it properly follows the logic). I swapped the output ports for WESTCMD and the problem followed the logic for WESTCMD.

The LCD is using 4 bit method. I have had not problems using it.

Below is the code causing the azimuth motor to run. A brief explanation. The motor starts to run based on a given amount of error (WEST_START) for a given amount of time (10 s). This is a latched start. So if the motor is off, it should take 10 seconds to restart. The motor will turn off for several reasons: if the WEST_STOP error has been reached, if the SUN_OK signal goes low, if the west limit switch (LIMWEST) has been reached, or if an east command (EASTCMD) has been issued.

The motor is cycling on and off at the same rate as the LCD UPDATE loop. It appears that the LCD UPDATE loop is affecting the state of T1_dn.

interrupt [TIM0_OVF] void timer0_ovf_isr(void)
{   T_1sec++;   // increment internal counter
    TCNT0=10;   // let counter register start at 10.  A count of 240 causes a 1/4 second overflow
    
    T1_dn=T1_en && (T1_dn || T1A>=HDELAY);
    T2_dn=T1_en && (T2_dn || T2A>=2);
    T3_dn=T3_en && (T3_dn || T3A>=360);
    T4_dn=T4_en && (T4_dn || T4A>=2);
     
    
        // Determination of azimuth motor run forward
        // ==========================================
        AZERROR=WEST-EAST;      // WEST and EAST are analog inputs, as are UP and DOWN        
        TIME_OK=(h>5 && h<22);  // h is the hour, read by the clock (DS1302
        SUN_OK=((EAST>MIN_SUN)||(WEST>MIN_SUN)||(UP>MIN_SUN)||(DOWN>MIN_SUN));                                    
        WEST_START=(AZERROR>ERROR);       // ERROR is a user-entered value.  WEST_START latches T1_en (enabling the T1 timer)
        WEST_STOP=(AZERROR<-1*ERROR);     
                                    
        T1_en=((TIME_OK)&&(~EASTCMD)&&(~WEST_STOP)&&(LIMWEST)&&(SUN_OK))&&(WEST_START || T1_en);
        WESTCMD=T1_dn; // T1_dn goes high when the T1 timer counts to 10 seconds
        
        
        // count number of starts on westcmd to debug
        if(WESTCMD && ~wold)                                                    
        wcount++;
        wold=WESTCMD;

[cliff: code tags fixed in all posts in this thread]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The problem exists in using the itoa() command during the lcd update. If I remove those commands from the code, everything works. Looks like Codevision has a bug.