NHD-0420CW I2C interface

Bz89

Hi all,

I am using an NHD-0420CW in a design which requires the interface type to be I2C. Upon reading all documentation and controller manuals (Us2066) I am still unsure of a few things and would like to ask a few questions. I Would appreciate any comments/feedback on the below:

1). in the Application notes section of the Newhaven website, a section is dedicated to explain the differences between serial and parallel interfaces. In this section a statement is made saying that an I2C interface may not work correctly with other devices on the same bus.

My system has 4 other device connected to the same bus, each however has a unique address, I am guessing that the comment made on the website is to say that the LCD would not work if there is another device having the same address connected to the bus? or is the website saying something else?

2). upon reading through the US2066 datasheet, the control byte is composed of the Co and D/C bits followed by 6 0s. My understanding of these 2 bits is to enable sending a mixture of data and command bytes in the same I2C transaction, is this correct? so to send a string of data bytes the control byte would be 0x40 followed by an x number of data bytes. Does the control byte need to be sent only once? or after sending each data byte?

And so to send a string of command bytes, the control byte is 0x80 followed by an x number of command bytes? would I need to send the control byte only once before sending all the commands? or once for each command?

I guess what I am trying to say is that I don't understand why there are 2 bits in the control byte that are both used for the same purpose for indicating whether the transmitted byte is a data or a command byte.

I would appreciate any feedback/comments on the above.

0

Comments

4 comments

Date Votes
  • Saurabh_B

    Hi,
    You should be able to use this with multiple sources on the same bus, however sometimes the other devices tend to sink some of the current and create invalid high signals.

    The continuation byte needs to be sent between each datawrite.
    While it is possible to send larger amounts of data continuously, for I2C you would need the command byte.

    The first bit is going to be the continuation bit, which should just be a 0 meaning there is "Data" to follow, by this it could mean that the following information could be data or a command.
    the DC bit will determine how the "Data" is interpreted.

    0
  • Rheib

    :-\
     Saurabh_B, Could you please be more specific here with your answer? I am also having a terrible time interpreting these bits in the data sheet and I would rather venture into knowing exactly how to exercise the I2C bus, for use of the US2066 controller in the NHD-0216CW display, instead of experimenting.  Specifically can you correct and detail the following "understanding"?:

    1) Control Byte: 8 bits. MSB = bit 7, LSB = bit 0, bit 7 = Continuation bit, this bit, when set, instructs the US2066 controller that there are more bytes to follow in "this" transaction. An Example: write "123" to the display (Assume that the display has been set up and cursor is at row 1 column 1). The bytes that would(appear) be written on the I2C bus would be:
    Slave Address = 0x78 (SA0 tied to GND), Control Byte = 0xC0 (Continuation Bit Set AND Data Bit Set), Data Byte = 0x31", Control Byte = 0xC0, Data Byte = 0x32, Control Byte = 0x80 (Continuation Bit Cleared and Data Bit Set), Data Byte = 0x33.  I am expecting that this sequence would adhere to the normal I2C transactional protocol whereby each byte transmitted would have a Start bit AND an Ack/Nack bit and after the last data byte, the master would terminate with a stop condition...

    2) Example, Set DDRAM Address to 0x33: The bytes that would (appear) be written on the I2C bus would be:
    Slave Address = 0x78 (Sa0 tied to GND), Control Byte 0x80 (Continuation Bit Set, Data Bit Cleared), Command Byte = 0x20 (setting N, BE, RE, and REV to 0), Control Byte = 0xB3 (0x80 + 0x33 for AC6-AC0). Again, I am expecting that this sequence would adhere to the normal I2C transactional protocol whereby each byte transmitted would have a Start bit AND an Ack/Nack bit and after the last data byte, the master would terminate with a stop condition...

    What is vitally important here is the proper behavior of the Continuation bit when multiple bytes are sent to the display over the I2C. And, the behavior of the Start bit on the front of every byte that gets sent. The Start bit is standard I2C and to diverge from this makes it very difficult to implement in a system with standard I2C cores that do this all automatically.

    One suggestion would be to add several examples of actual transactional sequences, similar to that shown in the US2066 data sheet (Figure 5-7 : I2C-bus data format) but add all of the details showing the values of the Control Bytes, command/data bytes, and start/stop bits. Code examples accompanying each graphic would also be tremendously helpful.

    Thank you,
    RSH

    0
  • Ted M.
    NHD Staff

    The Co bit can be kept low.  The data being sent will then be interpreted as Data or Command based on the  D/C# selection bit for the remainder of the write.  The I2C sequence will function as the standard protocol with the Co bit always low, beginning with the Start byte and using  D/C# and Ack/Nack bits until the last data byte ending with the stop.  If the Co bit is ever set High, then the display will ignore any data being sent to it during that time.

    0
  • BobG
    I've just finished working on an I2C driver for the US2066 contoller, and I treated the Co and D/C#flags as described in the manual section 5.1.4.2.  I preceeded each command byte with a control byte with C#.  Each control byte has the Co bit set if there is a control byte (for data or command) following the command.  A string of data bytes is preceeded with a control byte with D only.  I did not try to send any commands following the data in the same I2C message (to do so, I presume one would need control bytes interspersed with each command or data byte - and all but the last control would have Co set.  Basically, I implemented 4 simple routines:  command (sends one C# control byte and one one-byte command), cmdData (sends one C# + Co control byte, one command byte, one D control byte, and one data byte - used for the Func. Select A/B commands), extCmd (sends one C# + Co control byte, one command byte, one C# control byte, and one command byte), and write (sends one D control byte, and any number of data bytes).  Actually, I quite arbitrarily limited the number of data bytes in write to 5.   I cut this down to 1 data byte at one point to see if it would cure a light-streaking problem when doing fast rerwrites (3/sec), but it didn't help - so I put it back up to five - and may try higher.   This is running on an Arduino at 100KHz serial rate.

    Note: I'm unable to reproduce the problem of light streaking/flashes.  I hope it's not true that "problems that go away by themselves come back by themselves."
     
    « Last Edit: March 02, 2017, 10:48:10 AM by BobG »
    0

Please sign in to leave a comment.

Didn't find what you were looking for?

New post