![](templates/subSilver/images/CCSLogo.jpg) |
![CCS C Software and Maintenance Offers](templates/subSilver/images/forumAd6.jpg) |
View previous topic :: View next topic |
Author |
Message |
vpan
Joined: 31 Oct 2008 Posts: 14
|
time to transmit and execute |
Posted: Fri Oct 31, 2008 1:35 am |
|
|
hello everybody...
i try to estimate how long it takes to transmit
the following command
printf("A_%ld\n",value) where value 0-9999
and baud rate 9600
also,how long it takes for the system to execute the command?
i have a 16f628 controller with 4 MHz XT |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah Guest
|
|
Posted: Fri Oct 31, 2008 3:38 am |
|
|
Will also depend on number of bits selected, and parity etc..
Each bit takes 1/9600th second at 9600bps.
Each character, has one start bit added, and one stop bit.
If you are running at 8bits, no parity, then you have a total of ten bit times per character. 1/960th second.
Then (assuming you are using the hardware UART, not 'software serial'), the hardware has two characters of buffering present. So, if you send :
"A_0\n" (four characters), the command will return after two character times.
2/960th second.
If instead you send:
"A_9999\n" (seven characters), the command will return after five character times. 5/960th second.
Now, on your chip, you won't quite get 9600bps, with a 4MHz clock. The closest 'match', will be 9615bps (0.15% error), so in fact the times become /961.5. Also, the code will take a tiny fraction of a second to load the first characer (typically about 20uSec). However the calculation of the latter characters, is done 'while' the hardware is transmitting, so doesn't affect the results.
The major 'time', will always be the actual time needed by the hardware to send the bytes. The alternative is to use interrupt driven buffered transmission (EX_STISR.C), in which case the code will return much faster, taking perhaps a couple of mSec in total for the 'worst case' divisions. Total tansmission time, will remain the same.
Best Wishes |
|
![](templates/subSilver/images/spacer.gif) |
vpan
Joined: 31 Oct 2008 Posts: 14
|
|
Posted: Fri Oct 31, 2008 3:59 am |
|
|
thanks for answer
i want to send 7 values over 232.
can i send these values every 1ms?
i mean,do i have much time between printf() command
and UART (transmit) without PIC confuse?
if i have,what baud rate do you suggest?
else what is your suggestion about my case?
(different PIC, XT...)
UART settings is classic
1 start
1 stop
8 bits data
no parity
no flow control |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah Guest
|
|
Posted: Fri Oct 31, 2008 5:16 am |
|
|
Calculate it from what I posted.....
7*10 bits, in 1mSec, implies a bit rate of at least 70000bps. Normally 115200 would be the 'next' standard rae over this.
However you won't achieve what you want now at 4MHz.
First, the chip cannot develop this rate from this clock, with an acceptable margin.
Second, in your example, _generating_ the data for the number, will take a (as I have already said), perhaps 2mSec. At 9600bps, this is less than the time needed to transmit the data, so the transmission time is the limiting factor, but at 115200, this is no longer the case.
You would need to at least double, and probably quadruple the processor clock rate to do this.
Best Wishes |
|
![](templates/subSilver/images/spacer.gif) |
vpan
Joined: 31 Oct 2008 Posts: 14
|
|
Posted: Fri Oct 31, 2008 5:44 am |
|
|
if you were in my place
what PIC and clock (XT) will you choose?
i'm asking you because i'm confused
about how to calculate baud rate from datasheet
(tables,BRGH e.t.c) |
|
![](templates/subSilver/images/spacer.gif) |
vpan
Joined: 31 Oct 2008 Posts: 14
|
|
Posted: Fri Oct 31, 2008 5:47 am |
|
|
let me say an example
with 16f877A and 20MHz XT will be ok? |
|
![](templates/subSilver/images/spacer.gif) |
John P
Joined: 17 Sep 2003 Posts: 331
|
|
Posted: Fri Oct 31, 2008 6:01 am |
|
|
"I want to send 7 values over 232. Can I send these values every 1ms?"
It's an easy calculation. With 8 data bits, a start bit and a stop bit, at 9600Bd you need almost exactly 1msec to send 1 character.
7 values 1000 times a second is not even close. You need to rethink this setup from the start.
115.2KB is the highest rate that ordinary serial ports can handle, though if you're sending from one processor to another, you could go faster. At 115.2KB, you could get 11.5 characters over the line per msec, and I'm sure a PIC16F877 could send that many, but does the software run fast enough at the receiving end? And is 11500 chars/sec fast enough for what you want anyway?
If you need to, you could send the data in binary form and decode it at the receiving end. That would save a lot of transmission time. |
|
![](templates/subSilver/images/spacer.gif) |
Freddie
Joined: 06 Sep 2003 Posts: 49
|
|
Posted: Sat Nov 01, 2008 8:10 am |
|
|
You could time it exactly in a test program.
Code: |
// This code is not complete, just an example algorithm of sorts.
#use delay(clock=8000000)
int16 EventTime;
setup_timer_1 ( T1_INTERNAL | T1_DIV_BY_8 );
// delay(ms) = #ticks * 4 * Prescaler * 1000 / freq(MHZ)
//
// You need to pick a crystal and scale factor that
// makes the MaxTime greater than the event time. Otherwise
// you will need to use the overflow flag.
// In this example, the max event time is 262.144.
//
// Timer1 is 16 bits
// Crystal Prescaler MaxTime(ms) TimerPerTick(ms)
// 4 8 524.288 0.008
// 4 4 262.144 0.004
// 4 2 131.072 0.002
// 4 1 65.536 0.001
// 8 8 262.144 0.004 <-
// 8 4 131.072 0.002
// 8 2 65.536 0.001
// 8 1 32.768 0.0005
// 10 8 209.7152 0.0032
// 10 4 104.8576 0.0016
// 10 2 52.4288 0.0008
// 10 1 26.2144 0.0004
// 20 8 104.8576 0.0016
// 20 4 52.4288 0.0008
// 20 2 26.2144 0.0004
// 20 1 13.1072 0.0002
set_timer1(0);
printf("A_%ld\n",value);
EventTime = get_timer1();
//EventTime * 0.004 is the actual time in milliseconds. (0.004 is from the table above)
|
|
|
![](templates/subSilver/images/spacer.gif) |
|
|
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
|