Philips 8051 UART (P89LPC903)

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hi All,

I appreciate that this may have been asked before so I hope that you will
bear with me and offer an answer.

I am starting to write some embedded software, for the first time. But I
have extensive experience in Hardware, so I hope the learning curve isn't
going to be too steep. Basically in my first project I want to be able to
load a serial stream of data at 9600bps coming from a peripheral device into
an array on my Microcontroller. This data is coming in through the UART.

I was wondering how I manage to load this into consecutive slots. ie do I
need to interrupt the processor to say another byte is coming? If so how is
this done?

I am programming in C.


Pfitz



Re: Philips 8051 UART (P89LPC903)
Quoted text here. Click to load it
Your compiler probably comes with examples and libraries. These usually include
serial port examples. And yes: in most cases an interrupt based send/receive
routine is the best/easiest option.

--
Stef                       (remove caps and dashes from e-mail address to reply)

Death comes on every passing breeze,
We've slightly trimmed the long signature. Click to see the full one.
Re: Philips 8051 UART (P89LPC903)

Quoted text here. Click to load it

I take this to mean that you want your receiver to write the incoming
data into a circular FIFO, in which case you allocate an array of data
storage for the FIFO.  You also allocate two pointers to this array, one
for writing to it and another for reading from it.  These must be
initialized to point to the same location, typically the lowest address
in the array.

Quoted text here. Click to load it

You may use interrupts or you may poll the UART, but interrupts are more
efficient.  You first initialize the UART for the desired mode of operation
then enable its interrupt and set the EA bit.  Your UART interrupt service
routine (ISR) determines whether a receiver interrupt has occurred and, if
so, reads the UART data register, writes the data to where the write pointer
points, and advances the write pointer wrapping if necessary.

An executive (non-ISR) routine may then compare the FIFO's write and read
pointers and, if they're not equal, read the data from where the read pointer
points and advance the read pointer wrapping if necessary.

Quoted text here. Click to load it

Whatever!

--
========================================================================
          Michael Kesti            |  "And like, one and one don't make
We've slightly trimmed the long signature. Click to see the full one.
Re: Philips 8051 UART (P89LPC903)

Quoted text here. Click to load it

If you want, you can try my UART driver for the 8051. Get it here:

http://home.comcast.net/~embeddedfw /

The driver is stand-alone and written in Keil and Amrai compatible C.

--
- Mark ->
--

Re: Philips 8051 UART (P89LPC903)
Hi Mark,

The link seems to be dead.


Pfitz


Quoted text here. Click to load it



Re: Philips 8051 UART (P89LPC903)

Quoted text here. Click to load it

Ugh. The switch from attbi to comcast has not gone well. I'll send it to
you via email if you want it. Email to mark at embeddedfw dot com and I'll
send you the zip file.

Sorry,

- Mark

--
- Mark ->
--

Re: Philips 8051 UART (P89LPC903)
Quoted text here. Click to load it
That page is OK, but the link to the code gives:
As of December 2, 2003, this page is no longer available.

Looks like you used absolute links. Make them relative or replace
'attbi.com' by 'comcast.net'

--
Stef                       (remove caps and dashes from e-mail address to reply)

You're never too old to become younger.
We've slightly trimmed the long signature. Click to see the full one.
Re: Philips 8051 UART (P89LPC903)
May I suggest the P89LPC932 .....the bigger brother to the 903.

The 903 is a very very scaled down version of the 932 and am concerned
with 1k code space in the 903 you will run out of both code and data space.

Start with the bigger micro 1st more memory... then if you can fit it in to
1k code and 256 byte data
use the 903 (but I doubt it)

For both the 903 and 932 (which have the Philips flash LPC core)  use
the C code generator to generate example code for the hardware (Serial UARTs
etc)

http://www.codearchitect.org /


Happy coding


JG



Quoted text here. Click to load it
into
is



Re: Philips 8051 UART (P89LPC903)
Hi,

totally agree with Joseph. Start out with the LPC932 (best would be to
get a MCB900 board that comes with a 4k-compiler). Cost is MUCH lower
than doing it yourself 59$ or 59 Euro depending where you are. It can
be purchased through different ditributors as well as from Philips.
So, first make sure you have a tested hardware, write code for the 932
and if it fits in 1K afterwards, it is totally compatible with the 903

Schwob

Quoted text here. Click to load it

Re: Philips 8051 UART (P89LPC903)

Quoted text here. Click to load it
into

As others have suggested, look for interrupt examples.

Interrupt is normally the best solution for complex SW, as otherwise
you have to Poll  AND _guarantee_ any task branch is complete within 'next
byte arrival' time.
Not easy in C, and not conducive to safe mods in 6 months....

Another issue you will have is how to SYNC the BYTE with ARRAY index.
- your design will need some frame information. The 903 uart supports
9th Bit ADDR recognise, Frame Error and Break detect, so any of these can
be used to tell yor SW 'this is Byte#1'.
In simple systems, you can also nibble-encode, so upper nibble is ADDR, and
lower nibble is data. This wastes a little bandwidth, but allows random
order updates,
and is very simple to implement. Total datamap limit is 16 nibbles, or 8
bytes.
-jg



Re: Philips 8051 UART (P89LPC903)
Quoted text here. Click to load it

I disagree, based on the fact that he is a beginner.  A polled
system, testing for data ready in the uart, and then removing and
acknowledgeing that data, will be more instructive.  He can design
a buffer system independantly, to process the results of the
polling and getting.  He can make the getting check (and wait for)
the data ready signal.  Most of the modules will remain usable in
an eventual interrupt system, but the objectives will now be much
clearer.

By eliminating the relatively uncontrollable timing dependancies
of the interrupt system I think things will be much clearer.  His
overall flow will be:

 REPEAT
   synchronize to start of message
   get a buffer full.
   process buffer, while ignoring further input
 AD NAUSEAM.

--
Chuck F ( snipped-for-privacy@yahoo.com) ( snipped-for-privacy@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
We've slightly trimmed the long signature. Click to see the full one.

Site Timeline