|
|
View previous topic :: View next topic |
Author |
Message |
firasmail2000@yahoo.com
Joined: 06 Apr 2009 Posts: 5 Location: Jordan
|
Running 3 Software RS232 Full Duplex Ports Simultaneously |
Posted: Mon Apr 06, 2009 2:46 am |
|
|
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
|
|
Posted: Mon Apr 06, 2009 5:18 am |
|
|
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
|
|
Posted: Mon Apr 06, 2009 9:17 am |
|
|
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
|
|
Posted: Mon Apr 06, 2009 1:58 pm |
|
|
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
|
|
Posted: Mon Apr 06, 2009 5:30 pm |
|
|
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
|
|
Posted: Mon Apr 06, 2009 6:17 pm |
|
|
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
|
|
Posted: Mon Apr 06, 2009 11:24 pm |
|
|
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
|
|
Posted: Mon Apr 06, 2009 11:28 pm |
|
|
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
|
|
|
ckielstra
Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands
|
|
Posted: Tue Apr 07, 2009 6:47 am |
|
|
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
|
|
Posted: Tue Apr 07, 2009 7:27 am |
|
|
[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!! |
|
|
|
|
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
|