Yahoo Groups archive

Lpc2000

Index last updated: 2026-04-28 23:31 UTC

Thread

port timing

port timing

2005-04-10 by Gennady Palitsky

Maybe someone can help me to clarify the question with GPIO timing.

My intention is to move some data from flash to port0 on LPC2138 as fast as 
possible.

I tried few ways using Keil compiler and MCB2130 board.

1. LDR   R0, =flash_array       ;set flash array pointer
    LDR   R1,=0xE0028000    ;port0 PIN address (to set 0s and 1s 
simultaneously)

   LDR    R2,[R0],#4              ;load flash word to R2
   STR    R2,[R1]                   ;send R2 to port0

   LDR    R2,[R0],#4              ;next word
   STR    R2,[R1]                   ;
....... more words sent

according to the Keil simulator (and ARM7-TDMI-S timing description from the 
manual)
loading from flash to register takes 2 cycles, storing at the port address - 
3 cycles

Scoping port shows 10 cycles.

2. Doing the same loading data from RAM array gives the same results - 10 
cycles (should be 5 according to simulator and manual).

3. Preloading data to registers and moving to port:

    LDR   R0, =flash_array       ;set flash array pointer
    LDR   R1,=0xE0028000    ;port0 PIN address

    LDR   R2,[R0],#4
    LDR   R3,[R0],#4
    LDR   R4,[R0],#4
    .....

    STR   R2,[R1]
    STR   R3,[R1]
    STR   R4,[R1]
   ...
according to simulator and manual - 2 cycles.
scope - 7 cycles.
=================================
As far as I understand, storing data at the port address adds 5 misterious 
cycles with any method, loading data timing is accurate.
I tried different settings, it seems that only one affecting timing is VPB 
clock setting - above timing is for PCLK = CCLK.

P.S. I am using in-line assembly (one for all array move), because I can't 
get assembly function to work with Keil, but I don't think it matters.

Any idea where do these cycles come from?

Thank you,
Gennady

Re: [lpc2000] port timing

2005-04-10 by Robert Adsett

At 12:36 PM 4/10/05 -0400, Gennady Palitsky wrote:

>Maybe someone can help me to clarify the question with GPIO timing.
>
>My intention is to move some data from flash to port0 on LPC2138 as fast as
>possible.

There have been multiple threads on this starting with "Simple test program 
- is now instruction pipeline/VPB question" back in Nov of 2003.  An 
explanation from Philips appeared in the thread "I/O Speed - An 
Explanation" about a year later. Look up the actual message for the full 
explanation but quoting from it

"The I/O speed has a maximum at ~3.7 Mhz because of several reasons,  .......

It is caused by interactions between the
ARM pipeline, the VPB bus, the ARM AHB wrapper (interface between the
ARM7TDMI-S core and the AHB bus), and the instruction timing itself. "

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,   be 
they legal, genetic, or physical.  If you don't believe me, try to chew a 
radio signal. "  -- Kelvin Throop, III
http://www.aeolusdevelopment.com/

Re: [lpc2000] port timing

2005-04-10 by Gennady Palitsky

Thanks a lot for the reference.
Too bad it's not documented anywhere in Philips' papers.

So it seems that the BEST result I can get with loading consecutive data 
from flash and storing at a port is 10 cycles...
(what with my 14.318MHz clock is ~230nS, actually a bit more then 3.7MHz).

Is there ANY way aroung it? Since I need a byte every oscillator cycle (3 
cpu cycles), the only way I see is to output 4 bytes at a time to pld and 
multiplex it 4 times - every oscillator cycle.

Any ideas?

BTW, is there any group archive anyhere?

Gennady


----- Original Message ----- 
Show quoted textHide quoted text
From: "Robert Adsett" <subscriptions@...>
To: <lpc2000@yahoogroups.com>
Sent: Sunday, April 10, 2005 1:09 PM
Subject: Re: [lpc2000] port timing


>
> At 12:36 PM 4/10/05 -0400, Gennady Palitsky wrote:
>
>>Maybe someone can help me to clarify the question with GPIO timing.
>>
>>My intention is to move some data from flash to port0 on LPC2138 as fast 
>>as
>>possible.
>
> There have been multiple threads on this starting with "Simple test 
> program
> - is now instruction pipeline/VPB question" back in Nov of 2003.  An
> explanation from Philips appeared in the thread "I/O Speed - An
> Explanation" about a year later. Look up the actual message for the full
> explanation but quoting from it
>
> "The I/O speed has a maximum at ~3.7 Mhz because of several reasons, 
> .......
>
> It is caused by interactions between the
> ARM pipeline, the VPB bus, the ARM AHB wrapper (interface between the
> ARM7TDMI-S core and the AHB bus), and the instruction timing itself. "
>
> Robert
>
> " 'Freedom' has no meaning of itself.  There are always restrictions,   be
> they legal, genetic, or physical.  If you don't believe me, try to chew a
> radio signal. "  -- Kelvin Throop, III
> http://www.aeolusdevelopment.com/
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
>

Re: port timing

2005-04-10 by leon_heller

--- In lpc2000@yahoogroups.com, "Gennady Palitsky" <gennadyp@j...> 
wrote:
> Thanks a lot for the reference.
> Too bad it's not documented anywhere in Philips' papers.
> 
> So it seems that the BEST result I can get with loading consecutive 
data 
> from flash and storing at a port is 10 cycles...
> (what with my 14.318MHz clock is ~230nS, actually a bit more then 
3.7MHz).
> 
> Is there ANY way aroung it? Since I need a byte every oscillator 
cycle (3 
> cpu cycles), the only way I see is to output 4 bytes at a time to 
pld and 
> multiplex it 4 times - every oscillator cycle.
> 
> Any ideas?
> 
> BTW, is there any group archive anyhere?

The group is archived here. The search facility isn't very good, you 
have to step through lots of pages.

Leon

Re: port timing

2005-04-10 by embeddedjanitor

--- In lpc2000@yahoogroups.com, "Gennady Palitsky" <gennadyp@j...> 
wrote:
> Thanks a lot for the reference.
> Too bad it's not documented anywhere in Philips' papers.

I once asked Philps for a spec and they weasled out of it saying that 
there were too many variables. 
There are a few, including clock speed, MAM settings, VPB speed etc.
The main problem is die to the way Philips attached the core to the 
GPIO. If they'd one it on the "fast bus" instead of the VPB things 
would be a lot faster.

The Atmel SAM7 parts have much faster GPIOs but still not anyhere near 
single cycle.I prefer working with Philips than Atmel, but this one 
point was enough to make me choose an Atmel SAM7 part.

> 
> So it seems that the BEST result I can get with loading consecutive 
data 
> from flash and storing at a port is 10 cycles...
> (what with my 14.318MHz clock is ~230nS, actually a bit more then 3.
7MHz).

That's about right.

> 
> Is there ANY way aroung it? Since I need a byte every oscillator 
cycle (3 
> cpu cycles), the only way I see is to output 4 bytes at a time to 
pld and 
> multiplex it 4 times - every oscillator cycle.
> 
> Any ideas?
> 
The only way to get the data out fast with a Philps LPC21xx device is 
going to be using some sort of mechanism on the external memory bus.

Re: [lpc2000] Re: port timing

2005-04-10 by Marko Pavlin (home)

>
> >
> > BTW, is there any group archive anyhere?
>

Here's a message:
http://groups.yahoo.com/group/lpc2000/message/4000

You are right, max. toggle is 3.7MHz.

Marko

[lpc2000] Re: port timing

2005-04-10 by Gennady Palitsky

----- Original Message ----- 
Show quoted textHide quoted text
From: "embeddedjanitor" <manningc2@...>
To: <lpc2000@yahoogroups.com>
Sent: Sunday, April 10, 2005 3:12 PM
Subject: [lpc2000] Re: port timing


>
>
> --- In lpc2000@yahoogroups.com, "Gennady Palitsky" <gennadyp@j...>
> wrote:
>> Thanks a lot for the reference.
>> Too bad it's not documented anywhere in Philips' papers.
>
> I once asked Philps for a spec and they weasled out of it saying that
> there were too many variables.
> There are a few, including clock speed, MAM settings, VPB speed etc.
> The main problem is die to the way Philips attached the core to the
> GPIO. If they'd one it on the "fast bus" instead of the VPB things
> would be a lot faster.
>
> The Atmel SAM7 parts have much faster GPIOs but still not anyhere near
> single cycle.I prefer working with Philips than Atmel, but this one
> point was enough to make me choose an Atmel SAM7 part.
>

Unfortunately Atmel doesn't have IAP (the application engineer I spoke with 
sais they have it but don't advertise because it's not completed yet), and 
this is a requirement.


>>
>> So it seems that the BEST result I can get with loading consecutive
> data
>> from flash and storing at a port is 10 cycles...
>> (what with my 14.318MHz clock is ~230nS, actually a bit more then 3.
> 7MHz).
>
> That's about right.
>

BTW, when I use storing to port from registers (I can't use because of 
amount of data), I can get 7 cycles (scoped), what is above 6 Mhz for GPIO. 
Definitely above 3.7MHz... Why?


> The only way to get the data out fast with a Philps LPC21xx device is
> going to be using some sort of mechanism on the external memory bus.
>

Is external memory access faster then direct storing to GPIO?

Re: [lpc2000] Re: port timing

2005-04-10 by Gennady Palitsky

----- Original Message ----- 
Show quoted textHide quoted text
From: "embeddedjanitor" <manningc2@...>
To: <lpc2000@yahoogroups.com>
Sent: Sunday, April 10, 2005 3:12 PM
Subject: [lpc2000] Re: port timing


> --- In lpc2000@yahoogroups.com, "Gennady Palitsky" <gennadyp@j...>
> wrote:
>> So it seems that the BEST result I can get with loading consecutive
> data
>> from flash and storing at a port is 10 cycles...
>> (what with my 14.318MHz clock is ~230nS, actually a bit more then 3.
> 7MHz).
>
> That's about right.
>

I put on a board 17.73MHz crystal and with direct store from registers to 
GPIO got port toggle frequency
of ~7.6MHz. I believe that 20MHz crystal (don't have one) will give ~8.6MHz 
toggle.
Though extra 5 cycles at STR is still there, the port frequency is way above 
originally mentioned 3.7MHz.
Does it mean that something changed on LPC2138 ?

Gennady

Re: [lpc2000] Re: port timing

2005-04-11 by Peter Jakacki

Update frequency is not the same as output frequency when toggling. If 
you turn the outputs on and off at an update rate of 7.4MHz you will end 
up with a output frequency of 3.7MHz.

I run my 2106 at 22.1184MHz (overclocked) x3 and achieve an update 
frequency of ~8.3MHz or update period of 120ns on the GPIO pins. This is 
reading from RAM and writing shifted data. Toggling the pins would only 
give me a ~4.15MHz signal.

Philips might wonder how important is I/O speed really, what's all the 
gripe about. I'd say it isn't important, -except- for embedded real-time 
control. Now which market did Philips intend these chips for?

With the 2106 I generate 192x480x8 VGA graphics over 640x480 60Hz timing 
without any extra hardware other than some resistors. I really wish 
Philips would listen and improve the GPIO interface, how hard can it 
really be??? Surely it would have to be THE simplest fix.

*Peter*

Gennady Palitsky wrote:
Show quoted textHide quoted text
>I put on a board 17.73MHz crystal and with direct store from registers to 
>GPIO got port toggle frequency
>of ~7.6MHz. I believe that 20MHz crystal (don't have one) will give ~8.6MHz 
>toggle.
>Though extra 5 cycles at STR is still there, the port frequency is way above 
>originally mentioned 3.7MHz.
>Does it mean that something changed on LPC2138 ?
>
>

Re: [lpc2000] Re: port timing

2005-04-11 by Gennady Palitsky

----- Original Message ----- 
Show quoted textHide quoted text
From: "Peter Jakacki" <peterjak@...>
To: <lpc2000@yahoogroups.com>
Sent: Sunday, April 10, 2005 9:49 PM
Subject: Re: [lpc2000] Re: port timing


>
> Update frequency is not the same as output frequency when toggling. If
> you turn the outputs on and off at an update rate of 7.4MHz you will end
> up with a output frequency of 3.7MHz.
>
> I run my 2106 at 22.1184MHz (overclocked) x3 and achieve an update
> frequency of ~8.3MHz or update period of 120ns on the GPIO pins. This is
> reading from RAM and writing shifted data. Toggling the pins would only
> give me a ~4.15MHz signal.
>
> Philips might wonder how important is I/O speed really, what's all the
> gripe about. I'd say it isn't important, -except- for embedded real-time
> control. Now which market did Philips intend these chips for?
>
> With the 2106 I generate 192x480x8 VGA graphics over 640x480 60Hz timing
> without any extra hardware other than some resistors. I really wish
> Philips would listen and improve the GPIO interface, how hard can it
> really be??? Surely it would have to be THE simplest fix.
>
> *Peter*
>

You are right, I did mean an update frequency.
Now, how can you generate video graphics with this frequency if pixel clock 
is 70nS (ntsc, and even less for pal) ?
That's about what I am trying to accomplish, and I am really lost.

Gennady

Re: [lpc2000] Re: port timing

2005-04-11 by Robert Adsett

At 11:49 AM 4/11/05 +1000, Peter Jakacki wrote:
>Philips might wonder how important is I/O speed really, what's all the
>gripe about. I'd say it isn't important, -except- for embedded real-time
>control. Now which market did Philips intend these chips for?

Well I do embedded real-time control and pin toggling speed is not of great 
importance for what I do.  Different problem areas have different 
constraints.  I would expect that in some real-time embedded environments 
that the capability to do high rate pin toggling would be seen as a reason 
for caution since high toggling rates may imply fast edge rates with all 
the implications that those have.

I don't think Philips was expecting people to do a lot of high rate 
bit-banging with these chips, but high-rate bit-banging and embedded 
real-time are two different, but not exclusive, markets.  You can have 
either one without the other.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,   be 
they legal, genetic, or physical.  If you don't believe me, try to chew a 
radio signal. "  -- Kelvin Throop, III
http://www.aeolusdevelopment.com/

Re: [lpc2000] Re: port timing

2005-04-11 by Peter Jakacki

Different strokes for different folks, and even those folks differ their 
strokes for different folk. The cpu shouldn't be constrained by 
something that really is an easy fix just because it's not an issue in 
some apps. The next app that comes along it can be a real issue, such as 
this one. I don't live in a purist world where bit-banging is something 
odious, it may be down there and dirty, but it works.

This is where little 8-bit'ers such as the ubicom and silabs parts don't 
hold back, grrrhhhh grrrhhh, lol.

*Peter*

Robert Adsett wrote:
Show quoted textHide quoted text
>Well I do embedded real-time control and pin toggling speed is not of great 
>importance for what I do.  Different problem areas have different 
>constraints.  I would expect that in some real-time embedded environments 
>that the capability to do high rate pin toggling would be seen as a reason 
>for caution since high toggling rates may imply fast edge rates with all 
>the implications that those have.
>
>I don't think Philips was expecting people to do a lot of high rate 
>bit-banging with these chips, but high-rate bit-banging and embedded 
>real-time are two different, but not exclusive, markets.  You can have 
>either one without the other.
>

Re: [lpc2000] Re: port timing

2005-04-11 by Leon Heller

----- Original Message ----- 
Show quoted textHide quoted text
From: "Peter Jakacki" <peterjak@...>
To: <lpc2000@yahoogroups.com>
Sent: Monday, April 11, 2005 2:49 AM
Subject: Re: [lpc2000] Re: port timing


> 
> Update frequency is not the same as output frequency when toggling. If 
> you turn the outputs on and off at an update rate of 7.4MHz you will end 
> up with a output frequency of 3.7MHz.
> 
> I run my 2106 at 22.1184MHz (overclocked) x3 and achieve an update 
> frequency of ~8.3MHz or update period of 120ns on the GPIO pins. This is 
> reading from RAM and writing shifted data. Toggling the pins would only 
> give me a ~4.15MHz signal.
> 
> Philips might wonder how important is I/O speed really, what's all the 
> gripe about. I'd say it isn't important, -except- for embedded real-time 
> control. Now which market did Philips intend these chips for?
> 
> With the 2106 I generate 192x480x8 VGA graphics over 640x480 60Hz timing 
> without any extra hardware other than some resistors. I really wish 
> Philips would listen and improve the GPIO interface, how hard can it 
> really be??? Surely it would have to be THE simplest fix.

It's inherent in the ARM architecture, nothing to do with Philips.

Leon

Re: [lpc2000] Re: port timing

2005-04-11 by Peter Jakacki

I am quite aware of the cell nature of the beast. Butting cells together 
is fine for predesigned and certified functions. The current cell design 
for the ARM core has worked for it's traditional uses but simply needs a 
little refinement for the newer uses as indicated by 'everything 
on-chip' non-expandable nature of many of the newer ARMs.

To say that it is nothing to do with Philips really portrays them as 
follow the numbers mechano set builders, which they definitely are not.

I am not lambasting Philips or ARM or anyone on this matter especially 
as this is Philips foray into the embedded ARM market for which I 
sincerely applaud it. But if Philips came out with a new ARM that still 
lacked fast I/O (what is this, I am asking for Ethernet or another hard 
ask), I would be very disappointed.

BTW, I appreciate your comments and those of others, I frequently lurk 
on this list but rarely have much time to participate :(

*Peter*

Leon Heller wrote:
Show quoted textHide quoted text
>It's inherent in the ARM architecture, nothing to do with Philips.
>  
>

Re: port timing

2005-04-11 by philips_apps

Hi community,

Yes we are listening and yes we are working to make the ports as fast
as possible.

Give us another 6-8 weeks and you can get samples of such a device.

We are a so called "learning company" :-), you tell us what you need
and we try to integrate what is possible.

So, please bear with us, Robert

Re: [lpc2000] Re: port timing

2005-04-11 by Peter Jakacki

:) :) :) :) :) :) :) :) :) :) :) :) :) :)

philips_apps wrote:
Show quoted textHide quoted text
>Hi community,
>
>Yes we are listening and yes we are working to make the ports as fast
>as possible.
>
>Give us another 6-8 weeks and you can get samples of such a device.
>
>We are a so called "learning company" :-), you tell us what you need
>and we try to integrate what is possible.
>
>So, please bear with us, Robert
>  
>

Re: [lpc2000] Re: port timing

2005-04-11 by Gennady Palitsky

----- Original Message ----- 
Show quoted textHide quoted text
From: "embeddedjanitor" <manningc2@...>
To: <lpc2000@yahoogroups.com>
Sent: Sunday, April 10, 2005 3:12 PM
Subject: [lpc2000] Re: port timing


>
>
> --- In lpc2000@yahoogroups.com, "Gennady Palitsky" <gennadyp@j...>
> wrote:
>> Is there ANY way aroung it? Since I need a byte every oscillator
> cycle (3
>> cpu cycles), the only way I see is to output 4 bytes at a time to
> pld and
>> multiplex it 4 times - every oscillator cycle.
>>
>> Any ideas?
>>
> The only way to get the data out fast with a Philps LPC21xx device is
> going to be using some sort of mechanism on the external memory bus.
>

Following documented and known  undocumented - what would  be the maximum 
update frequency  for the external memory bus ?

Who thinks the PC Compatible UARTs on the LPC are nice ?

2005-04-12 by Anton Erasmus

Hi,

Since some of Philips's people seem to be reading this group. How many people
think they should change the crappy PC compatible UARTs to something else ?
UARTS that can generate interrupt when the last bit has been transmitted to 
make it easier to switch a RS-485 buffer for example. A proper 9 bit mode.
The possibility to read how many characters are in the Rx or Tx FIFO ? etc.


Regards
  Anton Erasmus


-- 
A J Erasmus

Re: Who thinks the PC Compatible UARTs on the LPC are nice ?

2005-04-12 by Ken Wada

I would've preferred the 28LC92 UART instead. In fact, this part is an 
original Philips architecture, based on the very fine SCC2692 I 
believe!

Ken Wada

--- In lpc2000@yahoogroups.com, "Anton Erasmus" <antone@s...> wrote:
> Hi,
> 
> Since some of Philips's people seem to be reading this group. How 
many people
> think they should change the crappy PC compatible UARTs to something 
else ?
> UARTS that can generate interrupt when the last bit has been 
transmitted to 
> make it easier to switch a RS-485 buffer for example. A proper 9 bit 
mode.
> The possibility to read how many characters are in the Rx or Tx FIFO 
? etc.
Show quoted textHide quoted text
> 
> 
> Regards
>   Anton Erasmus
> 
> 
> -- 
> A J Erasmus

Re: [lpc2000] Who thinks the PC Compatible UARTs on the LPC are nice ?

2005-04-13 by Robert Adsett

At 07:31 PM 4/12/05 +0200, Anton Erasmus wrote:
>Since some of Philips's people seem to be reading this group. How many people
>think they should change the crappy PC compatible UARTs to something else ?
>UARTS that can generate interrupt when the last bit has been transmitted to
>make it easier to switch a RS-485 buffer for example. A proper 9 bit mode.
>The possibility to read how many characters are in the Rx or Tx FIFO ? etc.

I can see the utility of a proper 9 bit mode with an interrupt after last 
transmitted bit available.  On the FIFO side though the addition of a flag 
to indicate that the transmit FIFO was full along with an interrupt to 
indicate when it was say 1/2 full would be enough to keep the transmit 
buffer full under just about all conditions.  The receive side seems quite 
sufficient to me.

Another item that might be useful would be some LIN specific support, 
mostly more break detection support.

Robert


" 'Freedom' has no meaning of itself.  There are always restrictions,   be 
they legal, genetic, or physical.  If you don't believe me, try to chew a 
radio signal. "  -- Kelvin Throop, III
http://www.aeolusdevelopment.com/

Re: Who thinks the PC Compatible UARTs on the LPC are nice ?

2005-04-13 by tonalbuilder2002

> I can see the utility of a proper 9 bit mode with an interrupt
after 
last 
> transmitted bit available. 


Some of Exar's latest UART's are quite nice and feature options such
as 9 bit protocol, automatic RS485 direction switching, etc.  Face it,
the 16c550 format is a relic, I would gladly swap these for 9 bit 
UART's, even if unbuffered.  For now I'm happily using Freescale 
MC9S12E's in communications applications, it has three nice 9 bit 
UART's.

Of course you can force 9 bit protocol on a 16c55x by reprogramming 
the parity bit for each character, but it's a lot of work and you 
can't use the buffer.

Here's the Exar UART matrix...

http://www.exar.com/search_uart.php

Bill T.
http://www.kupercontrols.com

Re: [lpc2000] Re: port timing

2005-04-13 by 42Bastian Schick

Gennady Palitsky
>
> Is external memory access faster then direct storing to GPIO?

I doubt this, since it uses the same paths on the chip.

But, do you write to IOPIN or do it by way of IOSET/IOCLR ?


-- 
42Bastian Schick

Re: [lpc2000] port timing

2005-04-13 by Gennady Palitsky

----- Original Message ----- 
Show quoted textHide quoted text
From: "42Bastian Schick" <bastian42@...>
To: <lpc2000@yahoogroups.com>
Sent: Wednesday, April 13, 2005 2:45 AM
Subject: Re: [lpc2000] Re: port timing


>
> Gennady Palitsky
>>
>> Is external memory access faster then direct storing to GPIO?
>
> I doubt this, since it uses the same paths on the chip.
>
> But, do you write to IOPIN or do it by way of IOSET/IOCLR ?
>

I write to IOPIN, since I need simultaneous update. It doesn't make any 
difference in timing, right?

Gennady

Re: [lpc2000] port timing

2005-04-13 by 42Bastian Schick

Gennady

> I write to IOPIN, since I need simultaneous update. It doesn't make any
> difference in timing, right?
It does (according to the docs). Direct write to IOPIN is the fastest.

-- 
42Bastian Schick

Re: [lpc2000] port timing

2005-04-13 by Gennady Palitsky

----- Original Message ----- 
Show quoted textHide quoted text
From: "42Bastian Schick" <bastian42@...>
To: <lpc2000@yahoogroups.com>
Sent: Wednesday, April 13, 2005 7:59 AM
Subject: Re: [lpc2000] port timing


>
> Gennady
>
>> I write to IOPIN, since I need simultaneous update. It doesn't make any
>> difference in timing, right?
> It does (according to the docs). Direct write to IOPIN is the fastest.
>

But it's only because it's one access to the port instead of two consecutive 
accesses to set and clear pins, right?
Otherwise I believe it's the same STR data,[PORT_REGISTER] instruction. Or 
do I miss something?

Gennady

Re: Who thinks the PC Compatible UARTs on the LPC are nice ?

2005-04-14 by lp2000c

--- In lpc2000@yahoogroups.com, "Anton Erasmus" <antone@s...> wrote:
> Hi,
> 
> Since some of Philips's people seem to be reading this group. How 
many people
> think they should change the crappy PC compatible UARTs to 
something else ?
> UARTS that can generate interrupt when the last bit has been 
transmitted to 
> make it easier to switch a RS-485 buffer for example. A proper 9 
bit mode.
> The possibility to read how many characters are in the Rx or Tx 
FIFO ? etc.
> 
> 
> Regards
>   Anton Erasmus
> 
> 
> -- 
> A J Erasmus


YES! YES! YES!

The most annoying thing is that the time when THRE interrupt occurs 
is dependent on "initialization conditions."

Second is that there is no way to tell if the transmit FIFO is full.

[lpc2000] Re: Who thinks the PC Compatible UARTs on the LPC are nice ?

2005-04-14 by Bill Knight

Am I missing something here guys (and gals)?  When the FIFO is
enabled the THRE bit in the Line Status Register is set whenever
the FIFO can accept additional characters.  So if it were clear,
isn't that an indication the FIFO is full?
As for RS-485 transceiver turn-around; the TEMT bit also in the
Line Status Register, can be used to determine when the stop bit
of the last character has been transmitted.  Can't that be used
to control the RS-485 interface?

Regards
-Bill Knight
R O SoftWare &
http://www.theARMPatch.com

Re: Who thinks the PC Compatible UARTs on the LPC are nice ?

2005-04-14 by johnthomasedwardtimm

--- In lpc2000@yahoogroups.com, "Bill Knight" <BillK@t...> wrote:
> Am I missing something here guys (and gals)?  When the FIFO is
> enabled the THRE bit in the Line Status Register is set whenever
> the FIFO can accept additional characters.  So if it were clear,
> isn't that an indication the FIFO is full?
> As for RS-485 transceiver turn-around; the TEMT bit also in the
> Line Status Register, can be used to determine when the stop bit
> of the last character has been transmitted.  Can't that be used
> to control the RS-485 interface?
> 
> Regards
> -Bill Knight
> R O SoftWare &
> http://www.theARMPatch.com

I second that motion.  I am using the THRE bit in the LSR to
determine 
whether the transmit FIFO is full and it works fine.

JT

Re: [lpc2000] Re: Who thinks the PC Compatible UARTs on the LPC are nice ?

2005-04-14 by Richard Duits

The THRE is set when the FIFO is empty. There may still be a BYTE in the 
transmit
shift register, but to keep the flow going you have to respond in less 
than 1 byte transmit
time to the THRE interrupt. If you don't there is nothing lost, the 
transmission just takes
a bit longer.

Regards,
Richard.


Bill Knight wrote:
Show quoted textHide quoted text
> Am I missing something here guys (and gals)?  When the FIFO is
> enabled the THRE bit in the Line Status Register is set whenever
> the FIFO can accept additional characters.  So if it were clear,
> isn't that an indication the FIFO is full?
> As for RS-485 transceiver turn-around; the TEMT bit also in the
> Line Status Register, can be used to determine when the stop bit
> of the last character has been transmitted.  Can't that be used
> to control the RS-485 interface?
>
> Regards
> -Bill Knight
> R O SoftWare &
> http://www.theARMPatch.com
>
>
>
>
> ------------------------------------------------------------------------
> *Yahoo! Groups Links*
>
>     * To visit your group on the web, go to:
>       http://groups.yahoo.com/group/lpc2000/
>        
>     * To unsubscribe from this group, send an email to:
>       lpc2000-unsubscribe@yahoogroups.com
>       <mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>        
>     * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>       Service <http://docs.yahoo.com/info/terms/>.
>
>

Re: Who thinks the PC Compatible UARTs on the LPC are nice ?

2005-04-14 by Ken Wada

Indeed!
You need...actually it is a very good idea to use the TEMT bit to 
toggle the transmit enable bit on your RS-485 interface.

For me, it would have been nice to have the TEMT bit generate an 
interrupt. My code would have been a little bit more efficient in this 
way.

As it stands, I now look for a signal that the interrupt service 
routine has processed the last byte out, (THRE interrupt, and no more 
bytes in tx queue). After this, I poll the TEMT bit. This lets me know 
that I will not 'clobber' that last byte out before disabling the 
transmitter on my RS-485 transceiver.

Ken Wada

--- In lpc2000@yahoogroups.com, "Bill Knight" <BillK@t...> wrote:
Show quoted textHide quoted text
> Am I missing something here guys (and gals)?  When the FIFO is
> enabled the THRE bit in the Line Status Register is set whenever
> the FIFO can accept additional characters.  So if it were clear,
> isn't that an indication the FIFO is full?
> As for RS-485 transceiver turn-around; the TEMT bit also in the
> Line Status Register, can be used to determine when the stop bit
> of the last character has been transmitted.  Can't that be used
> to control the RS-485 interface?
> 
> Regards
> -Bill Knight
> R O SoftWare &
> http://www.theARMPatch.com

Re: Who thinks the PC Compatible UARTs on the LPC are nice ?

2005-04-14 by Ken Wada

> Second is that there is no way to tell if the transmit FIFO is full.

Heh...

you need to ASSUME, that when THRE gets generated, that you can stuff 
up to 16-bytes into that FIFO.

Actually, my experience has shown that this is a pretty good 
assumption.

Unfortunately, if you work under non-interrupt mode, this means you 
need to wait for the queue to completely drain before you can feel 
'safe' in stuffing more bytes into the queue....

not the most efficient means to go in non-interrupt mode.

Ken Wada

Re: [lpc2000] Re: Who thinks the PC Compatible UARTs on the LPC are nice ?

2005-04-14 by Robert Adsett

At 09:41 AM 4/14/05 -0500, Bill Knight wrote:
>Am I missing something here guys (and gals)?  When the FIFO is
>enabled the THRE bit in the Line Status Register is set whenever
>the FIFO can accept additional characters.  So if it were clear,
>isn't that an indication the FIFO is full?

No, the THRE bit is cleared when something is ready to transmit, it is only 
set when the FIFO is empty.  The only way to fill the FIFO is to count how 
many bytes you put in.  I don't find that a big problem but it would be 
more efficient to be able to tell when the FIFO was full.

I'll leave the End of transmission question to others who have had to deal 
with it.  That still leaves the 9 bit mode problems.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,   be 
they legal, genetic, or physical.  If you don't believe me, try to chew a 
radio signal. "  -- Kelvin Throop, III
http://www.aeolusdevelopment.com/

Re: [lpc2000] Re: Who thinks the PC Compatible UARTs on the LPC are nice ?

2005-04-14 by Robert Adsett

At 03:39 PM 4/14/05 +0000, johnthomasedwardtimm wrote:
>I second that motion.  I am using the THRE bit in the LSR to
>determine
>whether the transmit FIFO is full and it works fine.

Have you actually checked how may bytes you get into the FIFO in that fashion ?

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,   be 
they legal, genetic, or physical.  If you don't believe me, try to chew a 
radio signal. "  -- Kelvin Throop, III
http://www.aeolusdevelopment.com/

Re: Who thinks the PC Compatible UARTs on the LPC are nice ?

2005-04-14 by lp2000c

Yes, you are missing something.

THRE indicates when FIFO is empty - not when it is full.
Furthermore, the exact time when this occurs, depends 
on "initialization conditions".
See paragraph following Table 68 of LPC213x manual (or similar for 
other members of this family).

As far as using TEMT for RS-485 turn-around, that would be great if 
it could be used to generate an interrupt.


--- In lpc2000@yahoogroups.com, "Bill Knight" <BillK@t...> wrote:
Show quoted textHide quoted text
> Am I missing something here guys (and gals)?  When the FIFO is
> enabled the THRE bit in the Line Status Register is set whenever
> the FIFO can accept additional characters.  So if it were clear,
> isn't that an indication the FIFO is full?
> As for RS-485 transceiver turn-around; the TEMT bit also in the
> Line Status Register, can be used to determine when the stop bit
> of the last character has been transmitted.  Can't that be used
> to control the RS-485 interface?
> 
> Regards
> -Bill Knight
> R O SoftWare &
> http://www.theARMPatch.com

Re: Who thinks the PC Compatible UARTs on the LPC are nice ?

2005-04-14 by peterburdine

--- In lpc2000@yahoogroups.com, "Bill Knight" <BillK@t...> wrote:
> Am I missing something here guys (and gals)?  When the FIFO is
> enabled the THRE bit in the Line Status Register is set whenever
> the FIFO can accept additional characters.  So if it were clear,
> isn't that an indication the FIFO is full?

Nope, that isn't the case.  THRE is transmit holding register empty. 
There is the THRE register and then a 16 byte FIFO.  So in my drivers,
I just dump upto 16 bytes in the FIFO and then get an interrupt when
they are all sent.  I guess I could do 17, I'd have to try that.  But
there is no way to tell if it is full, unless you count how many you
put in and keep track of the time and baud rate and all the error that
can occur.  But I find that dumping up to 16 chars in the fifo and
they the next 16 when I get THRE.  Its a little more overhead than
just checking to see if the FIFO is full, but since you can't do that,
this works well enough.
Show quoted textHide quoted text
> As for RS-485 transceiver turn-around; the TEMT bit also in the
> Line Status Register, can be used to determine when the stop bit
> of the last character has been transmitted.  Can't that be used
> to control the RS-485 interface?
> 
> Regards
> -Bill Knight
> R O SoftWare &
> http://www.theARMPatch.com

Re: [lpc2000] Re: Who thinks the PC Compatible UARTs on the LPC are nice ?

2005-04-14 by Bill Knight

Yep, I just checked some old docs on the 16550 and sure enough, THRE
is only set when the FIFO is empty - DUMB.  And yep, it sure doesn't
appear TEMT can be used to cause an interrupt - also DUMB.  OK, I'm
ready for a new, improved UART.

One small feature I would like is to have an interrupt generated as
the THRE interrupt is enabled, if the THRE bit is already set.  This
allows characters to be placed into an ouput queue and the THRE
interrupt enabled as a means of both starting a transmission as well
as adding characters to a transmission in progress.  It also allows
the forground process to do it without ever disabling global
interrupts.

-Bill

On Thu, 14 Apr 2005 17:04:38 -0000, lp2000c wrote:

Yes, you are missing something.

THRE indicates when FIFO is empty - not when it is full.
Furthermore, the exact time when this occurs, depends 
on "initialization conditions".
See paragraph following Table 68 of LPC213x manual (or similar for 
other members of this family).

As far as using TEMT for RS-485 turn-around, that would be great if 
it could be used to generate an interrupt.


--- In lpc2000@yahoogroups.com, "Bill Knight" <BillK@t...> wrote:
Show quoted textHide quoted text
> Am I missing something here guys (and gals)?  When the FIFO is
> enabled the THRE bit in the Line Status Register is set whenever
> the FIFO can accept additional characters.  So if it were clear,
> isn't that an indication the FIFO is full?
> As for RS-485 transceiver turn-around; the TEMT bit also in the
> Line Status Register, can be used to determine when the stop bit
> of the last character has been transmitted.  Can't that be used
> to control the RS-485 interface?
> 
> Regards
> -Bill Knight
> R O SoftWare &
> http://www.theARMPatch.com

Re: [lpc2000] Re: Who thinks the PC Compatible UARTs on the LPC are nice ?

2005-04-14 by Robert Adsett

At 02:10 PM 4/14/05 -0500, Bill Knight wrote:
>One small feature I would like is to have an interrupt generated as
>the THRE interrupt is enabled, if the THRE bit is already set.  This
>allows characters to be placed into an ouput queue and the THRE
>interrupt enabled as a means of both starting a transmission as well
>as adding characters to a transmission in progress.  It also allows
>the forground process to do it without ever disabling global
>interrupts.

While we're at it, how about a pseudo-DMA process to deal with the 
I/O?  That would reduce/eliminate the need for FIFO's.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,   be 
they legal, genetic, or physical.  If you don't believe me, try to chew a 
radio signal. "  -- Kelvin Throop, III
http://www.aeolusdevelopment.com/

Re: [lpc2000] Re: port timing

2005-06-03 by Peter Jakacki

Hi Robert,  how are those chips with the faster ports going? How can I 
get samples of them and do you have any data on them in the meantime?  
itching ... itching .... itching ....

TIA
*Peter*

philips_apps wrote:
Show quoted textHide quoted text
>Hi community,
>
>Yes we are listening and yes we are working to make the ports as fast
>as possible.
>
>Give us another 6-8 weeks and you can get samples of such a device.
>
>We are a so called "learning company" :-), you tell us what you need
>and we try to integrate what is possible.
>
>So, please bear with us, Robert
>  
>

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.