| View previous topic :: View next topic |
| Author |
Message |
soonc
Joined: 03 Dec 2013
Posts: 215
|
| Soft UART Max Speed ? |
 Posted: Sat Aug 22, 2015 9:02 pm |
 |
|
I'd like get opinion/experience about using a soft UART between two PIC chips.
Here is my intended setup:
Chip 1 is a PIC12F629 Can only use Soft UART.
| Code: |
#use delay(clock=2000000)
#use rs232(baud=600, parity=N, xmit=PIN_A0, rcv=PIN_A3, bits=8, FORCE_SW, DISABLE_INTS ) |
Chip 2 is a PIC24FJ128GA306 All Hardware UARTs are used.
| Code: |
#use delay(clock=29491200, crystal=7372800)
#use rs232(baud=600, parity=N, xmit=PIN_E6, rcv=PIN_E7, bits=8, FORCE_SW )
|
Interrupt on Chip 2 must not be disabled.
The communication session will always be started by Chip 2, and the number of bytes transferred will be 4-6 in any one session.
Clearly Chip 1 is the weak link.
My Question:
From experience what do you recommend as the maximum Baud Rate for a setup like this ? |
|
 |
Ttelmah
Joined: 11 Mar 2010
Posts: 19255
|
|
| Posted: Sun Aug 23, 2015 1:08 am |
|
|
Actually the weak link is chip 2, if you are not disabling interrupts.....
The problem is that if an interrupt occurs during the sampling or sending of a bit, the timing will be out by the total time involved in handling this interrupt. Error must not exceed a total of about 1/4 bit time for the link.
You would need to sit down and calculate the worst case delay any of your interrupts might cause (time the handler in MPLAB, or do it by having a fixed delay on a scope, and measuring the change when the interrupt is triggered). Then this delay gives the limit for maximum rate.
However consider going much faster and disabling interrupts. At 2MHz, you can go to about 12500bps. Even better take the small chip to 8Mhz, and clock at say 50Kbps. Then all six bytes would take less than 1mSec.... |
|
|
soonc
Joined: 03 Dec 2013
Posts: 215
|
| More speed may be better |
| Posted: Sun Aug 23, 2015 8:18 am |
|
|
| Ttelmah wrote: | Actually the weak link is chip 2, if you are not disabling interrupts.....
The problem is that if an interrupt occurs during the sampling or sending of a bit, the timing will be out by the total time involved in handling this interrupt. Error must not exceed a total of about 1/4 bit time for the link.
You would need to sit down and calculate the worst case delay any of your interrupts might cause (time the handler in MPLAB, or do it by having a fixed delay on a scope, and measuring the change when the interrupt is triggered). Then this delay gives the limit for maximum rate.
However consider going much faster and disabling interrupts. At 2MHz, you can go to about 12500bps. Even better take the small chip to 8Mhz, and clock at say 50Kbps. Then all six bytes would take less than 1mSec.... |
Thanks for you reply you gave me a lot of food for thought.
Chip 2 will be "ticking" at about 5mS and must not be stopped.
The small data packet sent by Chip2 to the slower Chip 1 can be sent in between the 5mS tick.
Chip 1 needs to run at 2MHz, I chose this clk speed as it still gives me enough cpu speed while keeping the power consumption low.
Thanks for the suggestions I'll experiment when the prototype pcb arrives. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9134
Location: Greensville,Ontario
|
|
| Posted: Sun Aug 23, 2015 10:03 am |
|
|
Since you're still in the 'design / proof of concept' stage, consider using a PIC WITH a hardware UART as 'PIC #1'. It might cost you an extra 50 cents BUT you'll have more features( memory,UART,speed, etc.)
Just an idea....
All too often I see the 'save a penny, spend a pound' problem here. You 'save' a penny' by choosing a 'small' PIC then 'spend a pound' in extensive R&D costs(labour and time) trying to get the little PIC to work for you.
Jay |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19255
|
|
| Posted: Sun Aug 23, 2015 10:40 am |
|
|
Also consider another possibility.
Is the I2C peripheral available on the PIC24?.
The little PIC could be an I2C master and send/receive from the PIC24, and then the communications are synchronous, so slight delays in the comm's won't matter. |
|
|
soonc
Joined: 03 Dec 2013
Posts: 215
|
| Thanks for both suggestions |
| Posted: Sun Aug 23, 2015 4:14 pm |
|
|
That sure gives me a lot to consider.
A different chip with built in H/W UART could be an easy out.
I2C I'm not sure there's enough code space in the PIC12 to do that.
The PIC12 is a legacy part of a design, the PIC24 is the new chip.
First I'll experiment with the faster Baud rate and try to send the data byte by byte inside of the 5mS system tick. It may take 5-6 ticks to send the data but the PIC12 should be able to handle that.
Thanks again. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19255
|
|
| Posted: Mon Aug 24, 2015 12:11 am |
|
|
It's worth realising that if you use DISABLE_INTS, this is done on a _per character_ basis. So that the interrupt is disabled for just one character time. Even if a timer tick occurs the maximum delay on handling this would be just one character time.
I2C master takes no more code space than software async serial.
What you can't do is a _slave_ (requires hardware). |
|
|
soonc
Joined: 03 Dec 2013
Posts: 215
|
| Good tip |
| Posted: Mon Aug 24, 2015 7:29 am |
|
|
| Ttelmah wrote: | It's worth realising that if you use DISABLE_INTS, this is done on a _per character_ basis. So that the interrupt is disabled for just one character time. Even if a timer tick occurs the maximum delay on handling this would be just one character time.
I2C master takes no more code space than software async serial.
What you can't do is a _slave_ (requires hardware). |
That's a handy tip, and makes the idea of sending the packet one byte at a time much easier.
I really do appreciate the help.
Thanks |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19255
|
|
| Posted: Mon Aug 24, 2015 7:57 am |
|
|
I must admit I use a soft UART on a PIC12LF1822 to handle a couple of control bytes from a 18LF45K50. Using regulated 3.3v, the internal oscillator on the 1822 is warranted to be within +/-2% up to 60C, and I've never seen any timing problems from this. Both the hardware UART's on the K50 are already in use, as is the MSSP, as is the hardware UART on the 1822. I worked on the simple basis of benchmarking the output from the soft UART, and winding the rate up till it was no longer correctly generated, and then operating below this speed, with the interrupts disabled. In my case I had to ensure that bytes arriving at 115200bps would still be handled on one of the hardware UART's. Since these take 86.8uSec per byte, I needed the worst case interrupt handling pause to not exceed this. I ran at 150kbPS, and it has been totally reliable.
What you haven't told us is which direction the data has to go?. It gets far harder if there is bi-directional comm's. Generally also the power consumption of other things is more than the small PIC. Remember you can turn this up just to do the communication, then slow down again if required. |
|
|
soonc
Joined: 03 Dec 2013
Posts: 215
|
| Great info |
| Posted: Mon Aug 24, 2015 8:45 pm |
|
|
| Ttelmah wrote: | I must admit I use a soft UART on a PIC12LF1822 to handle a couple of control bytes from a 18LF45K50. Using regulated 3.3v, the internal oscillator on the 1822 is warranted to be within +/-2% up to 60C, and I've never seen any timing problems from this. Both the hardware UART's on the K50 are already in use, as is the MSSP, as is the hardware UART on the 1822. I worked on the simple basis of benchmarking the output from the soft UART, and winding the rate up till it was no longer correctly generated, and then operating below this speed, with the interrupts disabled. In my case I had to ensure that bytes arriving at 115200bps would still be handled on one of the hardware UART's. Since these take 86.8uSec per byte, I needed the worst case interrupt handling pause to not exceed this. I ran at 150kbPS, and it has been totally reliable.
What you haven't told us is which direction the data has to go?. It gets far harder if there is bi-directional comm's. Generally also the power consumption of other things is more than the small PIC. Remember you can turn this up just to do the communication, then slow down again if required. |
That's great information thanks.
Chip 2 Starts the conversation and sends 2 to 4 bytes depending upon the command.
Chip 1 NEVER starts a conversation.
If a "set" command is sent then it will be 4 bytes, chip 1 does not reply.
If it's and inquiry then it's 2 bytes and Chip 1 replies with 2 bytes.
The only issue with testing on Chip 1 (12F629) is it limited or no debugging features ( think they make a special chip for debugging), but I can ziff mount an 8 pin DIP version on a bread board and simply reprogram each time. I'll slowly crank up the Baud rate until errors occur.
As you can run such a high Baud rate I have great hopes that I'll be able to do it all inside the 5mS tick.
This weekend I'll wire it all up.
At the moment Chip 1 draws 270Micro-Amps the entire legacy system runs at 2mA and Chip 2 switches clocks when needed to do other stuff. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19255
|
|
| Posted: Tue Aug 25, 2015 12:48 am |
|
|
| Not with 2MHz CPU clock though.... |
|
|
soonc
Joined: 03 Dec 2013
Posts: 215
|
| Yes 270uA with 2Mhz Clk |
| Posted: Tue Aug 25, 2015 7:27 am |
|
|
| Ttelmah wrote: | | Not with 2MHz CPU clock though.... |
|
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19255
|
|
| Posted: Tue Aug 25, 2015 8:54 am |
|
|
The point is you won't get to the baud rates I was running with 2MHz.
As I pointed out though, you could increase the clock for the transfer, then slow down again. Or could you switch to a 8pin chip with a UART, which potentially would allow this to handle much faster comms. |
|
|
soonc
Joined: 03 Dec 2013
Posts: 215
|
| H/W UART ? |
| Posted: Tue Aug 25, 2015 10:23 am |
|
|
| Ttelmah wrote: | The point is you won't get to the baud rates I was running with 2MHz.
As I pointed out though, you could increase the clock for the transfer, then slow down again. Or could you switch to a 8pin chip with a UART, which potentially would allow this to handle much faster comms. |
I did not know 8pin PIC Chip had H/W UART's ! Part number ? |
|
|
alan
Joined: 12 Nov 2012
Posts: 350
Location: South Africa
|
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
