 |
 |
| View previous topic :: View next topic |
| Author |
Message |
jmb1539
Joined: 29 Mar 2010
Posts: 11
|
| Program Counter CALL to nowhere in LST file |
 Posted: Wed Mar 27, 2013 8:39 am |
 |
|
I'm attempting to calculate the code execution time for a serial data transfer on the HW UART of a PIC18F2620 with a 20MHz oscillator by adding up all the assembly instructions from the LST file for the transfer. In the assembly, there are a couple program calls where the address to which it is calling doesn't exist anywhere in the LST file. Would I assume NOP for each address location up until the program counter reaches the next location with executable code?
Assemly showing call...
.
.
16DA: MOVFF AA,C0
16DE: MOVLW 01
16E0: MOVWF xC4
16E2: CALL 0CBA
'
'
Assembly in area of call after putting code in order
.
.
0CB2: MOVFF C3,FE9
0CB6: RRCF FED,F
0CB8: RETURN 0
0E58: CLRF FF8
0E5A: BCF F9F.0
0E5C: BSF F9F.2
.
.
Probably doesn't matter, but...... IDE, PCB, PCM, PCH, PCD 1.141
JuBo |
|
 |
Ttelmah
Joined: 11 Mar 2010
Posts: 19538
|
|
| Posted: Wed Mar 27, 2013 8:42 am |
|
|
Recompile with #nolist removed from the device header.
The compiler leaves out the code for CCS libraries unless you do this, so (for instance) the delays, RS232 etc., code won't be in the file.
Best Wishes |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19538
|
|
| Posted: Wed Mar 27, 2013 8:48 am |
|
|
Remember also that the UART transfer after the first two characters, will wait for a character to send, so better to use the MPLAB stopwatch that can simulate this.
Best Wishes |
|
|
jmb1539
Joined: 29 Mar 2010
Posts: 11
|
|
| Posted: Wed Mar 27, 2013 10:08 am |
|
|
I removed the #nolist as you mentioned and that made visible all the missing code. You're right, it contains many branches and loops that would make it virtually impossible to get an accurate calculation.
What led me down this path was an excessive delay I was seeing on my Tektronix scope of approximately 16ms from output on to output off, using the following UART setup and fprintf code, and I can't explain why it was taking so long. According to the calculation, the actual transmission of the data should take approximately 3.5 ms (if calculated correctly) at 8-N-1, 19200.
| Code: |
#USE delay(clock=20MHZ)
#USE rs232(STREAM=LCD, XMIT=PIN_C6, RCV=PIN_C7, BAUD=19200, bits=8, parity=N, ERRORS, DISABLE_INTS)
|
| Code: |
output_high(PIN_A0);
fprintf(LCD,"%c%c%c%c%03.1f Hz %c%c%c%c%03.1f%c ",
CMD,71,1,2,float1,CMD,71,10,2,float2,0xB2); // out LCD data
output_low(PIN_A0);
|
There are a couple 4-byte pic floats to ASCII conversions going on, but would that explain the extra 14ms? |
|
|
newguy
Joined: 24 Jun 2004
Posts: 1909
|
|
| Posted: Wed Mar 27, 2013 10:58 am |
|
|
| Yes it would. If at all possible, floats are to be avoided at all cost - they take a ton of memory and take forever to compute/handle/etc. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19538
|
|
| Posted: Thu Mar 28, 2013 9:53 am |
|
|
Worth realising, that printing a float, will involve repeated division, and remainders. Each division will take over 1/3rd mSec at your clock rate. It'll soon add up. Total will depend on just how large the numbers are. However if they are only (say) up to 1000, and you only want one decimal as you show, then:
| Code: |
signed int16 timesten1,timesten2;
timesten1=float1*10;
timesten2=float2*10;
fprintf(LCD,"%c%c%c%c%03.1Lw Hz %c%c%c%c%03.1Lw%c ",
CMD,71,1,2,timesten1,CMD,71,10,2,timesten2,0xB2); // out
LCD dat
|
Will be a lot faster. The division is now done in integer, with each taking less than 1/4 the time needed for the float division. The multiplication takes half the time needed for a single float division.
Remember also, you could use interrupt driven serial (EX_STISR.C), then the calculations will be being done, as the data transmits, instead of stopping for each character.
Combine the two approaches, and you'd probably find the whole thing will only take perhaps 5mSec.....
Best Wishes |
|
|
jmb1539
Joined: 29 Mar 2010
Posts: 11
|
|
| Posted: Fri Mar 29, 2013 2:46 pm |
|
|
| Thanks guys for the responses. I greatly appreciate it. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19538
|
|
| Posted: Sat Mar 30, 2013 4:20 am |
|
|
Thinking about it, there is also something wrong with your calculation.
You are using 19200bps. Each character is 10 bits (start, 8bits data, stop), so takes 0.52mSec (10/19200 second). Now you are printing 4 %c characters, then 3 characters from the float (minimum), then space, 'Hz', three spaces, then another four %c characters, then a minimum of another three characters from the float, then another %c, then three more spaces. A total of 24 characters _minimum_. Even if the maths took no time at all, it'd take 12.4mSec to send this all. In fact the maths is partially being done 'during transmission' (since the hardware buffer will be loaded, then the arithmetic done), so the overhead for the maths is only adding 1mSec.
Your '3.5mSec', is way out.....
Best Wishes |
|
|
|
|
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
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
