This is an elaboration of bandwidth and other issues with regard to
FTDI USB-RS232 convertor chips that have relevancy with regard to any
report that attempts to assess UARTs external to a PC using USB-RS232
convertors. In fact I really think it is not even worth the effort of
attempting to overcome all the possible problems with regard to
producing a credible report using USB-RS232 convertor chips.

FTDI chips can be switched between using bulk or isochronous USB
endpoints. Endpoints are serviced once every millisecond for
isochronous endpoints and up to a maximum of once every millisecond
for bulk endpoints. Bulk USB endpoints provide accurate data transfer
but non guaranteed bandwidth up to a maximum of 64KBytes per second
per enabled bulk USB endpoint (according to the USB 2.0 high speed
standard). Isochronous endpoints provide non accurate throughput up
to a maximum of 1023KByes per second per enabled endpoint (according
to the USB 2.0 high speed standard)

FTDI chips also contain a 128 byte transmit buffer and a 384 byte
receive buffer. This is necessary due to the one millisecond USB
endpoint servicing scheduling issue.

On the PC driver side the FTDI driver also has its issues. These are
discussed in FTDI chip application notes available at
www.ftdichip.com. Two drivers can be used: one through a regulat COM
port opening and the other using a more direct driver.

For a driver not to miss a character it must be requested by an
application in time, so as the driver can request the characters from
the chips buffer. If characters are not removed from the chips buffer
new characters are lost.

Just because a driver has received a character does not mean the
application will get the character. It is common knowledge and
expected behaviour that PC applications that use UARTs will lose
characters under load, although there are means to minimise this.
Also configuration of COM ports is complex and must be thoroughly
checked. That is why no report can be complete without a full
disclosure of source code or certification of a PC application. Also
other issues have relevancy, such as the CPU load on a PC.

John Heenan

--- In l..., "John Heenan" wrote:
>
> This is with regard to the claim of Jaya that the LPC UART is
faulty.
>
> Jaya is a university staff member in New South Wales Australia who
> gets paid from public tax payers money. As such he has an automatic
> standing and so we should expect certain standards. Also Jaya
> deliberately conducts himself in a style that attempts to portray
an
> image that he is a credible expert. However Jaya has not helped
> Brendan reconcile differences in results and Jaya has failed to
> provide complete information.
>
> Please note I am not making a claim that Jaya's results are not
true.
>
> 1. Brendan attempted to reproduce Jaya's claims and was not able
to.
> Brendan provided more complete information than Jaya.
>
> 2. Jaya's report is incomplete. Jaya has not provided a copy of the
> source code of PC program he used when testing the bootloader
> firmware (nite.exe). He also failed to provide a complete copy of
the
> source for test.hex firmware so we cannot investigate this side of
> the set-up also. He also used an FTDI chip but no where mentioned
if
> he used default or special configuration values for the FTDI
driver.
>
> 3. There are delay and latency issues with FTDI chips. FTDI Chip is
> open about this and no where claims their chips emulate real UARTS
> faithfully. Nor does FTDI Chip make any claims about
> having 'professional' performance, however that might be defined (I
> have not seen the word 'professional' used in any set of credible
> specifications). FTDI also makes it clear that data can be lost and
> advises use of flow control. Since FTDI Chip uses USB data can only
> be read and written within the bandwidth slots permitted by USB,
> which cannot be faster than 64 byte chunks once per millisecond for
> USB High Speed for each enabled USB endpoint. In fact FTDI chips
> reserve two bytes for their own use during each IN endpoint
transfer.
>
> 4. The Philips bootloader uses Xon/Xoff flow control. This is
clearly
> stated in the documentation. I have yet to see a single open source
> bootloader that includes Xon/Xoff flow control.
>
> 5. Jaya complained that it took him six weeks to master using
Philips
> UARTs. This appears bizarere as Philips uses a UART register layout
> and interrupt conventions that are as old as the first PCs. The LPC
> UART layout follows the '550 industry standard.
>
> 6. Philips follows the interrupt '550 industry standard so closely
> that they had to break a VIC rule mandated by ARM with regard to
not
> allowing the source of an interrupt disappear. However Philips
> clearly points out a way to work around this problem. Hence it is
not
> an unsolvable problem.
>
> John Heenan
>
> --- In l..., "jayasooriah" wrote:
> >
> > --- In l..., "Brendan Murphy"

> > wrote:
> > >
> > > --- In l..., "jayasooriah"
> > > wrote:
> > >
> > > > Bear in mind that no matter what converter you use, you may
get
> LPC
> > > > UARTs working incorrectly for some weird combination of CPU
> > > crystals
> > > > and baudrates.
> > > >
> > >
> > > Jaya,
> > >
> > > You keep repeating this claim without providing specific
> > > information, though I note the claim is now more restricted
than
> > > previously.
> > >
> > > Can you provide even one specific combination of crystal and
baud
> > > rate that doesn't work? If not, I'd ask you to please stop
making
> > > this claim.
> > >
> > > If the parts do indeed have an issue under certain
circumstances
> > > then it is valuable information to know exactly what the issue
is
> > > and what the circumstances are when it arises. If they don't
have
> an
> > > issue than repeating inaccurate information devalues the entire
> > > group.
> > >
> > > Thanks!
> > >
> > > Brendan
> >
> > Thanks to an alert by a fellow forum member, the issue has been
> quite
> > adequately documented here:
> >
> > http://www.cse.unsw.edu.au/~jayas/esdk/lpc2/limitations.html
> >
> > This was written some time ago and nothing has changed in respect
of
> > my findings reported.
> >
> > I say "alert" in my opening remark because my filter now seems to
> > working reasonably well in weeding out Brendan's posts :)
> >
> > Jaya
> Start a New Thread

There is a very simple way to that may help conclusively resolve this
issue with a minimal amount of effort. Simply set up a
microcontroller to passively monitor and record what is coming
directly from the LPC UART Tx pin and compare it later with what the
FTDI chip and nite reported. The LPC UART Rx pin can also be
directly monitored from a different UART to see what FTDI chip and
nite sent. If UARTS are not trusted to monitor then rise/fall
interrupt capture times can be recorded.

John Heenan

--- In l..., "John Heenan" wrote:
>
> This is an elaboration of bandwidth and other issues with regard to
> FTDI USB-RS232 convertor chips that have relevancy with regard to
any
> report that attempts to assess UARTs external to a PC using USB-
RS232
> convertors. In fact I really think it is not even worth the effort
of
> attempting to overcome all the possible problems with regard to
> producing a credible report using USB-RS232 convertor chips.
>
> FTDI chips can be switched between using bulk or isochronous USB
> endpoints. Endpoints are serviced once every millisecond for
> isochronous endpoints and up to a maximum of once every millisecond
> for bulk endpoints. Bulk USB endpoints provide accurate data
transfer
> but non guaranteed bandwidth up to a maximum of 64KBytes per second
> per enabled bulk USB endpoint (according to the USB 2.0 high speed
> standard). Isochronous endpoints provide non accurate throughput up
> to a maximum of 1023KByes per second per enabled endpoint
(according
> to the USB 2.0 high speed standard)
>
> FTDI chips also contain a 128 byte transmit buffer and a 384 byte
> receive buffer. This is necessary due to the one millisecond USB
> endpoint servicing scheduling issue.
>
> On the PC driver side the FTDI driver also has its issues. These
are
> discussed in FTDI chip application notes available at
> www.ftdichip.com. Two drivers can be used: one through a regulat
COM
> port opening and the other using a more direct driver.
>
> For a driver not to miss a character it must be requested by an
> application in time, so as the driver can request the characters
from
> the chips buffer. If characters are not removed from the chips
buffer
> new characters are lost.
>
> Just because a driver has received a character does not mean the
> application will get the character. It is common knowledge and
> expected behaviour that PC applications that use UARTs will lose
> characters under load, although there are means to minimise this.
> Also configuration of COM ports is complex and must be thoroughly
> checked. That is why no report can be complete without a full
> disclosure of source code or certification of a PC application.
Also
> other issues have relevancy, such as the CPU load on a PC.
>
> John Heenan
>
> --- In l..., "John Heenan" wrote:
> >
> > This is with regard to the claim of Jaya that the LPC UART is
> faulty.
> >
> > Jaya is a university staff member in New South Wales Australia
who
> > gets paid from public tax payers money. As such he has an
automatic
> > standing and so we should expect certain standards. Also Jaya
> > deliberately conducts himself in a style that attempts to portray
> an
> > image that he is a credible expert. However Jaya has not helped
> > Brendan reconcile differences in results and Jaya has failed to
> > provide complete information.
> >
> > Please note I am not making a claim that Jaya's results are not
> true.
> >
> > 1. Brendan attempted to reproduce Jaya's claims and was not able
> to.
> > Brendan provided more complete information than Jaya.
> >
> > 2. Jaya's report is incomplete. Jaya has not provided a copy of
the
> > source code of PC program he used when testing the bootloader
> > firmware (nite.exe). He also failed to provide a complete copy of
> the
> > source for test.hex firmware so we cannot investigate this side
of
> > the set-up also. He also used an FTDI chip but no where mentioned
> if
> > he used default or special configuration values for the FTDI
> driver.
> >
> > 3. There are delay and latency issues with FTDI chips. FTDI Chip
is
> > open about this and no where claims their chips emulate real
UARTS
> > faithfully. Nor does FTDI Chip make any claims about
> > having 'professional' performance, however that might be defined
(I
> > have not seen the word 'professional' used in any set of credible
> > specifications). FTDI also makes it clear that data can be lost
and
> > advises use of flow control. Since FTDI Chip uses USB data can
only
> > be read and written within the bandwidth slots permitted by USB,
> > which cannot be faster than 64 byte chunks once per millisecond
for
> > USB High Speed for each enabled USB endpoint. In fact FTDI chips
> > reserve two bytes for their own use during each IN endpoint
> transfer.
> >
> > 4. The Philips bootloader uses Xon/Xoff flow control. This is
> clearly
> > stated in the documentation. I have yet to see a single open
source
> > bootloader that includes Xon/Xoff flow control.
> >
> > 5. Jaya complained that it took him six weeks to master using
> Philips
> > UARTs. This appears bizarere as Philips uses a UART register
layout
> > and interrupt conventions that are as old as the first PCs. The
LPC
> > UART layout follows the '550 industry standard.
> >
> > 6. Philips follows the interrupt '550 industry standard so
closely
> > that they had to break a VIC rule mandated by ARM with regard to
> not
> > allowing the source of an interrupt disappear. However Philips
> > clearly points out a way to work around this problem. Hence it is
> not
> > an unsolvable problem.
> >
> > John Heenan
> >
> > --- In l..., "jayasooriah"
wrote:
> > >
> > > --- In l..., "Brendan Murphy"
>
> > > wrote:
> > > >
> > > > --- In l..., "jayasooriah"
> > > > wrote:
> > > >
> > > > > Bear in mind that no matter what converter you use, you may
> get
> > LPC
> > > > > UARTs working incorrectly for some weird combination of CPU
> > > > crystals
> > > > > and baudrates.
> > > > >
> > > >
> > > > Jaya,
> > > >
> > > > You keep repeating this claim without providing specific
> > > > information, though I note the claim is now more restricted
> than
> > > > previously.
> > > >
> > > > Can you provide even one specific combination of crystal and
> baud
> > > > rate that doesn't work? If not, I'd ask you to please stop
> making
> > > > this claim.
> > > >
> > > > If the parts do indeed have an issue under certain
> circumstances
> > > > then it is valuable information to know exactly what the
issue
> is
> > > > and what the circumstances are when it arises. If they don't
> have
> > an
> > > > issue than repeating inaccurate information devalues the
entire
> > > > group.
> > > >
> > > > Thanks!
> > > >
> > > > Brendan
> > >
> > > Thanks to an alert by a fellow forum member, the issue has been
> > quite
> > > adequately documented here:
> > >
> > > http://www.cse.unsw.edu.au/~jayas/esdk/lpc2/limitations.html
> > >
> > > This was written some time ago and nothing has changed in
respect
> of
> > > my findings reported.
> > >
> > > I say "alert" in my opening remark because my filter now seems
to
> > > working reasonably well in weeding out Brendan's posts :)
> > >
> > > Jaya
> > >
> Start a New Thread

--- In l..., Mukund Deshmukh
wrote:
> My question are,
>
> 1. What about baud rate between 4800 -230400?
>
> 2. You also said that it works at 230400 and above
>
> 3. What happen if the serial port is PC and not FTDI chip?
>
> Finally,
>
> Should we conclude that problem is below 4800 AND with FTDI chip
AND for
> LPC2292?
>
> Best Regards,
>
> Mukund Deshmukh.

Mukund,

I'm afraid you're wasting your time - I'd be amazed if you get a
straight answer.

Jaya's claim (and I quote: "When UART is polled and receive channel
is saturated, incoming characters are lost when operating at low but
not high baud rates."), is demonstrably not true. The UARTs work
perfectly well when a stream of data is received with no gaps.

My own view is he has observed a system behaving in a particular
way. The condition he mentions (no gaps in data) may be necessary to
demonstrate this behavior, but it is clearly not sufficient. If it
were, anyone else could reproduce it, given the same conditions. My
guess is that John Heenan is on the right track: that the culprit is
more likely to be the USB-UART IC, or the software it relies on
(Windows drivers etc.).

Unless and until Jaya can provide more complete information
regarding the data being fed into the LPC2xxx when it fails (i.e.
what's happening at the UART interface, thus removing external
causes as much as possible), the claim that there is some
undocumented flaw in the LPC2xxx UART cannot be substantiated.

Of course, it doesn't help if Jaya's idea of an informed debate is
to ignore and/or insult anyone who questions his analysis.

Brendan. Start a New Thread

--- In l..., Mukund Deshmukh wrote:
> Dear Jaya,
>
> This is from your web site.
>
> //
> More specifically, on LPC2292 with 14.7456 MHz crystal, both PLL and MAM
> disabled, VPBDIV set to 1, UART set to 8-data 1-stop and no parity,
it works
> at 230400 baud and above, but drops characters at 4800 baud and below.
>
> The problem manifests itself only when the UART is connected to
devices (for
> example FTDI chip) that can send data at full speed without any delays
> between characters at specific baud rates.
> //

Thanks Mukund for introducing sanity.

> My question are,

They are good questions.

>
> 1. What about baud rate between 4800 -230400?

I did not formally test for all baud rates. Client requirement was to
check out at 230400, 4800, 2400 1200 and 300.

The frequency at which you lose characters appears to increases as
baud rate is decreased. I prefer to confine myself with deterministic
testing because they are easier to defend. Thus I picked 230400 which
has never failed, and 4800 that always failed.

The transcripts for these two baud rates follow the paragraphs you quoted.

The experimental setup is still with me. Anyone can commission a
test. I do not release such reports to open forums but I rarely
restrict the owners of such reports from doing so.

As stated in my report the "transcripts were for obtained from
downloading a 900-byte test program using SILL through NITE".

Contrary to a dubious claims I read in this forum, NITE does support
XON/XOFF protocol.

> 2. You also said that it works at 230400 and above

NITE is used on many platforms and it works by default at 230400 baud.
Noone using NITE at this speed has reported this a problem at 230400
baud.

I know of one group that uses it at 250000 baud. I have personally
tested it on LPC (till we migrated to OKI) at 931600 baud using SILL
as the boot loader as the one supplied by Philips will not work above
230400 baud on this board.

> 3. What happen if the serial port is PC and not FTDI chip?

Default or standard drivers for native serial port on PC can go up to
192000 baud max. Even at this speed, if you look at the EIA data
stream you may be able to catch extraneous gaps at frequent intervals
that is attributed to driver delays.

When and where this happens depends on the PC hardware, BIOS firmware,
operating system, and what was loaded and/or running in memory at the
time of the experiment.

I have had reports it does show up with native PC ports, but nothing
significant enough for me to set aside time to look into it.

>
> Finally,
>
> Should we conclude that problem is below 4800 AND with FTDI chip AND for
> LPC2292?

No. There is nothing in the findings that suggest the problem is
related to FTDI as we have seen the same when it is driven by tester
using CPLD to generate EIA frames.

Only Philips/NXP can say what variants this problem is limited to.
Certainly not just LPC 2292 -- as if you look further down in the
report, I explain how the same die is used for a number of parts by
simply using their boot loader to write magic numbers in hidden registers.

The original problem was reported on LPC2105. By the time I got to
looking into it formally, I had only an LPC2292 with FT232BM chip on
board to play with.

It is worth nothing that is very easy for non specific testing to miss
this problem altogether as the behaviour at 299 baud and 301 baud is
very different to that at 300 baud.

I suspect the underlying cause is a 'beating' or 'aliasing' issue
between UART and processor clocking that gives rise to one or more
race conditions.

One needs to look at the design and interface of the UART itself for
the culprit. Having gone down this path before I know for a fact the
kind of problems that can occur even in the so called 'industry
standard cells' for UARTs.

>
> Best Regards,
>
> Mukund Deshmukh.
> Beta Computronics Pvt Ltd
> 10/1, IT Park, Parsodi,
> Nagpur-440022
> Cell - 9422113746

I trust you do not mind if I add a FAQ section with questions like
yours and the answers to my original article ... I may do this when I
get the time.

Kind regards,

Jaya

PS: Although I do not work with LPCs anymore, I am still like this
forum for the useful information that is posted by various people from
time to time and have a reasonably good filter at my end. Start a New Thread

--- In l..., "John Heenan" wrote:
>
> This is with regard to the claim of Jaya that the LPC UART is faulty.
>
> Jaya is a university staff member in New South Wales Australia who
> gets paid from public tax payers money.

I wish :) As a matter of fact I do not get paid by the UNSW. One the
other hand I pay more tax than I wish I had to!

> As such he has an automatic
> standing and so we should expect certain standards.

Yes and I believe I do live up to this expectation.

> Also Jaya
> deliberately conducts himself in a style that attempts to portray an
> image that he is a credible expert.

I do not do this deliberately. Please accept this as my personal
apology to you John Heenan if I did and this offended you. It is
probably because I am frequently called in as an independent expert on
various matters relating to computer systems.

HOWEVER, my dear John Heenan, this thread is NOT about the life and
career of Jayasooriah.

Stop stooping low this extent each time you want to use this forum as
a soap box to post long stories. You use this ONE excuse to make
THREE posts. Sheesh!

> However Jaya has not helped
> Brendan reconcile differences in results and Jaya has failed to
> provide complete information.

I cannot not see one good reason why I should. On the other hand I
can think of many why I should not.

I am sorry I appear not do not take every remark someone makes in this
forum seriously and respond with intricate details. I have work to do.

> Please note I am not making a claim that Jaya's results are not true.

Thank you very much. This is a good note on which I like to get off
this (your) thread.

Kind regards,

Jaya Start a New Thread

Hey! Could you stop this in public? When people subscribe here they expect
learn and share about LPC2000, not read about unresolved love stories. Go
private, please.

Citando jayasooriah :

> --- In l..., "John Heenan" wrote:
> >
> > This is with regard to the claim of Jaya that the LPC UART is faulty.
> >
> > Jaya is a university staff member in New South Wales Australia who
> > gets paid from public tax payers money.
>
> I wish :) As a matter of fact I do not get paid by the UNSW. One the
> other hand I pay more tax than I wish I had to!
>
> > As such he has an automatic
> > standing and so we should expect certain standards.
>
> Yes and I believe I do live up to this expectation.
>
> > Also Jaya
> > deliberately conducts himself in a style that attempts to portray an
> > image that he is a credible expert.
>
> I do not do this deliberately. Please accept this as my personal
> apology to you John Heenan if I did and this offended you. It is
> probably because I am frequently called in as an independent expert on
> various matters relating to computer systems.
>
> HOWEVER, my dear John Heenan, this thread is NOT about the life and
> career of Jayasooriah.
>
> Stop stooping low this extent each time you want to use this forum as
> a soap box to post long stories. You use this ONE excuse to make
> THREE posts. Sheesh!
>
> > However Jaya has not helped
> > Brendan reconcile differences in results and Jaya has failed to
> > provide complete information.
>
> I cannot not see one good reason why I should. On the other hand I
> can think of many why I should not.
>
> I am sorry I appear not do not take every remark someone makes in this
> forum seriously and respond with intricate details. I have work to do.
>
> > Please note I am not making a claim that Jaya's results are not true.
>
> Thank you very much. This is a good note on which I like to get off
> this (your) thread.
>
> Kind regards,
>
> Jaya
>
> Start a New Thread

--- In l..., wagner@... wrote:
> Hey! Could you stop this in public?

Heck, this is nothing! Wait until some unsuspecting newbie asks about
CRP!

You just have to sit back and relax, smoke 'em if you have 'em.

Richard Start a New Thread

--- In l..., "jayasooriah"
wrote:
>
> --- In l..., Mukund Deshmukh
wrote:
> > 3. What happen if the serial port is PC and not FTDI chip?
>
> Default or standard drivers for native serial port on PC can go up
to
> 192000 baud max. Even at this speed, if you look at the EIA data
> stream you may be able to catch extraneous gaps at frequent
intervals
> that is attributed to driver delays.
>
> When and where this happens depends on the PC hardware, BIOS
firmware,
> operating system, and what was loaded and/or running in memory at
the
> time of the experiment.
>
> I have had reports it does show up with native PC ports, but
nothing
> significant enough for me to set aside time to look into it.
>

A simple "no, I haven't seen the problem without the FTDI" would
have sufficed in answering this, the most important, question.

Brendan Start a New Thread

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

> Heck, this is nothing! Wait until some unsuspecting newbie asks about
> CRP!

Now that you asked about CRP, let me tell you how it all started ...

Nah ... just kidding!

Jaya Start a New Thread

----- Original Message -----
From: "Brendan Murphy"
To:
Sent: Sunday, September 24, 2006 10:23 AM
Subject: [lpc2000] Re: no serial port on my PC
> --- In l..., "jayasooriah"
> wrote:
>>
>> --- In l..., Mukund Deshmukh
> wrote:
>> > 3. What happen if the serial port is PC and not FTDI chip?
>>
>> Default or standard drivers for native serial port on PC can go up
> to
>> 192000 baud max. Even at this speed, if you look at the EIA data
>> stream you may be able to catch extraneous gaps at frequent
> intervals
>> that is attributed to driver delays.
>>
>> When and where this happens depends on the PC hardware, BIOS
> firmware,
>> operating system, and what was loaded and/or running in memory at
> the
>> time of the experiment.
>>
>> I have had reports it does show up with native PC ports, but
> nothing
>> significant enough for me to set aside time to look into it.
>> A simple "no, I haven't seen the problem without the FTDI" would
> have sufficed in answering this, the most important, question.

Brendan and Jaya,

Please stop this bickering, otherwise I'll put both of you on moderated
status!

Leon Start a New Thread