Running 3 Software RS232 Full Duplex Ports Simultaneously

[[email protected]]

Hi List,

This is my first post to this list. Excuse me if I do not follow your usual posting rules,

I'm trying to build a pic based controller that needs to serve 4 RS232 full duplex users at 9600 b/s using PIC18F4620 running at 20MHz.

As you may know, this chip has only one hardware RS232 port. I need to create 3 more full duplex ports using software RS232.

My question is, is it possible to implement such configuration using ccs RTOS?.

Has any one tried to use ccs RTOS for software full duplex RS232 port? Is there an available code ?

Help is highly appreciated.

Best Regards,

Firas

[Ttelmah]

No.
Whether it is possible at all, will depend massively on what 'else' the CPU has to do. Provided nothing else requires accurate timing, then something like this may be possible, for a couple of channels, by using one of the timers, and looping tightly monitoring first the inputs, looking for a falling edge on each, and working through a state machine for the required transmissions and receptions. _But_, to do three channels, full duplex, potentially requires you to be doing six separate 'jobs' in the loop. The total 'worst case' time slice available, is only 52uSec. Just 260 instructions, in which time, you need to potentially rotate six separate bytes, test the bit values either on these, or the input port update the individual counters and bits, test the timer, and loop. In reality for the comms to be reliable, you really need to perform all this in perhaps less than half this time. You also then have the added problem that bytes may arrive or need sending from the hardware port in this same interval.
I'm afraid I'd say this is on the 'border' of impossible, even in direct assembler, though possibly just about doable. However if anything else has to happen at the same time, then it is not possible at all. If the incomming serials are synchronous to one another, it becomes a little easier, and what gaps are allowable in the output streams, also affects the precise relationship of the timings.
In the past, I have handled _one_ full duplex 9600bps serial, on an 8Mhz chip, with accurate timings, and good performance, in assembler, but though the code was optimised to be as tight as possible, it was not possble to do the same on a 6MHz chip, without loosing some of the accuracies. This suggests that 20MHz, to do 3* this work, plus handling the other hardware port, is right on the 'edge'....

Best Wishes

[[email protected]]

Hi,

Thanks for reply. Actually I did in the past running full duplex hardware rs232 and one half duplex software serial port at the same time with no problems but without RTOS. I just had no idea about ccs RTOS.

I was hoping that it will help me writing separate threads for each software serial channel (we can thought that the 3 full duplex software serial as being a 6 separate threads).

What is the main concern in your reply was that we have limited time to do this job. What about if we reduced it to one hardware and two software serial ports?

Best Regards,

Firas

[Ttelmah]

Just one full duplex port, is less than 1/3rd the work, of doing 3. I too have done this, but to do three, _will_ be pushing the available performance. Remembering that all six threads may be running at different points in the I/O, and that the timings for all, must be maintained, You are going to find it more than 3* harder. The overhead of the RTOS, is an extra, you can't afford.

Best Wishes

[ckielstra]

Serial transmission is not so difficult as you can synchronize all streams. The extra delay this introduces is no problem and allows you to put all serial transmit queues in the same timer based interrupt. Each additional channel creates minimal overhead.

What is difficult is the reception... Each channel can, and will, arrive at a random moment in time.

I implemented an interrupt driven Bit-Bang full duplex serial driver, based on code from the book Serial Communications by Roger L. Stevens (www.sq-1.com).
I tweaked the code a bit and got a stable 19k2 on a 16MHz PIC18 and there is room for a small speed increase.

So yes, given the above figures I guess it is possible to do 3 full duplex serial channels at 9600 baud on a PIC18. But you are testing the limits, it will require assembly programming. And as the PIC16 has only a single interrupt level you are not allowed to have other interrupts active (that's why I used a PIC18).

Real time OS? Forget it, the extra overhead is something you can't afford.

Would I recommend doing this? NO!!
It will take a lot of time to tweak the code for the serial ports and if the compiler decides to insert interrupt disabling code than you are in trouble. For this reason I'm stuck at v3.226 of the compiler, newer v3 versions disable the interrupts on calls to:
- read_eeprom
- write_eeprom
- memcpy with a constant string parameter.
- strcpy with a constant string parameter.
- printf of a constant string.
I haven't checked if the v4 compiler has this same behaviour.

My suggestion would be to (in order of preference):
- Use a processor with a sufficient number of serial ports. Look further than just the PIC processors, an ARM or MIPS processor might better fit your project.
or:
- Add an external UART chip connected through SPI or I2C. The MAX3100 family is well known but has a design quirk in interrupt generation which makes it a bad choice. A newer and easier to interface chip is a model from the NXP SC16C* series, where you pay about €2,50 per channel in a 1, 2 or 4-channel chip.
or:
- Use multiple PIC processors.

Remember that at low quantities (< 1000) the time and money you spend on writing the software will be much higher than the hardware costs. So anything you can do in hardware should be well considered.

[asmallri]

Three serial ports at 9600 baud full duplex is a walk in the park :-)

It requires two high priority timer interrupts, one common transmit bit time interrupt and the other running at 3 times the bit rate for the receive interrupts.
_________________
Regards, Andrew

http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!!

[[email protected]]

Hi,

> ckielstra wrote:
>
> Real time OS? Forget it, the extra overhead is something you can't afford.

Is there a timing table for CCS RTOS overhead ?


Best Regards,

Firas

[asmallri]

[MikeW]

The best solution is 1 hware uart in the pic, then the following


I have used SC16IS752 in the past, very easy, no problems.

There is also code which works on the code library site

http://www.standardics.nxp.com/products/bridges/i2c.spi.slave.uart.irda.gpio/~SC16IS760/


Mike

[ckielstra]

[asmallri]

[quote="ckielstra"]