CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to CCS Technical Support

Running 3 Software RS232 Full Duplex Ports Simultaneously

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
firasmail2000@yahoo.com



Joined: 06 Apr 2009
Posts: 5
Location: Jordan

View user's profile Send private message Yahoo Messenger

Running 3 Software RS232 Full Duplex Ports Simultaneously
PostPosted: Mon Apr 06, 2009 2:46 am     Reply with quote

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
Guest







PostPosted: Mon Apr 06, 2009 5:18 am     Reply with quote

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
firasmail2000@yahoo.com



Joined: 06 Apr 2009
Posts: 5
Location: Jordan

View user's profile Send private message Yahoo Messenger

PostPosted: Mon Apr 06, 2009 9:17 am     Reply with quote

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
Guest







PostPosted: Mon Apr 06, 2009 1:58 pm     Reply with quote

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



Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands

View user's profile Send private message

PostPosted: Mon Apr 06, 2009 5:30 pm     Reply with quote

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



Joined: 12 Aug 2004
Posts: 1634
Location: Perth, Australia

View user's profile Send private message Send e-mail Visit poster's website

PostPosted: Mon Apr 06, 2009 6:17 pm     Reply with quote

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!!
firasmail2000@yahoo.com



Joined: 06 Apr 2009
Posts: 5
Location: Jordan

View user's profile Send private message Yahoo Messenger

PostPosted: Mon Apr 06, 2009 11:24 pm     Reply with quote

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



Joined: 12 Aug 2004
Posts: 1634
Location: Perth, Australia

View user's profile Send private message Send e-mail Visit poster's website

PostPosted: Mon Apr 06, 2009 11:28 pm     Reply with quote

firasmail2000@yahoo.com wrote:
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


Even with an RTOS you can implement the SW interrupt driven UARTS however the UARTS must have a higher priority than the RTOS interrupt.
_________________
Regards, Andrew

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



Joined: 15 Sep 2003
Posts: 184
Location: Warrington UK

View user's profile Send private message

use a SC16IS752
PostPosted: Tue Apr 07, 2009 1:58 am     Reply with quote

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



Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands

View user's profile Send private message

PostPosted: Tue Apr 07, 2009 6:47 am     Reply with quote

asmallri wrote:
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.
Sounds like an interesting concept. Three times oversampling is low when compared to the 16-times oversampling used by most hardware UARTS. Can you elaborate a bit more on accuracy and / or other requirements?

High priority interrupts are not available on the original poster's PIC16, but upgrading from a PIC16 to PIC18 is relative easy.

I see you removed your serial libraries from your website. Why?
asmallri



Joined: 12 Aug 2004
Posts: 1634
Location: Perth, Australia

View user's profile Send private message Send e-mail Visit poster's website

PostPosted: Tue Apr 07, 2009 7:27 am     Reply with quote

[quote="ckielstra"]
asmallri wrote:
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.
Sounds like an interesting concept. Three times oversampling is low when compared to the 16-times oversampling used by most hardware UARTS. Can you elaborate a bit more on accuracy and / or other requirements?

The transmit side is straight forward - jitter in the transmit side processing is not really an issue (even at 115200 baud with a PIC running at 40MHz). Receive side processing is also not really a problem at this low baud rate but becomes more challenging at high baud rates. I split the receive processing into two parts, the initial sample (grabbing the input state) and the post processing of handling the state for each serial port (start bit? data bit? stop bit, serial the bytes, setting flags to emulate UART behaviour).

When a start bit is detected I would start a "first data bit counter value" effectively sampling 4 sample ticks later for the first data bit value. All subsequent bits are sampled at 3 tick intervals


Quote:

High priority interrupts are not available on the original poster's PIC16, but upgrading from a PIC16 to PIC18 is relative easy.
Quote:
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.
I did not read any reference to a PIC16F in the thread by the original poster - was this perhaps in a related thread?

Quote:
I see you removed your serial libraries from your website. Why?


The serial drivers were low cost drivers and I found I spent more time helping customers in understanding and implementing the drivers that I could justify for this type of driver - the result was supporting the serial drivers impacted my ability to develop other better selling drivers such as the SD/MMC drivers.
_________________
Regards, Andrew

http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!!
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group