servicing 4+ serial ports with 8051

Hi. I got a project to design a board that can service 4+ serial ports. These ports are for various peripherals to connect to the system, such as radar detector with rs232 output, and other peripherals with rs232 output.

We used 8051 before, but the design was only able to let one peripheral to be active at a time, so it is not real-time at all and prevent other peripherals to communicate at the same time to the system.

Any suggestion? do we need RTOS or FPGA/CPLD to provide big-enough buffers for each serial ports?

Reply to
Jack
Loading thread data ...

Look into some deep-FIFO UARTS (Oxford and Exar make them). The only problem may be a shortage of external interrupt pins so that the 8051 can service each of them.

--Gene

Reply to
Gene S. Berkowitz

Have a look at TI. They have 16550 compatible uarts with 64, 128 and probably bigger fifos.

Clearly the size of the fifo you need depends on the baud rate of the serial ports and the speed of your processor.

Also you need to think about processing that data later. Assuming you have

4 serial ports ag 115k2 then you have about 40kb per second to do *something* with.

Ralph

Reply to
Ralph Mason

What are the baudrates and throughput of each device ?

Reply to
TheDoc

There are a few solutions, which is best depends on the traffic..

- If remotes can all work in ENQ-ACK modes, then simple MUX and polling will run 4 ports.

- If they talk only, but sparsely, a priority encode MUX can allocate them on a party line basis. A 80C51 with 2 UARTS would allow 4 : 2 mapping.

- If they all talk at once, and any loss is fatal, then you'll need

4 uart buffers. Rather than BIG devices like FPGA/CPLD, and QUADUARTS, a more up to date solution would be to use the tiniest uC from Cygnal/Philips as SPI-UART or i2c-UART - look at the C8051F305, or P89LPC90x series. Very small packages, and HW support for serial-serial bridges.

-jg

Reply to
Jim Granville

They are roughly as fast as 115k max. One or two maybe lower speed at 57k or less thanks for the replies.

Reply to
Jack

or less

You are not going to get an aggregate speed of over 40 kbytes/sec with an

8051. 115 kbits/s = 11500 bytes/s. Four channels will have 46 kbytes/s total. You are probably supposed to do something with the data streams?

A MC68332 was just able to run 4 channels of 115k simultaneously with two TI

16C552 interfaces (two-channel version of the PC serial chip).

Look for something more powerful, like Atmel AT91's.

Tauno Voipio tauno voipio @ iki fi

Reply to
Tauno Voipio

Tauno Voipio schrieb:

A fast 8051 core, programmed in assembly language, could perhaps handle that stream. It all depends on what really has to be done. It's not always necessary to use 32 bit chips.

--
Dipl.-Ing. Tilmann Reh
Autometer GmbH Siegen - Elektronik nach Maß.
 Click to see the full signature
Reply to
Tilmann Reh

I'm surprised that the '332 could barely handle that data, must have been some significant realtime processing going on in addition. Many of the clock-enhanced 8051's can handle that data stream. Look at the 100mhz Cygnal products for example, that allows almost 2,000 instruction cycles per byte of incoming data.

-- Regards, Albert

---------------------------------------------------------------------- AM Research, Inc. The Embedded Systems Experts

formatting link
(916) 780-7623

----------------------------------------------------------------------

Reply to
Albert Lee Mitchell

There was.

There is little sense to just receive a byte stream and push it out of another interface - that can be done cheaper with just a pair of RS -buffers.

For a single channel at 115 kbits/s there is about 90 us per character. This has to be divided by the number of channels, giving about 22 us per character for 4 channels, including any overheads.

A basic 8051 runs at about 1 instruction / us - that would let us do 22 instructions per character - a pretty tight interrupt service. The turbo versions of 8051 are a bit different story - the OP did not ask about such one.

A different story is that due to the very limited instruction addressing modes, any 8051 will lose plenty of instructions in address arithmetic, which is practically free in larger architectures.

Tauno Voipio tauno voipio @ iki fi

Reply to
Tauno Voipio

I do not think the interrupt pins should be a problem. Many of these multiple uart devices allow the use of only one interrupt line for all the uarts. I think the biggest problem will be the slow speed of a standard 8051 if the data rate is even moderately high. I would recommend a ATMega128 MCU that has 2 serial ports together with an external dual uart.

Regards Anton Erasmus

Reply to
Anton Erasmus

Yes. I have run a standard 8051 (12MHz) with the UART at 375,000kbps. At this speed, it was impossible to receive data and store it in a buffer using an interrupt handler. They only way to keep up was to poll the RI flag.

Meindert

Reply to
Meindert Sprang

Use the Quad Uart, which has 4 uarts in it and can handle four uarts at any time and it is very easy to use. I think National Semiconductors and Atmel make Quad Uarts.

Huricane

Reply to
Huricane

"Meindert Sprang" schreef in bericht news: snipped-for-privacy@news.nb.nu...

using

What did you do with the data? Just convert it from serial to parallel? I calculate 32 instruction cycles for one byte, not a great lot ;)

--
Thanks,
Frank Bemelman
 Click to see the full signature
Reply to
Frank Bemelman

less

FWIW, about 5 years ago I designed a 'data concentrator' with 8 x 9600 baud 'inputs' that output to a single 19200 baud 'output' based on a standard Intel (12Mhz) 8051.

The inputs were handled using 4 x Z80 SIO's (! because they were stock items in the company) with a PAL to generate the appropriate Z80 clock signals from the 8051. The SIO's had the ability to daisy-chain their interrupt lines (to a single interrupt input on the 8051) then you poll them for which one(s) had data ready.

The 8051 was capable of dealing with the serial streams using interrupts with software managed ring buffers and hardware flow control.

With a faster core 8051 and deep FIFO UARTs, it could be feasible at the baud rates you're talking :-/

Chris.

Reply to
CH

Indeed. This was an application with a camera and other devices on an RS-485 bus. The bus master was an ISA card with a 8051. The '51 polled the devices on the bus, read the data and stored it in an external SRAM. It then went in power-down mode, while the SRAM flipped into the memory map of the PC. So the only thing the '51 did was read data as fast as possible and dump it into memory until the end of the packet was received.

Meindert

Reply to
Meindert Sprang

Any of the new generation of 8051's should serve your needs. If the data were 16-bit chunks then the story might be different

-- Regards, Albert

---------------------------------------------------------------------- AM Research, Inc. The Embedded Systems Experts

formatting link
(916) 780-7623

----------------------------------------------------------------------

Reply to
Albert Lee Mitchell

Any of the new generation of 8051's should serve your needs. If the data were

16-bit chunks then the story might be different

-- Regards, Albert

---------------------------------------------------------------------- AM Research, Inc. The Embedded Systems Experts

formatting link
(916) 780-7623

----------------------------------------------------------------------

Reply to
Albert Lee Mitchell

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.