2106 | ADC | ARM7 | Atmel | Bootloader | CAN | CrossStudio | CrossWorks | DDS | ECos | Ethernet | ETM | FIFO | FLASH | FPGA | GCC | GDB | GNU | GNUARM | GPIO | I2C | IAP | IAR | JTAG | Kickstart | LCD | Linux | LPC | LPC-E2294 | LPC2000 | LPC2100 | LPC2104 | Lpc2106 | Lpc210x | LPC2114 | LPC2119 | LPC2124 | LPC2129 | Lpc2138 | LPC213x | LPC21xx | LPC2210 | LPC2212 | LPC2214 | LPC2292 | LPC2294 | LPC2xxx | LPC3128 | MCB2100 | Olimex | Philips | PWM | Rowley | RTC | RTOS | SPI | SSP | UART | UART0 | UART1 | ULINK | USB | Watchdog | Wiggler

I'm interested in people's opinion on this. I am using a I2C
Graphical Display interfaced with a LPC2148. On occasion, the I2C
command sent out drops a byte which causes the command to be invalid.
This could be due to noise, interference, and the like. I haven't
determined exactly what causes this. However, I'm sure there are
going to be instances of this on occasion and that it needs to be
accounted for.

The display doesn't have any ability to issue a NAK back for invalid
commands, whether bad parameter values, wrong number of parameters,
etc. It only sends a NAK back for buffer full, which I handle.
Therefore, I haven't figured out a way to reissue the display command
when bytes are dropped, because there is no way for me to know. The
display still tries to execute the invalid command and does weird things.

I have a RTC that refreshes the display every second with the new
time, and on occasion (every 20 minutes or so), the time gets
displayed in other areas of the display. It's annoying and looks bad.
It could happen anytime, so that refreshing the screen is not the
solution, because you never know if it has happened unless you look at
the display.

Shouldn't this be handled in the display? I think so. The display
company doesn't have immediate plans to do anything about it. They
say they don't have to code space. They have a serial version, but it
has the same protocol.

Sutton
------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

With that kind of support I'd vote by taking my display business to someone
that will

provide ack/nak response.

Can you improve the noise reduction? Better not to have to resend at all.

.Laurie:{)

From: l...@yahoogroups.com [mailto:l...@yahoogroups.com] On Behalf Of
Sutton Mehaffey
Sent: Thursday, 2 October 2008 6:40 AM
To: l...@yahoogroups.com
Subject: [lpc2000] I2C protocol question

I'm interested in people's opinion on this. I am using a I2C
Graphical Display interfaced with a LPC2148. On occasion, the I2C
command sent out drops a byte which causes the command to be invalid.
This could be due to noise, interference, and the like. I haven't
determined exactly what causes this. However, I'm sure there are
going to be instances of this on occasion and that it needs to be
accounted for.

The display doesn't have any ability to issue a NAK back for invalid
commands, whether bad parameter values, wrong number of parameters,
etc. It only sends a NAK back for buffer full, which I handle.
Therefore, I haven't figured out a way to reissue the display command
when bytes are dropped, because there is no way for me to know. The
display still tries to execute the invalid command and does weird things.

I have a RTC that refreshes the display every second with the new
time, and on occasion (every 20 minutes or so), the time gets
displayed in other areas of the display. It's annoying and looks bad.
It could happen anytime, so that refreshing the screen is not the
solution, because you never know if it has happened unless you look at
the display.

Shouldn't this be handled in the display? I think so. The display
company doesn't have immediate plans to do anything about it. They
say they don't have to code space. They have a serial version, but it
has the same protocol.

Sutton

[Non-text portions of this message have been removed]
------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

There aren't too many I2C graphical display companies around. Most
still use RS232.

I don't know if it is noise or not. Haven't determined the cause.
However, I think you have to handle that condition regardless.

Sutton

--- In l...@yahoogroups.com, "Laurie Gellatly"
wrote:
>
> With that kind of support I'd vote by taking my display business to
someone
> that will
>
> provide ack/nak response.
>
> Can you improve the noise reduction? Better not to have to resend at
all.
>
>
>
> .Laurie:{)
>
>
>
> From: l...@yahoogroups.com [mailto:l...@yahoogroups.com] On
Behalf Of
> Sutton Mehaffey
> Sent: Thursday, 2 October 2008 6:40 AM
> To: l...@yahoogroups.com
> Subject: [lpc2000] I2C protocol question
>
>
>
> I'm interested in people's opinion on this. I am using a I2C
> Graphical Display interfaced with a LPC2148. On occasion, the I2C
> command sent out drops a byte which causes the command to be invalid.
> This could be due to noise, interference, and the like. I haven't
> determined exactly what causes this. However, I'm sure there are
> going to be instances of this on occasion and that it needs to be
> accounted for.
>
> The display doesn't have any ability to issue a NAK back for invalid
> commands, whether bad parameter values, wrong number of parameters,
> etc. It only sends a NAK back for buffer full, which I handle.
> Therefore, I haven't figured out a way to reissue the display command
> when bytes are dropped, because there is no way for me to know. The
> display still tries to execute the invalid command and does weird
things.
>
> I have a RTC that refreshes the display every second with the new
> time, and on occasion (every 20 minutes or so), the time gets
> displayed in other areas of the display. It's annoying and looks bad.
> It could happen anytime, so that refreshing the screen is not the
> solution, because you never know if it has happened unless you look at
> the display.
>
> Shouldn't this be handled in the display? I think so. The display
> company doesn't have immediate plans to do anything about it. They
> say they don't have to code space. They have a serial version, but it
> has the same protocol.
>
> Sutton
>
>
>
> [Non-text portions of this message have been removed]
>

------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

I2C peripheral uses ACK for each byte received. Doesn't this work for you? In that case you could refresh the display.

If the noise is the problem, you can lower the bitrate and put capacitors on the lines.
If you have long lines between the microcontroller and the display, you can put a buffer (another microcontroller) before the display and use protocol with ACKs between the main microcontroller and the buffer.
[Non-text portions of this message have been removed]
------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, "Sutton Mehaffey" wrote:
>
> I'm interested in people's opinion on this. I am using a I2C
> Graphical Display interfaced with a LPC2148. On occasion, the I2C
> command sent out drops a byte which causes the command to be invalid.
> This could be due to noise, interference, and the like. I haven't
> determined exactly what causes this. However, I'm sure there are
> going to be instances of this on occasion and that it needs to be
> accounted for.
>
> The display doesn't have any ability to issue a NAK back for invalid
> commands, whether bad parameter values, wrong number of parameters,
> etc. It only sends a NAK back for buffer full, which I handle.
> Therefore, I haven't figured out a way to reissue the display command
> when bytes are dropped, because there is no way for me to know. The
> display still tries to execute the invalid command and does weird
things.
>
> I have a RTC that refreshes the display every second with the new
> time, and on occasion (every 20 minutes or so), the time gets
> displayed in other areas of the display. It's annoying and looks bad.
> It could happen anytime, so that refreshing the screen is not the
> solution, because you never know if it has happened unless you look at
> the display.
>
> Shouldn't this be handled in the display? I think so. The display
> company doesn't have immediate plans to do anything about it. They
> say they don't have to code space. They have a serial version, but it
> has the same protocol.
>
> Sutton
>

I happen to be the engineer that inherited the design of the display
you're mentioning. It's easy to tell because I fielded this very
question from our technical support team this morning. Before you go
passing judgment, let me clarify a couple of things.

We can't help you with your bytes getting changed in transit. Short
of performing a CRC check of some kind, you can't really make a dent
in that. Checking to see if the parameters are invalid really doesn't
do you much good if the noise has changed the byte to something else
that happens to still be valid.

You might also want to dig further into why a byte "drops out" of your
I2C stream. It's a synchronous protocol. Every time the clock goes,
the slave clocks a bit. I've seen extra bytes injected into the
system due to noise on the SCL line because the slave thought the
noise edges were actually clock edges. But dropping bytes, I'd grab a
decent logic analyzer and/or oscilloscope and take a look at the
actual signals being transmitted and make sure they are what you expect.

The bottom line is that asynchronous serial and I2C communications
were never designed to be robust. If you are getting noise in your
system that is flipping bits or messing with your clock, you really
want to fix that first.

--
-James
------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

The bottom line was that it wasn't noise. Upon further research, on
occasion, it is taking over 1 second to ACK one byte sent to the
display. I had a 1 second timer that jumped out of the wait for ACK
loop after 1 second. That appears not long enough on rare occasion
and causes missed bytes. I increased the time to 5 seconds and the
display seems to run smoothly after 4 hours. So, I guess one question
is 'why does it take over 1 second to ACK one byte sometimes?' and
what should the max wait time be?

To answer another response to this post, refreshing the screen is not
really an option if you don't have any other indication that the
screen is messed up other than visual.

Also, whether or not serial or I2C is not really robust (and I know it
isn't), I totally agree that design engineers should really look to
design systems to minimize any noise/interference affecting their
components. But, regardless, over time there are going to be missed
bytes. Nothing is 100% robust. Therefore, it is also imperative that
software engineers (I do both) design their software to be as robust
as possible too. I realize that embedded systems have a restricted
amount of code space, so I know there are tradeoffs. And, I know that
software can't solve all ills either, but you can't say that this is
just a hardware problem and ignore beefing up the software.

Sutton

--- In l...@yahoogroups.com, "jmctavish" wrote:
>
> --- In l...@yahoogroups.com, "Sutton Mehaffey" wrote:
> >
> > I'm interested in people's opinion on this. I am using a I2C
> > Graphical Display interfaced with a LPC2148. On occasion, the I2C
> > command sent out drops a byte which causes the command to be invalid.
> > This could be due to noise, interference, and the like. I haven't
> > determined exactly what causes this. However, I'm sure there are
> > going to be instances of this on occasion and that it needs to be
> > accounted for.
> >
> > The display doesn't have any ability to issue a NAK back for invalid
> > commands, whether bad parameter values, wrong number of parameters,
> > etc. It only sends a NAK back for buffer full, which I handle.
> > Therefore, I haven't figured out a way to reissue the display command
> > when bytes are dropped, because there is no way for me to know. The
> > display still tries to execute the invalid command and does weird
> things.
> >
> > I have a RTC that refreshes the display every second with the new
> > time, and on occasion (every 20 minutes or so), the time gets
> > displayed in other areas of the display. It's annoying and looks bad.
> > It could happen anytime, so that refreshing the screen is not the
> > solution, because you never know if it has happened unless you look at
> > the display.
> >
> > Shouldn't this be handled in the display? I think so. The display
> > company doesn't have immediate plans to do anything about it. They
> > say they don't have to code space. They have a serial version, but it
> > has the same protocol.
> >
> > Sutton
> > I happen to be the engineer that inherited the design of the display
> you're mentioning. It's easy to tell because I fielded this very
> question from our technical support team this morning. Before you go
> passing judgment, let me clarify a couple of things.
>
> We can't help you with your bytes getting changed in transit. Short
> of performing a CRC check of some kind, you can't really make a dent
> in that. Checking to see if the parameters are invalid really doesn't
> do you much good if the noise has changed the byte to something else
> that happens to still be valid.
>
> You might also want to dig further into why a byte "drops out" of your
> I2C stream. It's a synchronous protocol. Every time the clock goes,
> the slave clocks a bit. I've seen extra bytes injected into the
> system due to noise on the SCL line because the slave thought the
> noise edges were actually clock edges. But dropping bytes, I'd grab a
> decent logic analyzer and/or oscilloscope and take a look at the
> actual signals being transmitted and make sure they are what you expect.
>
> The bottom line is that asynchronous serial and I2C communications
> were never designed to be robust. If you are getting noise in your
> system that is flipping bits or messing with your clock, you really
> want to fix that first.
>
> --
> -James
>

------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Your latest post makes me think that I (and probably others)
have misunderstood your problem.

I2C is a synchronous protocol. An I2C ACK (or its absence a NACK)
occurs in the clock cycle immediately after the 8th data bit.

Is this the ACK you are talking about?

It is possible for an I2C peripheral to slow the bus down
by "clock stretching" i.e. holding SCL down until the peripheral
knows whether to do an ACK or a NACK.

Is your display doing clock-stretching? For a whole second?
This sounds wrong.

What I suspect is more likely is that the pull-up resistors
you have to supply for the I2C lines are somehow absent or
being defeated (e.g. by leakage through flux on the board).
I2C does not normally suffer from this - the pull-up resistors
are normally 1k to 10k Ohm. But they must be much higher
resistance when using a chip-on-glass peripheral such as an
LCD because the drive current of the LCD chip is tiny.

What value pull-up resistors are you using? And how fast
are you clocking the I2C?

Regards,
Danish

--- In l...@yahoogroups.com, "Sutton Mehaffey" wrote:
>
> The bottom line was that it wasn't noise. Upon further research, on
> occasion, it is taking over 1 second to ACK one byte sent to the
> display. I had a 1 second timer that jumped out of the wait for ACK
> loop after 1 second. That appears not long enough on rare occasion
> and causes missed bytes. I increased the time to 5 seconds and the
> display seems to run smoothly after 4 hours. So, I guess one question
> is 'why does it take over 1 second to ACK one byte sometimes?' and
> what should the max wait time be?

------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

10K and 100Khz. I haven't had any problems with my other I2C peripherals.
--- In l...@yahoogroups.com, "Danish Ali" wrote:
>
> Your latest post makes me think that I (and probably others)
> have misunderstood your problem.
>
> I2C is a synchronous protocol. An I2C ACK (or its absence a NACK)
> occurs in the clock cycle immediately after the 8th data bit.
>
> Is this the ACK you are talking about?
>
> It is possible for an I2C peripheral to slow the bus down
> by "clock stretching" i.e. holding SCL down until the peripheral
> knows whether to do an ACK or a NACK.
>
> Is your display doing clock-stretching? For a whole second?
> This sounds wrong.
>
> What I suspect is more likely is that the pull-up resistors
> you have to supply for the I2C lines are somehow absent or
> being defeated (e.g. by leakage through flux on the board).
> I2C does not normally suffer from this - the pull-up resistors
> are normally 1k to 10k Ohm. But they must be much higher
> resistance when using a chip-on-glass peripheral such as an
> LCD because the drive current of the LCD chip is tiny.
>
> What value pull-up resistors are you using? And how fast
> are you clocking the I2C?
>
> Regards,
> Danish
>
> --- In l...@yahoogroups.com, "Sutton Mehaffey" wrote:
> >
> > The bottom line was that it wasn't noise. Upon further research, on
> > occasion, it is taking over 1 second to ACK one byte sent to the
> > display. I had a 1 second timer that jumped out of the wait for ACK
> > loop after 1 second. That appears not long enough on rare occasion
> > and causes missed bytes. I increased the time to 5 seconds and the
> > display seems to run smoothly after 4 hours. So, I guess one question
> > is 'why does it take over 1 second to ACK one byte sometimes?' and
> > what should the max wait time be?
>

------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, "Danish Ali" wrote:
>
> Your latest post makes me think that I (and probably others)
> have misunderstood your problem.
>
> I2C is a synchronous protocol. An I2C ACK (or its absence a NACK)
> occurs in the clock cycle immediately after the 8th data bit.
>
> Is this the ACK you are talking about?
>
> It is possible for an I2C peripheral to slow the bus down
> by "clock stretching" i.e. holding SCL down until the peripheral
> knows whether to do an ACK or a NACK.
>
> Is your display doing clock-stretching? For a whole second?
> This sounds wrong.
>

I'm not surprised that the display would revert to clock stretching. I
agree that it is not a good thing, but I'm still not surprised.

It is my experience (based on PC graphics) that a common problem with
graphics cards back in the 90's was that the graphics device driver
(running on the host) tried to push as much data as possible to the
display, as fast as possible. The problem was that the speed at which
the graphics card could consume that data was SLOW when compared to
the speed at which the host could send it. So, the only choice the
graphics card had was to insert wait states (on PCI systems, this
meant many "retries"). I personally witnessed systems where this
persisted for many seconds even in "high-end" systems of the time.
This was clearly a problem (and it did eventually get addressed... see
the end of this reply for the solution).

Now back to I2C. I would imagine that a display controller connected
via I2C is not built for speed. So, it seems very plausible that the
pace at which the I2C master (the host) sends data to the I2C display
is faster than the display can process it. So what can the display do?

If it NACKs the I2C transaction it is likely to cause an error in the
I2C master. This means that the code in the I2C master has to be
written to handle this error as a "retry". I doubt the master has
support for this. It becomes difficult to distinguish between an
intentional "retry" and a real "error" that results in a NACK.

SO... the safe (simple) thing for the display to do is to revert to an
I2C wait state (in the hope that the I2C master doesn't time out).

One solution to this is pace the rate at which the I2C master sends
data to the display so that the wait state is avoided.

Alternatively, if the display has some sort of buffer, and it is
possible for the I2C master to read the amount of free space available
in the buffer before sending data, then the I2C master can be written
to avoid overflowing the device (thus causing the wait state
behavior). This is the approach that was taken to resolve the issue
with PC graphics cards that I mentioned.

TC
------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

What I do is if I get a NAK, I wait 50ms, and then send again trying
to allow the display some catchup time.

One of the problems is the NAK is just a handshake/buffer full. I was
told some time ago by the engineer that I didn't need to resend the
entire command after a NAK, just continue with the byte that was
NAKed. That made me think of the possibility that the display could
accept commands that are invalid or at least not let the master know
of invalid commands. And, I found that loophole.

I think the buffer on this display is 128 characters. So, with my
clock update sending 3 commands per second (~25 bytes), I can't
imagine why it is taking over 1 second on occasion to ACK a byte.

By the way, their tech support has been exceptional and they have been
working with me with problems I've found for several months. They
don't have a tremendous demand for the I2C versions, but the interest
is growing.

Sutton

--- In l...@yahoogroups.com, "tcirobot" wrote:
>
> --- In l...@yahoogroups.com, "Danish Ali" wrote:
> >
> > Your latest post makes me think that I (and probably others)
> > have misunderstood your problem.
> >
> > I2C is a synchronous protocol. An I2C ACK (or its absence a NACK)
> > occurs in the clock cycle immediately after the 8th data bit.
> >
> > Is this the ACK you are talking about?
> >
> > It is possible for an I2C peripheral to slow the bus down
> > by "clock stretching" i.e. holding SCL down until the peripheral
> > knows whether to do an ACK or a NACK.
> >
> > Is your display doing clock-stretching? For a whole second?
> > This sounds wrong.
> > I'm not surprised that the display would revert to clock stretching. I
> agree that it is not a good thing, but I'm still not surprised.
>
> It is my experience (based on PC graphics) that a common problem with
> graphics cards back in the 90's was that the graphics device driver
> (running on the host) tried to push as much data as possible to the
> display, as fast as possible. The problem was that the speed at which
> the graphics card could consume that data was SLOW when compared to
> the speed at which the host could send it. So, the only choice the
> graphics card had was to insert wait states (on PCI systems, this
> meant many "retries"). I personally witnessed systems where this
> persisted for many seconds even in "high-end" systems of the time.
> This was clearly a problem (and it did eventually get addressed... see
> the end of this reply for the solution).
>
> Now back to I2C. I would imagine that a display controller connected
> via I2C is not built for speed. So, it seems very plausible that the
> pace at which the I2C master (the host) sends data to the I2C display
> is faster than the display can process it. So what can the display do?
>
> If it NACKs the I2C transaction it is likely to cause an error in the
> I2C master. This means that the code in the I2C master has to be
> written to handle this error as a "retry". I doubt the master has
> support for this. It becomes difficult to distinguish between an
> intentional "retry" and a real "error" that results in a NACK.
>
> SO... the safe (simple) thing for the display to do is to revert to an
> I2C wait state (in the hope that the I2C master doesn't time out).
>
> One solution to this is pace the rate at which the I2C master sends
> data to the display so that the wait state is avoided.
>
> Alternatively, if the display has some sort of buffer, and it is
> possible for the I2C master to read the amount of free space available
> in the buffer before sending data, then the I2C master can be written
> to avoid overflowing the device (thus causing the wait state
> behavior). This is the approach that was taken to resolve the issue
> with PC graphics cards that I mentioned.
>
> TC
>

------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

I've heard that 1K - 10K are standard values of pullups on the I2C
bus. Does this vary with what bus speed you are running? I'm using
10K now, but I was told I might should go with 4.7K.

Sutton

--- In l...@yahoogroups.com, "Danish Ali" wrote:
>
> Your latest post makes me think that I (and probably others)
> have misunderstood your problem.
>
> I2C is a synchronous protocol. An I2C ACK (or its absence a NACK)
> occurs in the clock cycle immediately after the 8th data bit.
>
> Is this the ACK you are talking about?
>
> It is possible for an I2C peripheral to slow the bus down
> by "clock stretching" i.e. holding SCL down until the peripheral
> knows whether to do an ACK or a NACK.
>
> Is your display doing clock-stretching? For a whole second?
> This sounds wrong.
>
> What I suspect is more likely is that the pull-up resistors
> you have to supply for the I2C lines are somehow absent or
> being defeated (e.g. by leakage through flux on the board).
> I2C does not normally suffer from this - the pull-up resistors
> are normally 1k to 10k Ohm. But they must be much higher
> resistance when using a chip-on-glass peripheral such as an
> LCD because the drive current of the LCD chip is tiny.
>
> What value pull-up resistors are you using? And how fast
> are you clocking the I2C?
>
> Regards,
> Danish
>
> --- In l...@yahoogroups.com, "Sutton Mehaffey" wrote:
> >
> > The bottom line was that it wasn't noise. Upon further research, on
> > occasion, it is taking over 1 second to ACK one byte sent to the
> > display. I had a 1 second timer that jumped out of the wait for ACK
> > loop after 1 second. That appears not long enough on rare occasion
> > and causes missed bytes. I increased the time to 5 seconds and the
> > display seems to run smoothly after 4 hours. So, I guess one question
> > is 'why does it take over 1 second to ACK one byte sometimes?' and
> > what should the max wait time be?
>

------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

I found that running at 400 Khz, I needed to use 2K. I started with 10K
but the rise times were awful at that speed.
Sutton Mehaffey wrote:
>
> I've heard that 1K - 10K are standard values of pullups on the I2C
> bus. Does this vary with what bus speed you are running? I'm using
> 10K now, but I was told I might should go with 4.7K.
>
> Sutton
>
> --- In l...@yahoogroups.com ,
> "Danish Ali" wrote:
> >
> > Your latest post makes me think that I (and probably others)
> > have misunderstood your problem.
> >
> > I2C is a synchronous protocol. An I2C ACK (or its absence a NACK)
> > occurs in the clock cycle immediately after the 8th data bit.
> >
> > Is this the ACK you are talking about?
> >
> > It is possible for an I2C peripheral to slow the bus down
> > by "clock stretching" i.e. holding SCL down until the peripheral
> > knows whether to do an ACK or a NACK.
> >
> > Is your display doing clock-stretching? For a whole second?
> > This sounds wrong.
> >
> > What I suspect is more likely is that the pull-up resistors
> > you have to supply for the I2C lines are somehow absent or
> > being defeated (e.g. by leakage through flux on the board).
> > I2C does not normally suffer from this - the pull-up resistors
> > are normally 1k to 10k Ohm. But they must be much higher
> > resistance when using a chip-on-glass peripheral such as an
> > LCD because the drive current of the LCD chip is tiny.
> >
> > What value pull-up resistors are you using? And how fast
> > are you clocking the I2C?
> >
> > Regards,
> > Danish
> >
> > --- In l...@yahoogroups.com ,
> "Sutton Mehaffey" wrote:
> > >
> > > The bottom line was that it wasn't noise. Upon further research, on
> > > occasion, it is taking over 1 second to ACK one byte sent to the
> > > display. I had a 1 second timer that jumped out of the wait for ACK
> > > loop after 1 second. That appears not long enough on rare occasion
> > > and causes missed bytes. I increased the time to 5 seconds and the
> > > display seems to run smoothly after 4 hours. So, I guess one question
> > > is 'why does it take over 1 second to ACK one byte sometimes?' and
> > > what should the max wait time be?
> >
[Non-text portions of this message have been removed]
------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Sutton Mehaffey wrote:
>
> Also, whether or not serial or I2C is not really robust (and I know it
> isn't), I totally agree that design engineers should really look to
> design systems to minimize any noise/interference affecting their
> components. But, regardless, over time there are going to be missed
> bytes. Nothing is 100% robust. Therefore, it is also imperative that
> software engineers (I do both) design their software to be as robust
> as possible too. I realize that embedded systems have a restricted
> amount of code space, so I know there are tradeoffs. And, I know that
> software can't solve all ills either, but you can't say that this is
> just a hardware problem and ignore beefing up the software.
I fully agree on this all, Sutton.

--
Ciao, Dario
--
Cyberdyne
--
http://www.ecyberdyne.tk

------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, Dave Such wrote:
>
> I found that running at 400 Khz, I needed to use 2K. I started with
10K
> but the rise times were awful at that speed.
>

The I2C spec if readily available:
http://www.nxp.com/acrobat_download/usermanuals/UM10204_3.pdf

There is a section (7.1) that specifically deals with the pull-up
resistors.

The pull-up value is a function of speed, capacitance and Vdd. For
fast and standard mode and Vdd=5V, a value of 1.5k would be the
minimum and for fast mode with 100 pf capacitance the max value would
be around 3.5k. Often a value around 2.2k is used.

Values around 10k will only work in standard mode with < 100 pf
capacitance.

Richard

------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Hi Sutton,

Resistance, bus speed and bus length (stray capacitance)
are all linked.

I2C uses open-drain outputs to pull the lines to logic 0
and then the pull-up resistor to go to logic 1 (fighting
against the stray capacitance on the bus).

Have a look at the waveform on an oscilloscope - the rise to
logic 1 will not be as sharp as the fall to logic 0 - but
as long as the rise to 90% is within about half a bit-period
things should work without issue.

Is it better to reduce the I2C bus speed or reduce the
resistance if the rise-time is poor?
That's a system choice. But you might find that the
LCD controller's open-drain outputs are very feeble
and that they struggle to reach logic 0 with any value
smaller than 10kOhm. Check the LCD data sheet (if they
specify what the min drive current or min resistance).
And also check that the ACK back from the LCD is
solidly logic 0.

Why are LCDs particularly bad in this respect?
Because the "wires" between the chip and the connector
are often very thin (and transparent) and the series
resistance can be significant.

Regards,
Danish
--- In l...@yahoogroups.com, "Sutton Mehaffey" wrote:
>
> I've heard that 1K - 10K are standard values of pullups on the I2C
> bus. Does this vary with what bus speed you are running? I'm using
> 10K now, but I was told I might should go with 4.7K.
>
> Sutton

------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )