Lpc2000

http://www.keil.com/download/docs/288.asp

--- In lpc2000@yahoogroups.com, Sten <list@n...> wrote:
>
> dr_danish_ali wrote:
> > Hi Folks,
> >     I am very new to the lpc2xxx family (although I am competent
at PICs) so I am looking 
> > at what other people do with the peripherals. My current line of
investigation is the UARTs, 
> > which are described as "550-compatible".
> > Of course I want everything i.e. interrupt-driven and
externally-buffered serial input and 
> > output, but I don't seem to be having much success at finding
example source code that 
> > makes good use of the hardware uart transmit buffer. Can people
suggest where to look / 
> > what terms to google with?
> > 
> > I have seen (for example) the drivers posted by sashi_ono but (as
I understand it) they 
> > don't use the hardware transmit buffer. Perhaps this is related to
my PIC background, 
> > where I previously had to scrape every last cycle of performance
out of the hardware but 
> > that's unnecessary in the luxurious arm environment.
> > 
> > What's the problem with that code? I'm in no position to criticise
- I assume this is solid, 
> > working code (more than anything I've produced) but I reckon it
doesn't use the 16-level 
> > FIFO on transmit. This is a low-level hardware issue because the
THREEmpty interrupt 
> > occurs when the FIFO is _empty_ - not when there's space to put
more characters into it. 
> > So you could - assuming there are that many characters in the
external transmit buffer - 
> > pump 16 characters into U0THR in response to a THREEmpty
interrupt, and thereby save 
> > up to 15/16 ISR call overheads.
> > 
> > Is this worth the extra effort for an arm? It was often done in
the days of the PC. The ISR 
> > call overhead is not very great in terms of cycles, and it might
only be noticed at high baud 
> > rates.
> > 
> > What do people think? I invite comments on this point.
> > 
> > Regards,
> > Danish
> > 
> 
> Hi,
> 
> if you have a 16byte-hardware-FIFO why you should not use it?!?
> I have written an interrupt-driven driver which is using configurable
> software TX and RX FIFOs between ISR and task. The task is feeding the
> TX FIFO with data and the ISR in background is feeding UART's hardware
> FIFO with 16 bytes/call (if available) from TX FIFO. It's a maximum
> efficiency with a minimum overhead.
> 
> (void) uart_write(uartNr, "Unable to encrypt! -- ", 20, 200 MSEC);
> 
> If a task wants to transmit large data, an uart_write() call is writing
> and sleeping to the TX FIFO until all data has been transmitted (20
> bytes) or a timeout has been occured (200 msec).
> 
>   Sten
> 
> -- 
> /************************************************
>  Do you need a tiny and efficient real time
>  operating system (RTOS) with a preemtive
>  multitasking for LPC2000 or AT91SAM7?
> 
>    http://nanortos.net-attack.de/
> 
>  Or some open-source tools and code for LPC2000?
> 
>    http://www.net-attack.de/
> 
> ************************************************/
>