rs-232 on LPC-P2148

Kyer wrote:
> Besides, is there any piece of documentation for the LPC-P2148 you
> recommend? I just can´t find any.

Uh... you might try the manufacturers user manual, from the
manufacturer's site (somehow that seems too obvious!?):
http://www.nxp.com/acrobat/usermanuals/UM10139_1.pdf

Clifford Slocombe wrote:
>(somehow that seems too obvious!?):

For something perhaps a little less obvious and definitely very helpful
in your situation try also "The Insider's Guide To The Philips
ARM7-Based Microcontrollers:
An Engineer's Introduction To The LPC2000 Series" available at
http://www.hitex.co.uk/download.html (click the 'Insiders Guides' link).
You need to register to get it, but it is worth it.

Martin Thomas wrote:
> See www.efsl.be and
> http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/efsl_arm/index.html
> Download the package from the link [T4]. An example-application is
> included (UART and SD/MMC-Card).
>

Some caution required here. I believe most of UART examples are polled.
If you want to perform SD and serial I/O asynchronously, you will have
to implement buffered interrupt driven serial I/O. Otherwise if you
recieve serial data while you are writing to the card (which is
necessarily polled), you will get a serial buffer overrun and loose
data.

Also, SD cards vary wildly in write speed, I have had cards that barely
achieve 32Kb/sec while others can get >500Kb/sec. This performance is
independent of the SPI clock rate applied, and is down to the 'busy'
polling needed. This performance variation will inform the buffer size
you will need for the serial I/O.

Finally, SD card performance is drastically reduced when writing very
small data chunks, because of the fixed overhead required to perform
every access. So to maximise performance you should buffer the data and
write in larger chunks. For example in my tests I achived 55ms for a 1kb
write, but only 330ms for 128kb. This buffer should be secondary to and
larger than the serial i/o buffer as it needs different charactaristics.

You might get away with polled serial I/O if the incomming data is
periodic and relatively infrequent, so that you know after receiving
data you will never receive more until the SD write has completed. But
for the little effort it required, buffered serial I/O is mich more
flexible.

Another (nasty) solution, is to modify the low-level SD card driver so
that it polls and bufferes serial input while servicing the card, but
frankly this would be very hard to maintain evne if it worked at all.

Clifford