I am having trouble with the LCD screen freezing, there is a message displayed on the LCD but it is not changing as expected. The set up is quite involved and may be difficult for me to describe in any detail. I will attempt to cover a few points that may be relevant to the issue. I have set up three SPI slave chips one for each axis of movement of my mill project. Each of these slave chips is receiving data from digital callipers, a motor controller chip and couple of movement limit indicator switches. This data is transmitted to the master chip and then sent on to a PC by way of a serial UART connection. I am also intending to display the calliper reading on a LCD screen connected to the master. The data flow between the slaves and the master as well between the master and the PC is done using a number of control characters. For the most part this system is working well. I am getting valid calliper reading showing up in the correct locations at the PC. I am also getting the correct readout at the PC regarding the movement limit switches and returns from the motor controller chips such as torque limit setting and other parameters.

The problem I am experiencing is getting the calliper position data to reliably show up on the LCD screen. The reading show up part of the time as expected. Then the LCD screen reading lock up (stop changing) even when the changing reading are showing up at the PC screen. I can move a calliper position and read the change at the calliper itself and on the PC screen but the LCD screen shows no change at all. Often, I can get valid reading at the LCD for a period of time then it locks up. Could this be a hardware problem within the LCD itself? I have actually tried a couple of screens I am lost.

The statements to send the data on the UART to be displayed on the PC are immediately ahead to the fprintf statement intended to display the same data on the LCD. Nothing is changing that have been able to identify. I am posting a small portion of my code that is working to send the data to the PC on the UART then intended to print to the LCD screen. As I said the UART PC connection seams to always work the LCD sometimes works.

     // axis =  slave (axis) that is currrently reporting information.
        switch (axis){

    // S char is code for- income slave data
    // rtn =bitwise slave inforamtion containing motor controller return data ect.
    // mmread = current caliper position reading 
        case 0: 
        printf_P(PSTR("Sc%c%7f"),((char)(rtn)),mmread);  //c char is code X axis data
        break;

        case 1: 
        printf_P(PSTR("Sk%c%7f"),((char)(rtn)),mmread);  //k char is code y axis data
        break;

        case 2: 
        printf_P(PSTR("Ss%c%7f"),((char)(rtn)),mmread);  //s char is code z axis data
        break;
        }
        lcd_goto_position((axis +1), 4); 
        fprintf_P(&lcd_stream, PSTR("%8.4f%7.2f"),(mmread/25.4),mmread);
        }

I thought getting this information to the correct location on the PC would be the difficult part. It seams that displaying it on the LCD is causing more issues at this time. I don’t really require a LCD display and the PC I just thought it would be nice.

sask55 -

It may have something to do with the way the LCD is wired to the MCU. Since it doesn't use the LCD R/W pin to check if it is OK to send more data, it has to rely on a guess of the delay needed for each write signal. It's possible you are overloading it but it seems unlikely. You could try a delay but I think I would try executing lines 20 & 21 above less frequently than the "printf()" statements. Maybe put a static "count" variable in and execute only when "(count % 10 == 0)" to update 1/10 as often as the PC. Other than that it could be the breadboard channeling signals across pins.

I have now noticed that the issue with the LCD display appears to be related to the output state of at least one other pin on the master chip. There are a number of pins PC0,PC1,PC2,PC3,PC4 and PC5 that are configured as output pins on the master. The output state of these pins are controlled from the PC thru the UART. These pins are used to control the calliper resets, LED on the LCD, and power supply relays required to enable a sequential start up that is strongly suggested for 5 volt and 24 volt supplies to the motor controllers chips. All these output pins appear to working as expected and I am able to control these functions from the PC.

I have now realize that after the master executes the statement posted below the LCD stops changing. Once the statement below is carried out by the master I have to reset the master to see any changes on the LCD. It seams to me that the statement is dealing with the PORTC I don’t know how this should affect the LCD.

I realize that the style of bit manipulation is not typical but I don’t understand why it would have any effect on the LCD output from the chip. I have used this style or format a lot to select and copy only selected bits from one byte to another it may not be typical but it has work well for me. Incoming is the name of a one byte control charter that has been received on the UART from the PC. I am setting or clearing two bit in the PORTC register to match the state of the corresponding bits in the control byte “incoming”. PC3 and PC4 are the pins controlling the power relays to the motor controller chips, these relays are working as I expect. It makes no difference if there are any connections on the board to these two pins. I have completely removed any connection to both pins and the LCD problem still occurs each time the statement below is executed.

bit 3 and bit 4 decimal value of 8 and 16, decimal 24 sets bits 3 and 4

//Send PC comand to master ie power control
PORTC = ((PORTC & ~24) | (incoming & 24 )); 
delay_us(30);

I don’t have another ATmega168 on hand right now. I am expecting a package any day. I think I may try a different Micro just to be sure it is not some strange internal problem in this master chip.

For now I would be very interested in knowing how that statement could affect the LCD if anyone would explain it to me.

sask55 -

I wonder if writing to PC7 is causing the problem since there is no pin for that. In the datasheet it labels this as "read-only". You could try re-writing the code so PC7 never gets affected.

Thanks; that does sound like a very plausible explanation. I will certainly check that idea out as soon as I get a change.

But then on the other hand don’t regular common statements like PORTC &= ~(1<<PC1); and PORTC |= (1<<PC4); kind of do a similar thing

Is writing a bit to zero in a register byte writing a bit?

if so how do I avoid writing that one bit?

You may be correct. I am having a bit of trouble seeing how to write to a register without including all eight bits of the byte in the statement.

How is (incoming & 24) or binary000??000 really any different ? Can Bit 7 in PORTC have no value, not a 0 or a 1?

Is not PORTC &= ~(1<<PC1)

The same as PORTC = PORTC & (1<<1) or PORTC & (000000010)

What statement should I use to accomplish what I am trying to do without makeing soom indirect reference to bit 7 of the byte?

Darryl

I don't see how setting a value in PORTC would affect the LCD. If you comment out the line you suspect is causing the problem, does the LCD continue to work?

Darryl -

Actually I was thinking you might have been writing a 1 to the 7th bit, but after going through the different binary math scenarios, I don't think you would be setting that bit no matter what the value of "incoming" is. If it was, you could mask the 7th bit with &= 0x7F.

Noter -

I couldn't see it either but when I looked to see how close pin PC7 was to any of the LCD pins, I couldn't find it. That's what sent me off on that tangent.

Darryl -

You could try putting a scope on PD6 (LCD enable) or PD7 (LCD data/command) to see if it is an breadboard problem.

I have identified and corrected my problem. I took Noters advice and commented out the code line I felt was causing the issue. That did not fix the problem but it did get me thinking. It is kind of difficult to explain but basically I had a } to end a if statement in the wrong place in the code. As my system is set up the PC will send a series of command code bytes to the master on the UART the two LSB of each of these command bytes are used to tell the master were to send the command information that is carried in the remainder of each byte. The four possible directions to send the commands are the three slave chips or to control the output pins on the master chip. In the case of the master control bytes there is no new return data delivered from a slave chip. To make a long story a little shorter the variable axis =3 for master control codes. So after a master chip control byte was received the LCD was beening instructed to print on line 4 that does not exist at all. Once that statement attempting to print to line 4 was executed the LCD would lock up. By simply moving the end of the if statement to the correct location none of this code is executed when the command is a master chip control byte.

Sorry for the trouble, The problem was kind of simpleand all my fault things are back on track.

Thanks everyone.

Darryl