Philips 8051 UART (P89LPC903)

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

Reply to
pfitz
Loading thread data ...

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,
 Click to see the full signature
Reply to
Stef

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.

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.

Whatever!

--
========================================================================
          Michael Kesti            |  "And like, one and one don't make
 Click to see the full signature
Reply to
Michael R. Kesti

Hi Mark,

The link seems to be dead.

Pfitz

Reply to
pfitz

"pfitz" wrote in news: snipped-for-privacy@news.teranews.com:

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

formatting link

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

--
- Mark ->
--
Reply to
Mark A. Odell

"pfitz" wrote in news: snipped-for-privacy@news.teranews.com:

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 ->
--
Reply to
Mark A. Odell

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.
 Click to see the full signature
Reply to
Stef

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)

formatting link

Happy coding

JG

into

is

Reply to
Joseph Goldburg

"pfitz" wrote

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

Reply to
Jim Granville

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

Reply to
Schwob

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 (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
 Click to see the full signature
Reply to
CBFalconer

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.