I'm still here. I tried this code, and it Serial.prints 4. Unfortunately, it only loads the first 2 characters. I tried different vals for the buffers, but I still only get 2 chars, now. Furthermore, I tested the sketch on my 2nd new LK1602 -12, and now I've got 2 units with bad splash screens. This one doesn't have vertical bars for the other 30 spaces, it's got some chinese character or such. (The same one for each char.)
I also tried using the lineTWBR = 250; --I tried: 50, 100, 200, & 250. It didn't seem to change anything
I've got good jumper wires going to my display. It's just strange, all the other features are working. I'm going to try uninstalling arduino & libraries, and reinstalling...
Matrix Orbital recommended a delay between every char, so I tried this, but it still only gives the first 2 characters.
He thinks, like myself, that it just some little issue in the transmission that needs tweeked.
#include <Wire.h>
void setup(){
Serial.begin(9600);
Wire.begin(); // join i2c bus (address optional for master)
//TWBR = 250;
delay(4000); //gives a chance to connect to serial before it starts
Wire.beginTransmission(40);
Wire.send(254); //(0xFE); init commands
delay(50);
Wire.send(64); //(0x40); init. startup
//send 32 characters with a 50ms delay
for(int i = 56; i <= 87; ++i){
delay(50); //I've tried: 50, 30, 20, 60,90,120,180
Wire.send(i);
}
int w = Wire.endTransmission();
Serial.println(w);
}
void loop(){
}
One bug that I have encountered is that it’s possible to freeze the display when using the I2C bus under two conditions. First, if the display has not finished powering up (takes about 1?4 second) and you issue a command, it may freeze. This also happens if you issue a command sequence to quickly that needs to write to its EEPROM as it’s reading the command, such as when you program the startup screen. The solution is a delay in both instances, but it can be confusing as this bug is not documented. When using the display on the serial interface there are no issues.
Wire.send(64); //(0x40); init. startup
//send 32 characters with a 50ms delay
for(int i = 56; i <= 87; ++i){
delay(50); //I've tried: 50, 30, 20, 60,90,120,180
Wire.send(i);
}
int w = Wire.endTransmission();
That won't do anything at all. I'll tell you why. All Wire.send does is put stuff into a buffer. Wire.endTransmission sends it as fast as it can. So you could put in a 10-minute delay there, and it still sends at the same speed it ever did.
The only way I know of slowing down the transmission is changing TWBR (which you tried). Failing that you may have to manually clock out the bits. Sounds like a lot of work just to get the startup screen right.
Can you switch to serial mode just to program the startup screen? Then go back to I2C for everything else? Assuming you don't want to change the startup screen very often (like, you do that once, and then rejumper the device for I2C).
Thanks! that explains a lot! Like why anytime I try to write the splash screen, I have to reboot it to get something else working because it seems froze up. I do remember reading that about wire.send doing the final transmission, that DOES explain why the delay didn't help.
This Serial thing is sounding more and more appealing to me. The manual says you can use the LCD in serial mode by desoldering some jumers, I just thought that "Serial" meant the D9 plug on the back, or what ever it's called, that you find on a computer. So can I hook this LCD up to my Arduino via pins 0 & 1 and use serial just like I do with the serial monitor when my Arduino is connect to my laptop? Would it use the same commands?? This sounds VERY nice and simple. The manual also talks about auto key send, so maybe all I'd have to do it the similar thing I do on my laptop -- something like if (Serial.available()>0)...
This sounds like an awfully trouble free solution. Not that I have anything against I2C, but this, my first experience with it, has been quite trying.
Another minor oddity I found was that the command to remember things: If I had it remember the block curosr, it would, but I never could get it to remember the LCD on indefinitely command... That would be the same issue of writing to EEPROM.
I'll be anxious to hear if/how I can use this with Serial on my Uno, if I really can just use Tx and Rx on pin 0 and 1.
Certainly you can use Pin 0 and Pin 1 (assuming it works on 5V which I assume it does). Your only problem would be with uploading sketches. I found with some serial gadgets (like the RFID reader) that I just had to pull the pin while I uploaded a new sketch. This may not trouble you too much.
Alternatively use the "software serial" library and just use other pins.
I'll have to read up on 'software serial'. But, the more I think about it, I've pretty well gotten to know this I2C stuff, and I think I've found all the bugs, now. I've been tweeking this library quite a bit. One thing I found was the the init() function did all this:
//while there are hard-coded details here of lines, cursor and blink settings, you can override these original settings after calling .init()
void LCDI2C::init () {
delay(1000);
Wire.begin();
on(5);
clear();
blink_off();
cursor_off();
//clear();
}
...the on(5) --5 minutes, expains why the remember command I would give to keep the backlight on forever didn't seem to take affect. It likely has taken affect, but every sketch I load overrides it with when I use the init().
Another bug that I see now was the culprit for some sporadic behaviors is the home() command in the library. It sent (0,0), which is what the normal lcd library does, but it needs to be (1,1) as the manual states:
3.4.5 Set cursor position (254 71 [column] [row])
This command sets the cursor position (text insertion point) to the [column] and [row] specified. Columns
have values from 1 to 20 (0x01 to 0x14) and rows have values of 1 and 2 (0x01 and 0x02).
So I may do a little soldering of jumpers to start up Serial commication and fix my splash screen, then go back and see if everything is working perfectly via I2C.
I hope some of this can be a help to anyone else. I don't know anything about making libraries, but I've just made some edits to the one in the playground for this LCD display.
19200 is the default baud. I even made sure the LCD hadn't been changed by jumpering the override pins 3 & 4.
I
the manual: http://www.matrixorbital.ca/manuals/LK_series/LK162-12/LK162-12_Legacy/LK162-12_220.pdf
I did just like it says on the bottom of page 13, top of page 14, by removing the default jumpers for i2c on the right, and soldering in the serial jumpers on the left of the 4 pin header. I check both sides with a meter to make sure I got them desoldered and soldered. (I didn't leave my iron on them for more than 2 seconds.)
I connected pins 2 and 3 to my arduino pins 0 and 1 (rx to tx, tx to rx) although I tried switching them when it didn't work. The LCD lights up but I get no response from my sketch...
Can't get Serial going...
I've found some nice looking librarys/functions for matrix orbitals on serial. This is supposed to work, I don't know what I'm doing wrong???
I got it. I guess this is TTL serial, what ever that means. I had to swap a couple more solder bugs. Plus, the tx and rx pictured in the manual is reversed.
I JUST got it working! I got a brand spanking new splash screen. Maybe I'll load a few of them, so as to bring up the success rate: I've tried loading a splash screen now probably 100 times. So, I'll load 2 or 3 of them.
This Serial seems nice, but I definitely don't like it connected on pin 0 and 1. It interfers with loading sketches.
I think I got all the bugs worked out of the I2C, now, so I may just do some re-desoldering, and go with that. What about little glitches in power? I notice when my little space heater kicked off (that's plugged into the same outlet as my wall-mart ac/dc adapter, that my lcd kinda flaked out, the other day. Which would be more reliable, softSerial or I2C? Serial has auto send keystrokes, but I don't see how that will improve my code, as all I'll be doing is checking Serial.available, rather than polling the lcd unit itself, at least I think.
I mainly want something dependable. The I2C locking up on me so much has me running scared. Does it normally work pretty good?
SouthernAtHeart:
This Serial seems nice, but I definitely don't like it connected on pin 0 and 1. It interfers with loading sketches.
Yes it does that. This is why I suggested softserial, which can use other pins. However I don't particularly like software serial implementations.
I mainly want something dependable. The I2C locking up on me so much has me running scared. Does it normally work pretty good?
It should be reliable. I would look at the pull-up resistors. If it is marginal you may have marginal wave-forms. The pull-ups help there. The power shouldn't be doing that. I would either use another power outlet, or perhaps give yourself some insurance with a capacitor or two. Maybe something like 100uF 16V electrolytic wired between +5 and GND to smooth out the power glitches (get the polarity right), and also a 0.1uF to get rid of any transient pulses.
Does Serial need pull down resistors??? Everytime I power up I get one or 2 strange characters on my display, and then the rest of it is good. Occassionally it'll all be good. This must be from lack of pull downs. I'll have to research what values to use.
The thing is that the initial transitioning from low to high or vice versa might be interpreted as a character. I would just clear the screen as part of the power-up sequence.
Ok, thanks. This LCD (I have 2) that I converted to Serial is working nice. I'm converting my code now. Haven't got into the polling for keypresses yet, but it shouldn't be a problem.
