 |
 |
| View previous topic :: View next topic |
| Author |
Message |
splater
Guest
|
| interupts |
 Posted: Tue Jun 13, 2006 3:50 am |
 |
|
Hi,
I use a software UART with the 18F4620
| Code: | | #USE RS232 (BAUD=9600, XMIT=PIN_D6, RCV=PIN_D7, PARITY=N, BITS=8,STREAM=SETUP) |
I use an EXT interupt
| Code: |
#INT_EXT
void Receive(void)
{
if (kbhit(SETUP)) data=getc(SETUP);
}
|
and my simple main
| Code: |
void main()
{
EXT_INT_EDGE(H_TO_L);
enable_interrupts(GLOBAL);
enable_interrupts(INT_EXT);
while (TRUE)
{
measure();
if (data=='W')
{
fprintf(SETUP,";%06.2f;%06.2f\r\n",Eactu,Eacu);
data='a';
}
}
}
|
but it doesn't seem to interupt at all time, only when I send an "WWWWWWWWWWWWWWWWWWW" continously then it interupts and goes into the fprintf ...
Someone has an idea ???
THank so much for your help.
[/quote] |
|
 |
Ttelmah
Guest
|
|
| Posted: Tue Jun 13, 2006 4:47 am |
|
|
What clock rate on the chip?.
At 9600bps, the 'start' bit, will be 104uSec long. Now the interrupt should be triggered on the fallng edge of this bit, and you need to get into the character read, before the timing has moved too far from the centre of the bit time. Something like 5uSec maximum 'error', is perhaps acceptable. Now the interrupt response, takes up to one instruction time, then there is the call, and the global handler itself takes about another 30 instruction times, before you arrive in the handler. So on a master clock of 40MHz, this should just about be OK (about 3.2uSec). However if your master clock is much below this, the problem will be that the code just does not enter the handler quickly enough. If you are not using any other interrupts, you may be able to use the 'FAST' option on the interrupt handler, and get it to work. However you would need to look through the interrupt handler listing, and see what registers are used, and save ones beyond those automatically handled by the processor (I'd suspect a couple of counters for the serial I/O).
Handling 'interrupt driven soft comms', at 9600bps, is not easy if the processor speed is lower.
Best Wishes |
|
|
splater
Guest
|
|
| Posted: Tue Jun 13, 2006 5:27 am |
|
|
thx for your answer.
I have
| Code: | | #USE delay(clock=3579000) |
I tried the FAST option but no change. Then I tried to put the RS232 at 2400 and the same thing.
It doesn't seem to be a question of clcok because trying to send 'W' but not continuous sometimes I get the respond. It sees like the INT only interuptor at some moment of the code ....
Any idea ?
Thx again |
|
|
Ttelmah
Guest
|
|
| Posted: Tue Jun 13, 2006 6:35 am |
|
|
If your crystal is only 3.579MHz, then I'm afraid it is not going to work. You can't just use the FAST option, and hope!. You need to look through the code, and save the registers manually to use this.
At 3.579MHz, you execute just under 1MIPS. The time to get into the interrupt handler, and actually read the port, is going to be something over 36uSec. I'm afraid this is just to long to work. What is happening, is that by the time the code reaches the handler, you have already probably missed the start bit, and then retrieve random garbage according to how far 'late' in the character you are. With a continuous stream of characters, sometimes you will strike lucky, and just happen to arrive in the routine in time.
Using the software serial 'interrupt driven', will _only_ work if your device is running at a relatively high rate compared to the required serial speed. You are not.
Best Wishes |
|
|
splater
Guest
|
|
| Posted: Tue Jun 13, 2006 6:52 am |
|
|
I understand this point of view but then I ask: In the last version I used the HW UART with the INT_RDA and it worked. Now I want to use other Pins and it doesn't work. Is it normal ?
Thanks |
|
|
rberek
Joined: 10 Jan 2005
Posts: 207
Location: Ottawa, Canada
|
|
| Posted: Tue Jun 13, 2006 6:58 am |
|
|
| If you are using other pins, the compiler will generate a software UART, which will be even slower than the hardware one, making your situation even worse... |
|
|
splater
Guest
|
|
| Posted: Tue Jun 13, 2006 7:09 am |
|
|
I use other pins like analogics inputs ... I just checked and I can see that it interupts on every cicles .... Peharps because it detects some changes on other pins ... Is there a way to make it interupt only if it receive a bit on the PIN D7 ???
Thx |
|
|
rnielsen
Joined: 23 Sep 2003
Posts: 852
Location: Utah
|
|
| Posted: Tue Jun 13, 2006 8:15 am |
|
|
I've used a software uart while utilizing the external interrupt to trigger the routine that read the data coming in. My oscillator was running at 19.6608MHZ. I didn't use the kbhit() because I knew that if the interrupt was entered there was a character that needed to be read. I had it running at 9600 baud.
You need to get your oscillator running as fast as you can and then make your ISR as Short as possible. Snatch the character, stuff it someplace and then get out so the ISR can be ready for the next character. Remember the KISS method (Keep It Simple Stupid).
Ronald |
|
|
Ttelmah
Guest
|
|
| Posted: Tue Jun 13, 2006 3:04 pm |
|
|
| splater wrote: | I understand this point of view but then I ask: In the last version I used the HW UART with the INT_RDA and it worked. Now I want to use other Pins and it doesn't work. Is it normal ?
Thanks |
Totally.
The 'point' is that with a hardware UART, the interrupts occur when a character is complete, and there is a whole character time, to service them. With a software UART, you _must_ be inside the service routine, in something in the order of perhaps no worse than 20% of a _bit_ time, and preferably less than 5% of a bit time, if the reception is to work....
Best Wishes |
|
|
splater
Guest
|
|
| Posted: Wed Jun 14, 2006 2:00 am |
|
|
Ok, this point is clear !
So my unique last chance: Is there a way to get an interupt only if there is a change on the D7 pin?
Thx again |
|
|
rnielsen
Joined: 23 Sep 2003
Posts: 852
Location: Utah
|
|
| Posted: Wed Jun 14, 2006 7:47 am |
|
|
After examining the data sheet, it looks as though there is no interrupt associated with pin D7. Portd is a bi-directional port. Three pins are also multiplexed with outputs P1B, P1C and P1D of the Enhanced CCP module. There is no description of an interrupt being tied to this pin.
So....
I think you're hosed in trying to get pin D7 to give you any kind of an interrupt.
Ronald |
|
|
|
|
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
