Yahoo Groups archive

Lpc2000

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

Message

Re: [lpc2000] optimum uart buffered transmit example?

2005-11-19 by Sten

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/

************************************************/

Attachments

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.