So I was doing pretty well with developing a dynamic menu for my device, but something stranged happened an hour ago. My LCD no longer read any I2C command coming from my processor, and the only thing I can think about is something shorted on the I2C LCD or the slave address changed somehow. Before this happened I would put delays after certain abstracted LCD function calls because I don't think they're on the same baud rate, meaning the LCD buffer fills up and loses some of the data being sent.
Now I gave up trying to debug it and tried to manually override my LCD by following the following steps listed in the documentation.
1. Power off the display module.
2. Place a jump between Row 5 and Column 1.
3. Power up the display module.
4. The display module is now set to its default values listed below in table 2.
5. Edit and save settings.
However, the LCD still contains all the bitmaps and fonts stored on, thus making me think that it didn't actually get reset. I'm assuming that the LCD should be blank when it's powered on again? Right? Am I doing something wrong?
Manual Override Fails (GLK240128-25)
Hi Markl22,
Sorry to hear you are having some trouble with your GLK240128-25 in I2C mode. It sounds like you've got a handle on the manual override procedure, and the steps provided are correct.
The manual override, although a powerful tool, has little real effect on the display. By that I mean only certain settings, those listed in that table, are changed; all other data on the device remains the same. This means that any fonts or bitmaps on your device will remain, and your start up screen will still display on power up. To get rid of those, you'll have to look through your manual for the wipe filesystem command (p.46), or use MOGD# in RS232 mode to preform the same task at the push of a button.
Give that manual override another go, your I2C write address will be 0x50 again, and just throw up another post if you run into trouble.
Thanks,
Troy
Sorry to hear you are having some trouble with your GLK240128-25 in I2C mode. It sounds like you've got a handle on the manual override procedure, and the steps provided are correct.
The manual override, although a powerful tool, has little real effect on the display. By that I mean only certain settings, those listed in that table, are changed; all other data on the device remains the same. This means that any fonts or bitmaps on your device will remain, and your start up screen will still display on power up. To get rid of those, you'll have to look through your manual for the wipe filesystem command (p.46), or use MOGD# in RS232 mode to preform the same task at the push of a button.
Give that manual override another go, your I2C write address will be 0x50 again, and just throw up another post if you run into trouble.
Thanks,
Troy
Troy Clark
Design & Development
Matrix Orbital
Design & Development
Matrix Orbital
That makes a lot more sense then. My problem had something to do with the i2c slave address. Either it was not reseting to 0x50, or address 0x50 got messed up somehow. Anyways by changing the slave address to 0x52, the communication works again and I'm up and running. Thanks for the fast reply though.
Also do you have any idea on how to determine what bit rate the LCD reads from I2C? I'm assuming our bit rate is much faster than what our LCD is running at since sometimes we have to put busy waits or delays after specific I2C abstracted drawing functions that send multiple I2C sends. If we don't put those delays, a line or shape will not be drawn correctly, as if the last data point was discarded or corrupted. Any idea how to determine or change the bit rate?
Also do you have any idea on how to determine what bit rate the LCD reads from I2C? I'm assuming our bit rate is much faster than what our LCD is running at since sometimes we have to put busy waits or delays after specific I2C abstracted drawing functions that send multiple I2C sends. If we don't put those delays, a line or shape will not be drawn correctly, as if the last data point was discarded or corrupted. Any idea how to determine or change the bit rate?
Hi Markl22,
No worries, good to hear that you've got your GLK up and running again.
There is really no way to calculate a bit rate at which the LCD pulls data out of it's buffer. As commands come in, they will enter the buffer and wait to be executed, this execution time varies from command to command. Once the 120 byte buffer is full, it will respond with a NAK by pulling the SDA line low on the ninth clock pulse, after that last byte is received. You can check out the I2C communication summary in your manual, or the app notes on our .ca site for more info.
I hope that provides a little insight for you, if any of the info above just doesn't make sense, please feel free to put up another post.
Thanks,
Troy
No worries, good to hear that you've got your GLK up and running again.
There is really no way to calculate a bit rate at which the LCD pulls data out of it's buffer. As commands come in, they will enter the buffer and wait to be executed, this execution time varies from command to command. Once the 120 byte buffer is full, it will respond with a NAK by pulling the SDA line low on the ninth clock pulse, after that last byte is received. You can check out the I2C communication summary in your manual, or the app notes on our .ca site for more info.
I hope that provides a little insight for you, if any of the info above just doesn't make sense, please feel free to put up another post.
Thanks,
Troy
Troy Clark
Design & Development
Matrix Orbital
Design & Development
Matrix Orbital