 |
 |
| View previous topic :: View next topic |
| Author |
Message |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
 Posted: Sat Oct 22, 2011 12:42 pm |
 |
|
Download the 16F88 data sheet:
http://ww1.microchip.com/downloads/en/DeviceDoc/30487c.pdf
In it, search for this:
You will quickly find this section:
| Quote: |
2.1 Program Memory Organization
The Reset vector is at 0000h and the interrupt vector is at 0004h.
|
You can do that search for any PIC data sheet. For 16F, it's always at
0004h. Look in your .LST file at that address. That's where the CCS
interrupt dispatcher code is placed by the compiler (if you have an
#int_xxx directive above a function).
For an explanation of the code there, see this thread. The modern code
is somewhat different than the example given, but it's close enough so
the explananations are still helpful:
http://www.ccsinfo.com/forum/viewtopic.php?t=29173
With regard to your delay testing code, those are code snippets, not a
complete test program with #include, #fuses, #use delay, main(), etc.
But in any case, I can't work on it until tomorrow. |
|
 |
pumazzz
Joined: 19 Oct 2011
Posts: 12
|
|
| Posted: Sun Oct 23, 2011 3:53 am |
|
|
| PCM programmer wrote: | With regard to your delay testing code, those are code snippets, not a
complete test program with #include, #fuses, #use delay, main(), etc.
But in any case, I can't work on it until tomorrow. |
Program:
| Code: | #include <16F88.h>
#FUSES INTRC, NOWDT, NOPROTECT ,NOLVP,NOBROWNOUT
#use delay(clock=8000000)
#use fast_io (A)
#use fast_io (B)
#include "transceiver.h"
#include "transceiver.c"
#define SPI_MODE_0 (SPI_L_TO_H | SPI_XMIT_L_TO_H)
unsigned char DATA2[32]={0xAA,0xBB,0xCC,0xDD,0x11,0x22,0x33,0x44,0x55};
unsigned char *pData;
void main()
{
setup_oscillator(OSC_8MHZ);
ext_int_edge(H_TO_L);
enable_interrupts(GLOBAL);
enable_interrupts(INT_EXT);
setup_spi(SPI_MASTER | SPI_MODE_0 | SPI_CLK_DIV_4);
PIC_init();
transciever_init();
pData = DATA2;
while(1)
{
output_high(PIN_A1);
output_low(PIN_A1);
transceiver_write_tx_payload(pData, 5, false);
output_high(PIN_A1);
output_low(PIN_A1);
delay_ms(x);//x=1,2,3
}
} |
|
|
|
pumazzz
Joined: 19 Oct 2011
Posts: 12
|
|
| Posted: Sun Oct 23, 2011 3:58 am |
|
|
| PCM programmer wrote: | | You can do that search for any PIC data sheet. For 16F, it's always at 0004h. Look in your .LST file at that address. That's where the CCS interrupt dispatcher code is placed by the compiler (if you have an #int_xxx directive above a function). |
I counted my code in .LST file, found out 55 instruction cycles for interrupt overhead. I began to count from the address 0004h
and I found the following saying in datasheet
"For external interrupt events, such as the INT pin or PORTB change interrupt, the interrupt latency will be three or four instruction cycles."
So that why you tell the interrupt overhead is 58 instruction cycles. Thanks very much |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Sun Oct 23, 2011 1:15 pm |
|
|
Your test program doesn't compile. It's missing several things. To make
it compile I would have to imagine and write the missing routines. But
then it wouldn't be the actual same test program. I've done enough on
this thread. I don't want to work on it any more. |
|
|
pumazzz
Joined: 19 Oct 2011
Posts: 12
|
|
| Posted: Sun Oct 23, 2011 1:44 pm |
|
|
| PCM programmer wrote: | Your test program doesn't compile. It's missing several things. To make
it compile I would have to imagine and write the missing routines. But
then it wouldn't be the actual same test program. I've done enough on
this thread. I don't want to work on it any more. |
 Thank you very much for the information and suggestions you gave in this thread, it is very useful. I will try to solve the problems. |
|
|
RF_Developer
Joined: 07 Feb 2011
Posts: 839
|
|
| Posted: Mon Oct 24, 2011 1:43 am |
|
|
| pumazzz wrote: | | PCM programmer wrote: | Your test program doesn't compile. It's missing several things. To make
it compile I would have to imagine and write the missing routines. But
then it wouldn't be the actual same test program. I've done enough on
this thread. I don't want to work on it any more. |
Thank you very much for the information and suggestions you gave in this thread, it is very useful. I will try to solve the problems. |
Pumaazzz, you have clearly spent a lot of time trying to predict and explain the timing of your code on the PIC. You have spent a lot of other people's time too... PCM has now given up trying to help you. The one thing I want to know is why? Why is this timing so important? What is so critical about this timing that it has to be microsecond perfect? If it really has to be that precise then a hardware (possibly an FPGA) solution is more appropriate. Even an upgrade to the compiler will probably be enough to knock the timing out significantly and you'll have to go through the timing analysis all over again.
I suspect you may be misreading the datasheet for the device you are interfacing to. Very few devices or protocols require you to respond with such precision, most timings are minimums or maximums. So what is the problem you are tying to solve. So far you've spent a lot of our time and energy looking at symptoms. Rather, I suspect, than the cause of the problem.
RF Developer |
|
|
|
|
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
