--- In l..., "Brendan Murphy"
wrote:

> > It is quite clear that the problem is not restricted to error bits
> as
> > you cliam. That is my point.
> >
> > You have to ask yourself if DR is set when there is a framing or
> > parity error, and if FE or PE is lost, what happens to the DR bit.
> >
> > You also have to ask yourself the what happens when the FIFO is 16
> > deep, but there is only one status register with the error and DR
> bits.
>
> This is pointless: the text is there for anyone to read.

No argument here. You should not be surprised you are not able to
repeat my results if you do not have the right equipment or if you do
not design the test to look for the particular fact you want verified.

For what it is worth, what took me more than six weeks on LPC to
implement took only a good part of four days to implement on OKI.

Funnily enough, this is despite the langage in the OKI manual being
difficult to read, for example:

> CLKSEL should be set before START bit setting, if application
> need correct timer interval. Because timer start count with
> maximum 6 count by the clock that selected by CLKSEL before
> this register write.

I prefer a bad English good design to good English bad design anytime!

Jaya Start a New Thread

--- In l..., "jayasooriah" wrote:
> No argument here. You should not be surprised you are not able to
> repeat my results if you do not have the right equipment or if you do
> not design the test to look for the particular fact you want
verified.
>

Eh?

I was trying to verify your claim the UART dropped characters at low
bit rates when there are no gaps between the received characters. I
verified these conditions, as I described in the test results. If your
tests needed some special equipment or other condition, maybe you
should have shared this information before presenting the claim?

Anyway, it's not for me or anyone else to proove the parts behave as
described in the manuals (as ammended by the errata), but for the
person making a claim that they behave differently. As nobody seems
able to reproduce your test results (a fairly standard requirement of
anyone presenting a theory to explain observed bahviour), your claim
is just that: a claim.

Brendan Start a New Thread

--- In l..., "Brendan Murphy"
wrote:
>
> --- In l..., "jayasooriah" wrote:
> > No argument here. You should not be surprised you are not able to
> > repeat my results if you do not have the right equipment or if you do
> > not design the test to look for the particular fact you want
> verified.
> > Eh?
>
> I was trying to verify your claim the UART dropped characters at low
> bit rates when there are no gaps between the received characters. I
> verified these conditions, as I described in the test results. If your
> tests needed some special equipment or other condition, maybe you
> should have shared this information before presenting the claim?

Look Brendan. Call it whatever you want. I have presented tests and
the results. It is on public record.

Others have independently verified my findings. There is little point
making endless requests for more information.

Have a nice day.

Jaya Start a New Thread

--- In l..., "jayasooriah" wrote:

> Look Brendan. Call it whatever you want. I have presented tests and
> the results. It is on public record.
>
> Others have independently verified my findings. There is little point
> making endless requests for more information.
>
> Have a nice day.
>
> Jaya
>

Look, Jaya. The UARTs behave as described in the maunual, as ammended
by the errata. I have presented tests and the results. It is on
public record.

Nobody has independently verified your own claims to the contrary and
been prepared to say in a public forum that they have. There is little
point in making endless assertions there is some undocumented flaw in
the UARTs when your own test results cannot be replicated.

Have a nice day.

Brendan. Start a New Thread

Errrm not wishing to prolong this conversation but who has independantly
verified this? I've not seen a post from anyone who has actually verified
that the UART does indeed have the issue you claim - did I miss something?.
It appears to be working fine for the 2129 I tested it on.

Andy
-----Original Message-----
From: l... [mailto:l...]On Behalf Of
jayasooriah
Sent: 18 August 2006 02:41
To: l...
Subject: [lpc2000] Re: UART1 problem receiving but ok transmitt
--- In l..., "Brendan Murphy"
wrote:
>
> --- In l..., "jayasooriah" wrote:
> > No argument here. You should not be surprised you are not able to
> > repeat my results if you do not have the right equipment or if you do
> > not design the test to look for the particular fact you want
> verified.
> >
>
> Eh?
>
> I was trying to verify your claim the UART dropped characters at low
> bit rates when there are no gaps between the received characters. I
> verified these conditions, as I described in the test results. If your
> tests needed some special equipment or other condition, maybe you
> should have shared this information before presenting the claim?

Look Brendan. Call it whatever you want. I have presented tests and
the results. It is on public record.

Others have independently verified my findings. There is little point
making endless requests for more information.

Have a nice day.

Jaya Start a New Thread

Hi All,

Some comments back on my own post.

I have tried with blinking a led every time I'm supposed to received a
char and that LED is blinking rock solid (even if it doesn't say if
it's a correct received char ;-) ).

Second, I tested against a RS-232 chip instead and it was rock solid
echoing of the char I sent to it so I presume, once again, that the
actual code for receiving and sending is ok and it's something with
timing or simular that makes it go wrong when using the RS485 chip.

As I can send without any problem it looks like, and I have verified
the schema/pcb many times now, the connections between LPC2106 and the
MAXIM circuit should be fine.

So, doing a test with interrupt handling on the comms RX part could be
worth it. Shall have a look at the errata also.

Someone here that have worked with the MAX1480B chip?

Thanks for all the input and comments so far. Anything more of ideas
or thoughts are, as before, very very welcome.

Cheers
/Johan

--- In l..., "fredrikssonjohan" wrote:
>
> Hi!
>
> I'm stucked with this and can't figure out why it will not work.
> Anyone seeing the obvious or have any friendly ideas of what might be
> wrong?
>
> OK. I'll try to give an as good description as possible of what I have
> and try do. The first problem is that if I send, as a test, 8 "A" I
> will get 4 or 5 "A"s in return and then one or two non ascii visible
> chars and mostly a FF as end. I would say the successrate is 3-4 per
> 20 sent blocks of 8 "A". So there is my problem. No clean RX on the
> LPC2106 with this MAX1480B.
>
> There is a LPC2106 connected via a 74HC86 and finally the Maxim
> MAX1480B opto/power isolated circuit. This is all connected as per
> MAXIMSs datasheet and work 100% when sending data. Never miss a single
> bit.
> As I never have any TX problem I figure that the init part of the port
> should be OK.
>
> As a stripped down testing routine I do the following:
> while (1)
> {
> cbuff[icnt] = wait_and_receive();
> icnt++;
>
> if (icnt == 8)
> {
> icnt = 0;
> IOSET = (1< > pause(TWO_MS);
> for (int j = 0; j < 8; j++)
> uart1Putch(cbuff[j]);
>
> // Back to RX mode again
> IOCLR = (1< > pause(TWO_MS);
> }
> }
>
> Im just waiting for any char in the RX buffer and switch to RS486 TX
> mode and send it back. Added a small delay after switching mode on the
> RS485 line just to be sure.
>
> Using this bit just for pool until there is a char available
> int wait_and_receive(void)
> {
> int ch;
>
> while((ch = uart1Getch()) == -1) {
> ;
> }
> return ch;
> }
>
> And this is the actual code checking if the is a char available.
> The uart1Getch(...) loooks like this:
> if (U1LSR & ULSR_RDR) // check if character is available
> return U1RBR; // return character
> return -1;
>
> The init is done by this and works perfect for TX
> void uart1Init(uint16_t baud, uint8_t mode, uint8_t fmode)
> {
> // set port pins for UART1
> PINSEL0 = (PINSEL0 & ~U1_PINMASK) | U1_PINSEL;
>
> U1IER = 0x00; // disable all interrupts
> U1IIR; // clear interrupt ID
> U1RBR; // clear receive register
> U1LSR; // clear line status register
>
> // set the baudrate
> U1LCR = ULCR_DLAB_ENABLE; // select divisor latches
> U1DLL = (uint8_t)baud; // set for baud low byte
> U1DLM = (uint8_t)(baud >> 8); // set for baud high byte
> U1LCR = (mode & ~ULCR_DLAB_ENABLE);
> U1FCR = fmode;
> }
>
> Wow, sorry for the long message and code, but otherwise I guess
> someone is asking how that and that is done so I include it from the
> start.
>
> If anyone have a clue or idea I would be very happy guy!
>
> Cheers
> Johan
> Start a New Thread

For RS485...

- Make sure you pull up A/'+' signal and Pull down B/'-' signal on
the RS485 bus
- Make sure you use TEMT to disable your RS485 driver. Do NOT
disable the RS485 driver immediately after you write the
character to UART. That character will be slowly shifted out
and only completed shifting out of the UART when TEMT is set.
- RS485 is half-duplex, if you do not disable the RS485 receiver
when transmitting, there will be character echo-ed back to UART
receiver every time you transmit a character
- For some RS485 interface parts, there might be "glitches" on the
bus signal when you disable the RS485 driver (but this normally
get filtered off by the UART receiver)

Sorry, cannot think of anything else... and Good Luck
Regards

BTW: I was actually happen to use that MAX1480 in the planning.
Please give some info of the problem after all this... :)

--- In l..., "fredrikssonjohan" wrote:
>
> Hi All,
>
> Some comments back on my own post.
>
> I have tried with blinking a led every time I'm supposed to
received a
> char and that LED is blinking rock solid (even if it doesn't say if
> it's a correct received char ;-) ).
>
> Second, I tested against a RS-232 chip instead and it was rock
solid
> echoing of the char I sent to it so I presume, once again, that the
> actual code for receiving and sending is ok and it's something with
> timing or simular that makes it go wrong when using the RS485 chip.
>
> As I can send without any problem it looks like, and I have
verified
> the schema/pcb many times now, the connections between LPC2106 and
the
> MAXIM circuit should be fine.
>
> So, doing a test with interrupt handling on the comms RX part
could be
> worth it. Shall have a look at the errata also.
>
> Someone here that have worked with the MAX1480B chip?
>
> Thanks for all the input and comments so far. Anything more of
ideas
> or thoughts are, as before, very very welcome.
>
> Cheers
> /Johan
>
> --- In l..., "fredrikssonjohan" wrote:
> >
> > Hi!
> >
> > I'm stucked with this and can't figure out why it will not work.
> > Anyone seeing the obvious or have any friendly ideas of what
might be
> > wrong?
> >
> > OK. I'll try to give an as good description as possible of what
I have
> > and try do. The first problem is that if I send, as a test,
8 "A" I
> > will get 4 or 5 "A"s in return and then one or two non ascii
visible
> > chars and mostly a FF as end. I would say the successrate is 3-4
per
> > 20 sent blocks of 8 "A". So there is my problem. No clean RX on
the
> > LPC2106 with this MAX1480B.
> >
> > There is a LPC2106 connected via a 74HC86 and finally the Maxim
> > MAX1480B opto/power isolated circuit. This is all connected as
per
> > MAXIMSs datasheet and work 100% when sending data. Never miss a
single
> > bit.
> > As I never have any TX problem I figure that the init part of
the port
> > should be OK.
> >
> > As a stripped down testing routine I do the following:
> > while (1)
> > {
> > cbuff[icnt] = wait_and_receive();
> > icnt++;
> >
> > if (icnt == 8)
> > {
> > icnt = 0;
> > IOSET = (1< > > pause(TWO_MS);
> > for (int j = 0; j < 8; j++)
> > uart1Putch(cbuff[j]);
> >
> > // Back to RX mode again
> > IOCLR = (1< > > pause(TWO_MS);
> > }
> > }
> >
> > Im just waiting for any char in the RX buffer and switch to
RS486 TX
> > mode and send it back. Added a small delay after switching mode
on the
> > RS485 line just to be sure.
> >
> > Using this bit just for pool until there is a char available
> > int wait_and_receive(void)
> > {
> > int ch;
> >
> > while((ch = uart1Getch()) == -1) {
> > ;
> > }
> > return ch;
> > }
> >
> > And this is the actual code checking if the is a char available.
> > The uart1Getch(...) loooks like this:
> > if (U1LSR & ULSR_RDR) // check if character is available
> > return U1RBR; // return character
> > return -1;
> >
> > The init is done by this and works perfect for TX
> > void uart1Init(uint16_t baud, uint8_t mode, uint8_t fmode)
> > {
> > // set port pins for UART1
> > PINSEL0 = (PINSEL0 & ~U1_PINMASK) | U1_PINSEL;
> >
> > U1IER = 0x00; // disable all interrupts
> > U1IIR; // clear interrupt ID
> > U1RBR; // clear receive register
> > U1LSR; // clear line status
register
> >
> > // set the baudrate
> > U1LCR = ULCR_DLAB_ENABLE; // select divisor
latches
> > U1DLL = (uint8_t)baud; // set for baud low byte
> > U1DLM = (uint8_t)(baud >> 8); // set for baud high byte
> > U1LCR = (mode & ~ULCR_DLAB_ENABLE);
> > U1FCR = fmode;
> > }
> >
> > Wow, sorry for the long message and code, but otherwise I guess
> > someone is asking how that and that is done so I include it from
the
> > start.
> >
> > If anyone have a clue or idea I would be very happy guy!
> >
> > Cheers
> > Johan
> Start a New Thread

--- In l..., "Andrew Berney" wrote:
>
> Errrm not wishing to prolong this conversation but who has independantly
> verified this? I've not seen a post from anyone who has actually
verified
> that the UART does indeed have the issue you claim - did I miss
something?.
> It appears to be working fine for the 2129 I tested it on.
>
> Andy

Andy,

My information is the this problem is readily replicated using the
image I provided on other (A version) variants besides the 2292/0510
on which I conducted the tests when FT232BM based dongle is used.

What is the date codes on your FT232BM and LPC2129 chips, and what
crystals frequencies are you using on these?

Jaya Start a New Thread

--- In l..., "jayasooriah" wrote:
>
> --- In l..., "Brendan Murphy"
> wrote:
> >
> > --- In l..., "jayasooriah"
wrote:
> > > No argument here. You should not be surprised you are not able
to
> > > repeat my results if you do not have the right equipment or if
you do
> > > not design the test to look for the particular fact you want
> > verified.
> > >
> >
> > Eh?
> >
> > I was trying to verify your claim the UART dropped characters at
low
> > bit rates when there are no gaps between the received characters.
I
> > verified these conditions, as I described in the test results. If
your
> > tests needed some special equipment or other condition, maybe you
> > should have shared this information before presenting the claim?
>
> Look Brendan. Call it whatever you want. I have presented tests and
> the results. It is on public record.
>
> Others have independently verified my findings. There is little
point
> making endless requests for more information.
>

This is not helpful. I believe Brendan made an honest attempt and has
come to the conclusion your results are not repeatable within the
parameters you state or imply.

I wonder what "independent verfification" means here? Some university
students in a hurry plagirising results?

John Heenan

> Have a nice day.
>
> Jaya
> Start a New Thread

--- In l..., "John Heenan" wrote:

> This is not helpful. I believe Brendan made an honest attempt and has
> come to the conclusion your results are not repeatable within the
> parameters you state or imply.

Perhaps Brendan's attempts are as honest as your comments are helpful :)

> I wonder what "independent verfification" means here? Some
> university students in a hurry plagirising results?

I find students these days have much better things to do!!!

On a more serious note, the people who pay me to solve such problems,
this problem in particular, have verified my findings and moved on.

I thought it would be useful to document it for the benefit of others
who may find themselves in a similar situation.

I certainly did not mean it to be an exercise for Brendan to see if
can stimulate the LPC and create the race conditions as I and others
have been able to.

Jaya Start a New Thread