Lpc2000

As soon as I write a single character to the THRE, Transmit holding
register empty flag in U1LSR is cleared. Either the FIFO is not
enabled or is set to '1', or this is the normal operation (after all,
the FIFO is not **empty**).

In the latter case how do you know if there is still space in the FIFO
to write data?

BTW, while trying to resove this problem I came accross the following
comment in the control register descriptions:

00: trigger level 0 (default='h1)
01: trigger level 1 (default='h4)
10: trigger level 2 (default='h8)
11: trigger level 3 (default='he)
These two bits determine how many receiver UART1 FIFO characters must
be written
before an interrupt is activated. The four trigger levels are defined
by the user at
compilation allowing the user to tune the trigger levels to the FIFO
depths chosen.
0



What exactly does it mean by defined at compile time? Perhaps if I
knew where these levels were configured I would find the answer to my
Tx FIFO problem ?!

hodgejackiehank wrote:

> As soon as I write a single character to the THRE, Transmit holding
> register empty flag in U1LSR is cleared. Either the FIFO is not
> enabled or is set to '1', or this is the normal operation (after all,
> the FIFO is not **empty**).
> 
> In the latter case how do you know if there is still space in the FIFO
> to write data?
> 
> BTW, while trying to resove this problem I came accross the following
> comment in the control register descriptions:
> 
> 00: trigger level 0 (default='h1)
> 01: trigger level 1 (default='h4)
> 10: trigger level 2 (default='h8)
> 11: trigger level 3 (default='he)
> These two bits determine how many receiver UART1 FIFO characters must
> be written
> before an interrupt is activated. The four trigger levels are defined
> by the user at
> compilation allowing the user to tune the trigger levels to the FIFO
> depths chosen.
> 0
> 
> 
> 
> What exactly does it mean by defined at compile time? Perhaps if I
> knew where these levels were configured I would find the answer to my
> Tx FIFO problem ?!
> 
> 
> 
> 

I also stumbled across this description. Obviously, this is a copy-and-paste 
from the description of the '550-UART IP-Core. So, 'compile time' means the time 
of the building of the chip, when all the hardware descriptions (in VHDL, 
Verilog or whatever) are translated and mapped onto the target technology and 
'user' in this case is/are the chip designer(s).
IIRC, somewhere in the user manual is explicitely said that the FIFO holds 16 
byte with possible trigger levels being 1, 4, 8 or 14.

Regards,
Jens

> I also stumbled across this description. Obviously, this is a
copy-and-paste 
> from the description of the '550-UART IP-Core. 

I thought it might be something like that. So given that the FIFO is
preconfigured, how do I know when the FIFO is full?

At 10:28 AM 7/6/04 +0000, you wrote:

> > I also stumbled across this description. Obviously, this is a
>copy-and-paste
> > from the description of the '550-UART IP-Core.
>
>I thought it might be something like that. So given that the FIFO is
>preconfigured, how do I know when the FIFO is full?

In this respect, it behaves as all '550s.  When the THRE interrupt fires 
the FIFO is empty and you can put up to 16 bytes into it.  Something like

  case RECEIVE:
     for( i = 0; i <16; i++) {
          U0THR = buf[i];
      }
      break;

Oversimplified but it illustrates the point.

AFAIR this is documented in all of a sentence or maybe two.

BTW, I would be very interested if anyone else has run into the missing 
THRE interrupt symptoms I've seen.

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

> 
> In this respect, it behaves as all '550s.  When the THRE interrupt
fires 
> the FIFO is empty and you can put up to 16 bytes into it.  Something
like
> 

I would like to be able to "top up" the FIFO when possible so that I
can have more time before the next interupt. Trouble is I am not sure
if I am intepreting the flags correctly, the THRE flag appears to be
set even if just 1 byte has been written, so it is no use for seeing
if the FIFO may be topped up.

At 12:00 PM 7/6/04 +0000, you wrote:

> >
> > In this respect, it behaves as all '550s.  When the THRE interrupt
>fires
> > the FIFO is empty and you can put up to 16 bytes into it.  Something
>like
> >
>
>I would like to be able to "top up" the FIFO when possible so that I
>can have more time before the next interupt. Trouble is I am not sure
>if I am intepreting the flags correctly, the THRE flag appears to be
>set even if just 1 byte has been written, so it is no use for seeing
>if the FIFO may be topped up.

There is no way to know when the transmit FIFO has been partially emptied 
(well you could time how long it was since it was last filled).

The THRE flag does just that it flags when the transmitter holding register 
is empty.  That means that there was nothing in the FIFO to re-fill it.

I can see that a transmitter FIFO would be a useful additional source to 
increase the allowable interrupt response latency but there is nothing in 
the uart to give it to you.

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

At 08:10 AM 7/6/04 -0400, you wrote:
>I can see that a transmitter FIFO would be a useful additional source to
>increase the allowable interrupt response latency but there is nothing in
>the uart to give it to you.

Oops, that should be

I can see that a transmitter FIFO threshold interrupt would be ....

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

Hello all,

I am puzzled by perhaps similar thing re: missing THRE int., FIFO empty?
Can anyone plese help me to see what I do incorrectly?

Polled UART0 works, INT on THRE doesn't.
Timer0 ISR works, though.

The code (snippets below)never makes it to UART_THRE ISR.
I am re-writing INT driven buffered Tx already implemented on another
MCUs.
BTW, I am a newbie on LPC2106, no flames please.

--roger

---ivt.s----
LDR PC, [PC, #-0xFF0] 		@ load irq vector from vic
LDR PC, FIQ_Addr

-----main.c---

VICIntSelect = 0x0; 	/* ALL sources selected as IRQ */
VICIntEnable = 0x50; 	/* TIMER0 and UART0_THRE interrupts enabled */
/* Address of the ISR */
VICVectAddr0 = (unsigned long)IRQ_Timer0_Handler; 
VICVectCntl0 = 0x24;	/* IRQ for channel 4: TIMER0 : 10 0100 */ 
VICVectAddr1 = (unsigned long)IRQ_UART0_Tx_Handler;
VICVectCntl1 = 0x26;	/* IRQ for channel 6: UART_THRE: 10 0110 */
.
.
.

PINSEL0 = 0x05;      	// enable UART0 TxD/RxD
UART0_FCR = 0x07;   	// enable and reset Tx and Rx FIFO
UART0_LCR = 0x83;	// 8N1; enable divisor latches access
UART0_DLL = 0x20;  	// LSB divider for cclk/115200*16=0x20
UART0_DLM = 0x00;  	// MSB = 0
UART0_IER = 0x02;	// enable THRE interrupt
UART0_LCR = 0x03;   	// disable divisor latches

void __attribute__((interrupt)) IRQ_UART0_Tx_Handler(void)
{
IOCLR =0x00000080; <----- LED, active low never turns ON
...
etc.
}

--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...> wrote:
> At 10:28 AM 7/6/04 +0000, you wrote:
> 
> > > I also stumbled across this description. Obviously, this is a
> >copy-and-paste
> > > from the description of the '550-UART IP-Core.
> >
> >I thought it might be something like that. So given that the FIFO is
> >preconfigured, how do I know when the FIFO is full?
> 
> In this respect, it behaves as all '550s.  When the THRE interrupt
fires 
> the FIFO is empty and you can put up to 16 bytes into it.  Something
like

> 
>   case RECEIVE:
>      for( i = 0; i <16; i++) {
>           U0THR = buf[i];
>       }
>       break;
> 
> Oversimplified but it illustrates the point.
> 
> AFAIR this is documented in all of a sentence or maybe two.
> 
> BTW, I would be very interested if anyone else has run into the missing 
> THRE interrupt symptoms I've seen.
> 
> 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

At 01:46 PM 7/28/04 +0000, you wrote:
>Hello all,
>
>I am puzzled by perhaps similar thing re: missing THRE int., FIFO empty?
>Can anyone plese help me to see what I do incorrectly?
>
>Polled UART0 works, INT on THRE doesn't.
>Timer0 ISR works, though.

Just a quick question, are you are sending are byte directly by writing it 
to the THR before you expect to get a THRE interrupt (the transmission does 
need to be primed)?

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

void tx(char c)
{
	UART0_THR = c;
}

..and then I expect INT (after the 8th bit is out).

--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...> wrote:
> At 01:46 PM 7/28/04 +0000, you wrote:

> Just a quick question, are you are sending are byte directly by
writing it 
> to the THR before you expect to get a THRE interrupt (the
transmission does 

> need to be primed)?
> 
> 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

I'm going to take a deeper look at this in a bit (when I get a break) but 
initially it looks OK.  In the meantime, however, a couple of 
questions/suggestions.

- Is anything happening at the receive side (Is the transmit looped back, 
is the receive getting info from somewhere) or is it transmit only?
- How about putting in a check in the main body (IE non-interrupt) or the 
timer  to check the THRE flag and set an LED if it  is set?  That way you 
should be able to tell if the flag has gone up but the interrupt has 
disappeared.  Maybe you've found a way to harden what I've seen.

At 02:40 PM 7/28/04 +0000, you wrote:
>void tx(char c)
>{
>         UART0_THR = c;
>}
>
>..and then I expect INT (after the 8th bit is out).

I figured it was probably something like that.  Just wanted to be sure of 
the obvious :)

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

OK, I've been through it again.  I didn't see anything obvious.  Would I be 
correct in assuming you get one character out and then nothing?

Robert

At 02:40 PM 7/28/04 +0000, you wrote:
>void tx(char c)
>{
>         UART0_THR = c;
>}
>
>..and then I expect INT (after the 8th bit is out).

" '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

Robert, thanks for your ideas.
Alas... "Houston..we have a problem". :-)
I have found out that I can service only INT of TIMER0, and not TIMER1
and UART0_THRE. It appears, the problem might be somewhere else 
(ivt.s -> linking?).
In the polled Tx_ing there is no problem, I got 115200 out okay.
FIFO is okay, but I want to buffer it w/128 bytes and INT. 
Is it foolish?
Page 89 looks (Oct 02, '03 specs) great, I have not study it until
today on a train.
I think FIFO/U0THR needs to be "primed", as you have hinted y'day.

Summary:
my_debug_ability = 0;
JTAG_access=0;
ddd_or_insight=0;
GNUARM+=cygwin;
Olimex = 0x01;

Does this snippet look okay (for IRQ ints)?

          NOP                       	
          LDR PC, [PC, #-0xFF0] <---- what happens here?
          LDR PC, FIQ_Addr
               
Undefined_Addr: .word Undefined_Handler
SWI_Addr:       .word SWI_Handler
Prefetch_Addr:  .word Prefetch_Handler
Abort_Addr:     .word Abort_Handler
FIQ_Addr:       .word FIQ_Handler

Happy SW trails!

--roger

--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...> wrote:
> I'm going to take a deeper look at this in a bit (when I get a
break) but 
> initially it looks OK.  In the meantime, however, a couple of 
> questions/suggestions.
> 
> - Is anything happening at the receive side (Is the transmit looped
back, 
> is the receive getting info from somewhere) or is it transmit only?
> - How about putting in a check in the main body (IE non-interrupt)
or the 
> timer  to check the THRE flag and set an LED if it  is set?  That
way you 
> should be able to tell if the flag has gone up but the interrupt has 
> disappeared.  Maybe you've found a way to harden what I've seen.
> 
> At 02:40 PM 7/28/04 +0000, you wrote:
> >void tx(char c)
> >{
> >         UART0_THR = c;
> >}
> >
> >..and then I expect INT (after the 8th bit is out).
> 
> I figured it was probably something like that.  Just wanted to be
sure of 

> the obvious :)
> 
> 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

--- roger_lynx <roger_lynx@...> wrote:

> ...... 
> 
> Does this snippet look okay (for IRQ ints)?
> 
>           NOP                       	
>           LDR PC, [PC, #-0xFF0] <---- what happens
> here?
>           LDR PC, FIQ_Addr
>                
> Undefined_Addr: .word Undefined_Handler
> SWI_Addr:       .word SWI_Handler
> Prefetch_Addr:  .word Prefetch_Handler
> Abort_Addr:     .word Abort_Handler
> FIQ_Addr:       .word FIQ_Handler
> 
> Happy SW trails!
> 
> --roger
> 
LDR PC, [PC, #-0xFF0] instruction is loacted at
0x00000018, which means the PC would have advanced to
0x00000020 this value offset -0x0FF0 would address the
location at 0xFFFF F030, which is the address of VIC
Vector Address Register. (Given in the User Manual)
You should have your IRQHandler for UART0-THRE 
Address loaded into the VICVADDRx (x between 0 to 15)
and correspondingly the VICCNTLx (corresponding to the
VICVADDR - x) should be set to 0x26 (bit 5 = 1 
indicates this Vectored IRQ slot is enabled, bit 4:0
has the value of 0b00110 indicates UART0 is enabled
for this slot). This is explained in Philips AN10254.

The instruction at 0x18 can handle all the interrupts
that are enabled in VIC, by automatically jumping to
the IRQ handler of the specific interrupt that took
place.
Hope this clarification (is correct!) and it helps
you.
Cia
Mathew 


		
__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail

You might want to check my contribution to the files section on Yahoo.
The descriptively titled 'UT040322A.zip', contains an interrupt or
polled (your choice) UART driver, non-interrupt system timer, and a
blinky lights program.  It may be of help to you.

Regards
-Bill Knight
the ARM Patch

At 10:08 AM 7/29/04 +0000, you wrote:
>Robert, thanks for your ideas.
>Alas... "Houston..we have a problem". :-)
>I have found out that I can service only INT of TIMER0, and not TIMER1
>and UART0_THRE. It appears, the problem might be somewhere else
>(ivt.s -> linking?).
>In the polled Tx_ing there is no problem, I got 115200 out okay.
>FIFO is okay, but I want to buffer it w/128 bytes and INT.
>Is it foolish?

Should be quite doable.  The FIFO just lowers the number of interrupts you 
need to respond to.

>Page 89 looks (Oct 02, '03 specs) great, I have not study it until
>today on a train.
>I think FIFO/U0THR needs to be "primed", as you have hinted y'day.

As do most UART transmit interrupts (at least the ones I've dealt with).


>Summary:
>my_debug_ability = 0;
>JTAG_access=0;
>ddd_or_insight=0;
>GNUARM+=cygwin;
>Olimex = 0x01;
>
>Does this snippet look okay (for IRQ ints)?
>
>           NOP
>           LDR PC, [PC, #-0xFF0] <---- what happens here?
>           LDR PC, FIQ_Addr
>
>Undefined_Addr: .word Undefined_Handler
>SWI_Addr:       .word SWI_Handler
>Prefetch_Addr:  .word Prefetch_Handler
>Abort_Addr:     .word Abort_Handler
>FIQ_Addr:       .word FIQ_Handler

The ldr PC, {pc, #-0FF0] is just an indirect jump using the vector provided 
by the VIC.

Given that only one interrupt is responding I'm wondering about your 
interrupt acknowledgement.  Do you have an interrupt acknowledge sequence 
at the end of the interrupt response routines to inform the VIC that you 
have finished with the interrupt?

         ldr     r0, =VICVectAddrRead    /*  Let VIC know we are done.   */
         str     r0,[r0]

Without something like the above the VIC will never know you are done with 
the interrupt.

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

--- In lpc2000@yahoogroups.com, "Bill Knight" <BillK@t...> wrote:
> You might want to check my contribution to the files section on 
Yahoo.
> The descriptively titled 'UT040322A.zip', contains an interrupt or
> polled (your choice) UART driver, non-interrupt system timer, and a
> blinky lights program.  It may be of help to you.
> 
> Regards
> -Bill Knight
> the ARM Patch

Hey Bill,

I took a close look at the 'UT040322A.zip' files and I noticed 
something in the UART initializer ("uart0Init" in uart.c) that I 
need your clarification on.

;void uart0Init(uint16_t baud, uint8_t mode, uint8_t fmode)
;{
;......
;......
;  // set the number of characters and other
;  // user specified operating parameters
;  U0LCR = (mode & ~ULCR_DLAB_ENABLE);
;  U0FCR = fmode;

There are defines for bits 4 & 5 of fmode that I think corresponds 
to TxFIFOs (interpreting the header files). But I thought writing 
1's to the UART FCR [5:3] shouldn't be done (stated in the lpc21xx 
manual)...unless u really know what u are doing. I can't find any 
documentation in the manual for setting TxFIFO levels but that piece 
of code seems to suggest otherwise. Could u explain what the 
Reserved bits ( 3, 4 & 5) in U0FCR [5:3] are for? 

Thanks. 
Leighton

Looks like you found a mistake in my header files.  The bit definitions
for the Fifo Control Register should be as follows:

// FIFO Control Register bit definitions
#define UFCR_FIFO_ENABLE    (1 << 0)    // FIFO Enable
#define UFCR_RX_FIFO_RESET  (1 << 1)    // Reset Receive FIFO
#define UFCR_TX_FIFO_RESET  (1 << 2)    // Reset Transmit FIFO
#define UFCR_FIFO_TRIG1     (0 << 6)    // Trigger @ 1 character in FIFO
#define UFCR_FIFO_TRIG4     (1 << 6)    // Trigger @ 4 characters in FIFO
#define UFCR_FIFO_TRIG8     (2 << 6)    // Trigger @ 8 characters in FIFO
#define UFCR_FIFO_TRIG14    (3 << 6)    // Trigger @ 14 characters in FIFO

I will correct the header file and repost the example code.

-Bill



On Fri, 30 Jul 2004 14:32:58 -0000, Leighton Rowe wrote:

--- In lpc2000@yahoogroups.com, "Bill Knight" <BillK@t...> wrote:
> You might want to check my contribution to the files section on 
Yahoo.
> The descriptively titled 'UT040322A.zip', contains an interrupt or
> polled (your choice) UART driver, non-interrupt system timer, and a
> blinky lights program.  It may be of help to you.
> 
> Regards
> -Bill Knight
> the ARM Patch

Hey Bill,

I took a close look at the 'UT040322A.zip' files and I noticed 
something in the UART initializer ("uart0Init" in uart.c) that I 
need your clarification on.

;void uart0Init(uint16_t baud, uint8_t mode, uint8_t fmode)
;{
;......
;......
;  // set the number of characters and other
;  // user specified operating parameters
;  U0LCR = (mode & ~ULCR_DLAB_ENABLE);
;  U0FCR = fmode;

There are defines for bits 4 & 5 of fmode that I think corresponds 
to TxFIFOs (interpreting the header files). But I thought writing 
1's to the UART FCR [5:3] shouldn't be done (stated in the lpc21xx 
manual)...unless u really know what u are doing. I can't find any 
documentation in the manual for setting TxFIFO levels but that piece 
of code seems to suggest otherwise. Could u explain what the 
Reserved bits ( 3, 4 & 5) in U0FCR [5:3] are for? 

Thanks. 
Leighton







Yahoo! Groups Links

That clear things up big time. Thanks again. :) 

> Looks like you found a mistake in my header files.  The bit 
definitions
> for the Fifo Control Register should be as follows:
> 
> // FIFO Control Register bit definitions
> #define UFCR_FIFO_ENABLE    (1 << 0)    // FIFO Enable
> #define UFCR_RX_FIFO_RESET  (1 << 1)    // Reset Receive FIFO
> #define UFCR_TX_FIFO_RESET  (1 << 2)    // Reset Transmit FIFO
> #define UFCR_FIFO_TRIG1     (0 << 6)    // Trigger @ 1 character 
in FIFO
> #define UFCR_FIFO_TRIG4     (1 << 6)    // Trigger @ 4 characters 
in FIFO
> #define UFCR_FIFO_TRIG8     (2 << 6)    // Trigger @ 8 characters 
in FIFO
> #define UFCR_FIFO_TRIG14    (3 << 6)    // Trigger @ 14 characters 
in FIFO

> 
> I will correct the header file and repost the example code.
> 
> -Bill
>

Leighton:

I noticed that you made a revision to your interrupt-driven UART 
routines to disable/restore global interrupts around the 
disabling/enabling of the transmit and receive interrupts.  What was 
your rationale for making this change?

Thanks,

JT

--- In lpc2000@yahoogroups.com, "johnthomasedwardtimm" <area51@a...> 
wrote:
> Leighton:
> 
> I noticed that you made a revision to your interrupt-driven UART 
> routines to disable/restore global interrupts around the 
> disabling/enabling of the transmit and receive interrupts.  What 
was 
> your rationale for making this change?
> 
> Thanks,
> 
> JT

This question is actually directed towards Bill Knight (the author of 
the UART routines).  Sorry about the confusion.

The code is actually Bill's, so it's better that u ask him. 

Maybe the global disable/enable part prevents any spurious events 
from occuring while changing the uart interrupt enable registers.




--- In lpc2000@yahoogroups.com, "johnthomasedwardtimm" <area51@a...> 
wrote:
> Leighton:
> 
> I noticed that you made a revision to your interrupt-driven UART 
> routines to disable/restore global interrupts around the 
> disabling/enabling of the transmit and receive interrupts.  What 
was 

> your rationale for making this change?
> 
> Thanks,
> 
> JT

That is the reason but has been in the code for some time.
This was discussed in length on this forum a while back.
You might want to check the archives for more details.

-Bill



On Fri, 30 Jul 2004 19:15:54 -0000, Leighton Rowe wrote:

The code is actually Bill's, so it's better that u ask him. 

Maybe the global disable/enable part prevents any spurious events 
from occuring while changing the uart interrupt enable registers.




--- In lpc2000@yahoogroups.com, "johnthomasedwardtimm" <area51@a...> 
wrote:
> Leighton:
> 
> I noticed that you made a revision to your interrupt-driven UART 
> routines to disable/restore global interrupts around the 
> disabling/enabling of the transmit and receive interrupts.  What 
was 

> your rationale for making this change?
> 
> Thanks,
> 
> JT

Is there a way to disable interrupts at the VIC or does it have to be 
through the CPSR?  I tried something like this:

unsigned save;

save = VICIntEnable;
VICIntEnClr = 0xffffffff;

// interrupts disable here

VICIntEnable = save;

This method definitely does not work as expected.  Any ideas?

Thanks,

JT

--- In lpc2000@yahoogroups.com, "Bill Knight" <BillK@t...> wrote:
> That is the reason but has been in the code for some time.
> This was discussed in length on this forum a while back.
> You might want to check the archives for more details.
> 
> -Bill
> 
> 
> 
> On Fri, 30 Jul 2004 19:15:54 -0000, Leighton Rowe wrote:
> 
> The code is actually Bill's, so it's better that u ask him. 
> 
> Maybe the global disable/enable part prevents any spurious events 
> from occuring while changing the uart interrupt enable registers.
> 
> 
> 
> 
> --- In lpc2000@yahoogroups.com, "johnthomasedwardtimm" 
<area51@a...> 

> wrote:
> > Leighton:
> > 
> > I noticed that you made a revision to your interrupt-driven UART 
> > routines to disable/restore global interrupts around the 
> > disabling/enabling of the transmit and receive interrupts.  What 
> was 
> > your rationale for making this change?
> > 
> > Thanks,
> > 
> > JT

Hello all,

I'd like to thank all who suggested their solution(s) to my post.
My error was that I was "enabling" THRE interrupt in U0IER reg. while
DLAB was set. 
The said interrupt can be turned ON when DLAB=0 *ONLY*.
<Duh>.
Now all my three ints (TIMER0, TIMER1, UART_THRE)run okay.

Thanks again.

--roger

--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...> wrote:

> 
> >Page 89 looks (Oct 02, '03 specs) great, I have not study it until
> >today on a train.
> >I think FIFO/U0THR needs to be "primed", as you have hinted y'day.
> 
> As do most UART transmit interrupts (at least the ones I've dealt with).
> Given that only one interrupt is responding I'm wondering about your 
> interrupt acknowledgement.  Do you have an interrupt acknowledge
sequence 
> at the end of the interrupt response routines to inform the VIC that
you 
> have finished with the interrupt?
> 
>          ldr     r0, =VICVectAddrRead    /*  Let VIC know we are
done.   */
>          str     r0,[r0]
> 
> Without something like the above the VIC will never know you are
done with 
> the interrupt.