Ok, I'm currently lost. I can get the LK404-25 to display text fully if I step through the code (TI TMS320F2808 chip for those interested), but if I take the breakpoints out and let it run, 1/2 or so of the characters don't get displayed (varies depending on which way I was sending the characters to the screen -- I've tried a bunch of ways to get around this). If I throw in a couple delay/timing loops, it seems to display all text, though that's kind of like flying blind & hoping the characters get displayed (what happens if there is a full moon AND the new guy's name is Harold? I don't want to be debugging display issues in the back 40 of nowhere if I can avoid it). The last rev/rewrite of the display code from last night works best, but I don't seem to get any NAKs and the 2808's transmit buffer empties like there was no problem... Is there any register I can check on the display, or command I can send to get some sort of flow control going?
Martin.
LK404-25, I2C and dropped characters
Hello mlind,
Thank you for your post.
Can you please tell me the serial number on the back of your LK404-25?
Unfortunately, there are no registers to check on the display. The NAK/ACK bit is the flow control on I2C. I have a feeling that you were communicating with the module a little too fast, and that the delays that you have inserted has slowed the transactions down which resulted to a better responding display.
Best Regards,
Thank you for your post.
Can you please tell me the serial number on the back of your LK404-25?
Unfortunately, there are no registers to check on the display. The NAK/ACK bit is the flow control on I2C. I have a feeling that you were communicating with the module a little too fast, and that the delays that you have inserted has slowed the transactions down which resulted to a better responding display.
Best Regards,
Raquel Malinis
Design and Development
Matrix Orbital
Design and Development
Matrix Orbital
S/N: 6M09-2024
That's my feeling too, since stepping through (delay implicit) worked, but going full speed didn't. Checked the clock lines and they're going @ 385kHz, which should be in spec for 400kHz i2c.
If I go into a loop on the receipt of a NAK, and continually send the last character, will the display NAK until its ready and then ACK? In the end, I want to minimize the time in the display routine(s) and not have to insert delays here & there -- its a bit of a kludge imho. I'll look into the NAK thing a bit deeper tonight & see if something falls out of the tree...
I kinda wish the I2C end of things was a bit more documented, though... :-/
Martin.
That's my feeling too, since stepping through (delay implicit) worked, but going full speed didn't. Checked the clock lines and they're going @ 385kHz, which should be in spec for 400kHz i2c.
If I go into a loop on the receipt of a NAK, and continually send the last character, will the display NAK until its ready and then ACK? In the end, I want to minimize the time in the display routine(s) and not have to insert delays here & there -- its a bit of a kludge imho. I'll look into the NAK thing a bit deeper tonight & see if something falls out of the tree...
I kinda wish the I2C end of things was a bit more documented, though... :-/
Martin.