|
|
View previous topic :: View next topic |
Author |
Message |
Guest
|
RS232 is not working while EXTINT0 executing |
Posted: Wed Jun 16, 2004 2:38 am |
|
|
Dear All,
When using EXTINT0 is executing (a very short routime) my serial port RS232 (hardware) is not working. Could you please help me. In my application I'm using a INT0 just to collect some simple inputs and in paralell using RS232 to send and receive data. I need to have real time collecting data as also to handle rs232 stream.
Thank you in advance
regards
John |
|
|
Ttelmah Guest
|
Re: RS232 is not working while EXTINT0 executing |
Posted: Wed Jun 16, 2004 4:04 am |
|
|
Anonymous wrote: | Dear All,
When using EXTINT0 is executing (a very short routime) my serial port RS232 (hardware) is not working. Could you please help me. In my application I'm using a INT0 just to collect some simple inputs and in paralell using RS232 to send and receive data. I need to have real time collecting data as also to handle rs232 stream.
Thank you in advance
regards
John |
You need to post more details (processor, baud rate etc.), and probably the code of your int handler.
The most likely reason is speed. If (for instance), your RS232 is running at 19200bps, and the processor is clocked at 10MHz, then the 'character time', is approximately 52.2uSec, which is just 130 instructions. Assume the 'worst case', that the INT0 handler has higher priority than the RS232 handler (consider trying adjusting the interrupt priority...), then the global interrupt handler gets called, does all the work of saving the registers needed, then calls your 'short' interrupt handler for INT0, then returns, restores the saved registers, returns to the main program, and then interrupts to handle the RS232, again savin all the registers, ad finally calling the RS232 routine. The time needed for this depends on the processor (more instructions are required on the latter chips like the 18F family, than on older chips), but is typically perhaps 20 to 30 instruction times for the 'saver', another 20 instructions for the 'dispatcher' (this varies according to how many interrupts are in use), another 20 to 30 instruction times to restore the registers, plus the instructions in the actual 'INT0' routine. It is very easy to find that this has added up to a couple of hundred instruction times without trying very hard (remember that some very 'simple' instructions can generate a lot of code). If you assme that the 'simple' code generates 100 instructions, then the total latency in this situation becomes 30+20+100+30+30 instructions (210).
Now at the moment a receive interrupt occurs, you _at best_, assuming full speed comms, have two character times before the buffer will overfow. It is relatively easy to exceed this, with the example above, getting very close. If the RS232 receive routine itself, then adds a couple of tests before actually reading the character, the result will be an error.
First, try increasing the priority of the RS232 handler.
Second look again at the lengths of the handlers themselves. It may well be worth using the 'noclear' option on the RS232 handler, and clearing the interrupt as soon as the character has been read (rather than the default at the end of the routine), since this improves the ability to cope with the situation where a second character 'completes' before you have finished the handler for the first.
Third, make sure that you have 'errors' selected in the #use RS232 setup, since this will clear the error flag, and prevent the RS232 from hanging if data is not retrieved fast enough.
Best Wishes |
|
|
Guest
|
|
Posted: Wed Jun 16, 2004 4:08 am |
|
|
In order for us to help you we need more information.
What chip are you using?
Which compiler version?
When you say your RS-232 is not working, what do you mean with this? Is it working but stops after some time? Or don't you have any communication at all? Was your RS-232 working before you activated the INT0? etc.
Can you paste the relevant parts of your code? Including the #use rs232 statement. |
|
|
Guest
|
|
Posted: Wed Jun 16, 2004 10:04 am |
|
|
Thank you. The problem was the speed of processor
best regards
John |
|
|
|
|
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
|