Matrix Orbital Corp

ok, let me start out by saying that out of all my years of working with electronics your documentation is the worst I've seen. That's including the time I had to work off of an bablefish translation for an rareish part...

anyway here is a summery of my code:

start i2c
write 0x50
wait for ack/nack
write 0xFE
wait for ack/nack
write 0x46 // backlight off
wait for ack/nack
stop i2c

the display I have is an old lcd4041 that I got from ebay.

the problem I have is that I get ack,ack,nack back the first time, the second time (no power cycle) I get ack, then my processor hangs waiting for an ack or nack.

now your documentation is pretty confusing in the useage of the mighty "ack" department. the faq even uses the same paragraph which says some nonsense like: ack is sometimes used to indicate a transmition failure, but only after the second byte is recieved.

that has to be a typo or something. (one that existed since 2005 though)or do the displays not conform to the i2c standards which uses nack to do that? and if the display does only acknowledge the previous byte then where are there 3 responses instead of 2?

another thing, I'm useing 400khz. However the documentation doesn't say what speed the lcd is capable of for i2c communication. (with not even a hint on where I can find out)

another thing is that there are 4 sets of jumpers on the board. the documentation completely skips over what they do or what they are used for. (other than a settings reset which uses one of them) I couldn't get the display to work till I removed 1 on each end of the 4X8 header. is there a special i2c jumper sequence I need to use like the one to use the serial port or something?

another thing is I don't know what address the lcd is when it's at default. it says matrix orbital defines the address as 8 bytes instead of seven. ok, but the i2c standard is 7 bytes with the least significant bit being read/write. so when the documentation says 0x50, If I translate that with matrix orbital's "special" addressing ways, does that then mean the address is actually 0xA0?

but seriously, even if you don't help me at least update your documentation so others don't suffer. and with the extrordinarily high prices of your new displays you shouldn't have a hard time being able to afford hiring someone else to do it for you if you have don't have time to.

Hello ouch,

I would like to apologize that you find our documentation poorly written.

Your code looks good:
I am not sure why you would get a ACK, ACK, NAK, since the the LCD4041 is not capable of NAK.

We do not produce the LCD4041 anymore, and so we do not recommend any design based on it. I would like to suggest to try our newer displays.

We have made changes to our I2C implementation and it is now capable of ACK and NAK at 100KHz speed.

The LCD4041, like the rest of our displays come with 0x50 slave address. There is no need to shift this address; the way you have it in your code is right.

but seriously, even if you don't help me at least update your documentation so others don't suffer. and with the extrordinarily high prices of your new displays you shouldn't have a hard time being able to afford hiring someone else to do it for you if you have don't have time to.

Again, I am really sorry that you find the documentation poorly written, but if you check out our new line of displays that are far newer than the LCD4041 you have, our documentations have improved. As per the pricing of our displays, I think that the convenient interface that our displays offer are worth its price. For people who do not have much protyping and design to do and are just doing a one-of designs only, we have what we call our 'Economy' displays that are cheap but yet still offers the nice and easy interface and built in features that add so much to the value of a normal parallel display.

Thanks,

ok, I was frustrated yesterday so sorry about the rudeness.

but you have to keep in mind that I bought this display specificly for the i2c interface only to find that portion of the display poorly documented. And now I find out that it doesn't even comply with i2c standards...

So you can understand my frustration.

but anyway, I reduced the speed down to 1khz and the display still doesn't seem to be responding. what speed would you recommend trying?

I think the problem might be that the microcontroller I'm using (zilog encore 64k) has a built in I2C hardware controller. It expects the devices to comply with i2c standards. If a device doesn't say, produce nacks, then the hardware for the i2c controller hangs in a loop waiting for those to arrive.

another thing I was worrying about is if the lcd even has open collector i2c data lines?

also you never mentioned what those extra jumpers were for either.

any specific technical data you can provide on the lcd would be appreciated...

thanks,

Hello ouch,

No need to apologize, its unfortunate that you have picked out a display that is quite old and I honestly have not had the experience of using that particular model. I will try and get someone who can dig deep on this, since as I said, the LCD4041 is quite old.

When you say document, are you referring to this manual?
I just want to make sure that we are looking at the same manual.

The I2C on the LCD4041 is implemented by the built I2C hardware on the module's microcontroller; the SCL and SDA lines are open collector as per I2C standards.

The implementation of I2C routines unfortunately, is flawed; this is why it is not capable of NAK'ing. If your I2C master is expecting a certain aknowledgement, and received a different one, your code should be able to find a way to stop the transaction, and not hang. It would be good to scope out the I2C lines.

As for the jumpers, again, I will get someone to help me out on this. You are right there is no mention on the manual; which indicates that maybe they should not be touched at all; but then you said you had to do something with them.

yes that is the manual I'm refering to.

the jumper situation was discussed before here: (there is a nice picture showing what I'm looking at also)

http://www.lcdforums.com/forums/viewtop ... ht=lcd4041

however no detail of what they were used for came up. The manual only shows one jumper header being installed, but as you can see in the picture there must of been a hardware revision that never got documented. all 4 headers were installed when I got it. but the display didn't do anything then. after removeing the 2 on the outside, it properly displayed some hyperterminal action at least, so I know it works.

I can disable the I2C controller's inturrupt requests on my microcontroller so it doesn't get stuck waiting for stuff but I don't know how it will handle toggleing that on and off every lcd transaction...

but to me I would think once we figure out what the display wants, it should keep returning acks and never need to nack or return nothing. currently it acks it's address but then it doesn't return anything on the next byte.

I also tried to send characters to it yesterday but it did the same thing.

Jumpers: I still haven't found documentation regarding these jumpers; its good that you found that one thread you mentioned.

but to me I would think once we figure out what the display wants, it should keep returning acks and never need to nack or return nothing. currently it acks it's address but then it doesn't return anything on the next byte.

You are right; the code you have posted before looks good. I am not sure why it should not work; you said that the LCD4041 ACK'd the slave address and the FEh, but not the 46h. I wonder if putting delays in between will help..

well, well look at what I found:

http://ww1.microchip.com/downloads/en/D ... 80132e.pdf

sounds a lot like the problems I'm haveing... you remember the nack I got returned but you said the display can't do that? I wonder if one of the zilog library's double starts for something. I'll have to comb over the code tonight and see what I can come up with.

I also saw some posts on this message board detailing i2c line lockups, and some displays displaying garbage when sent characters. you might want to check into errata sheets for those controllers and see if they suffer a simular problem.

that's one of the reasons I don't like to use pic chips. they seem to go from design to production way to fast...

edit:

ok, I checked the code and there are no double starts. infact the i2c controller on the encore is incapable of such things according to the documentation.

however the other i2c components on the board are being talked to at much faster speeds than the lcd can handle. So it might be possible that the lcd skips some data and sees 2 start sequences and then fails to properly communicate when the i2c line is breifly slowed down to communicate with the encore.

I don't know, I'm at a loss here. I've been trying to get this friggen lcd to work with i2c for 7-8 days now. I've about given up, it should not be this difficult...

edit2:

you know, the LK404-25 looks awfully simular to my display. I wonder if the 2 displays themselfs are pin for pin compatable? If so I could remove the old flawed addon board I have and replace it with one of the new addon boards for the LK404-25. If you guys even have the addon boards seperate that is...

hmm... I'm thinking the board doesn't "light up" for edits

so here it is

Hi ouch,

No, the board does not light up for edits, but at least now I caught your post.

Unfortunately, we do not sell the interface boards ('add-on') separately. I am not sure if the modules are pin to pin compatible, but I guess since there is no interface board to get separately, there is no need to check for compatibility.

Thanks,

well, any news on what each of those jumpers do at least?

is that a no?

No, sorry. But I have found the files that I need, just need to correlate them with the code. I will let you know as soon as I figure these out.