 |
 |
| View previous topic :: View next topic |
| Author |
Message |
derfbor
Guest
|
| USART and interrupt |
 Posted: Mon Jan 24, 2005 7:34 am |
 |
|
Hello,
I am a french student, i am working on a project about RF transmission. The protocole is that when the pic receive a command it must respond just after it receive it. The duration of emmission and reception is fixed. The emitter send a trame (a command in 23 bytes) and just after decode the receiver send a response. When the uart receive a byte it store it and generate an interrupt.
My question is:
Must i decode the command in the UART ISR (decrypte each byte when it comes), is it correct? I think it is necessary because the receiver must response just after the reception of the command.
Did you have an other solution?
Thanks a lot. |
|
 |
Mark
Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA
|
|
| Posted: Mon Jan 24, 2005 8:18 am |
|
|
| Quote: | | Must i decode the command in the UART ISR |
Generally not but it depends especially since
| Quote: | I think it is necessary because the receiver must response just after the reception of the command.
|
"Just after the reception" is too general a parameter. What exactly does it mean? One nanosecond, microsecond, milisecond, second .... There is an overhead for processing the interrupt. Maybe this is too long to even meet your criteria. Typically you would set a flag and process in the main loop. The main loop could sit in a wait state waiting on data once a transmission begins. There could be a timeout so that the system wouldn't "hang" if some data was lost. This could keep the interrupt very short to avoid missing data (especially at high data rates). |
|
|
Guest
|
|
| Posted: Mon Jan 24, 2005 9:11 am |
|
|
| Mark wrote: | | Quote: | | Must i decode the command in the UART ISR |
Generally not but it depends especially since
| Quote: | I think it is necessary because the receiver must response just after the reception of the command.
|
"Just after the reception" is too general a parameter. What exactly does it mean? One nanosecond, microsecond, milisecond, second .... There is an overhead for processing the interrupt. Maybe this is too long to even meet your criteria. Typically you would set a flag and process in the main loop. The main loop could sit in a wait state waiting on data once a transmission begins. There could be a timeout so that the system wouldn't "hang" if some data was lost. This could keep the interrupt very short to avoid missing data (especially at high data rates). |
Yes, i anderstand but imagine that in the main loop we have a task that execute an action. This task is interrupted by ISR on byte receive. The isr execute itself, store the received byte, set the Flag and return to the task. If the Task is long (or if we don't how long is its duration), we can't say if we will have enougth time to decode the byte or the commande before the transmission. |
|
|
Mark
Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA
|
|
| Posted: Mon Jan 24, 2005 9:25 am |
|
|
1. You still haven't stated the maximum allowable time between the two events.
| Quote: | | If the Task is long (or if we don't how long is its duration) |
In all most all cases this duration can be determined (worst case time).
How long is the reception? Given enough time, the Main Loop could be waiting on this data once reception begins.
I am not saying this is how you should design your system but this is a possiblity. Your details are very sketchy so it is uncertain if this approach will work. It is up to you to decide. The simpliest solution would be to do it in the interrupt so maybe that is the course you should take. |
|
|
Guest
|
|
| Posted: Mon Jan 24, 2005 9:33 am |
|
|
| Mark wrote: | 1. You still haven't stated the maximum allowable time between the two events.
| Quote: | | If the Task is long (or if we don't how long is its duration) |
In all most all cases this duration can be determined (worst case time).
How long is the reception? Given enough time, the Main Loop could be waiting on this data once reception begins.
I am not saying this is how you should design your system but this is a possiblity. Your details are very sketchy so it is uncertain if this approach will work. It is up to you to decide. The simpliest solution would be to do it in the interrupt so maybe that is the course you should take. |
Ok, some details...
in an interval of 25 ms the system must receive a command and give an answer to it. For reception, the system has 9,5 ms and for answer idem, 9,5 ms.
First the system wait for incomming datas. when the first data arrives it has 9,5 ms second to decode the command and prepare an answer. A command has 23 bytes at 19200 bps. After this reception the system must begin to send the answer 1.5 ms after the 9,5 ms of the reception. |
|
|
Ttelmah
Guest
|
|
| Posted: Mon Jan 24, 2005 11:24 am |
|
|
| Anonymous wrote: | | Mark wrote: | 1. You still haven't stated the maximum allowable time between the two events.
| Quote: | | If the Task is long (or if we don't how long is its duration) |
In all most all cases this duration can be determined (worst case time).
How long is the reception? Given enough time, the Main Loop could be waiting on this data once reception begins.
I am not saying this is how you should design your system but this is a possiblity. Your details are very sketchy so it is uncertain if this approach will work. It is up to you to decide. The simpliest solution would be to do it in the interrupt so maybe that is the course you should take. |
Ok, some details...
in an interval of 25 ms the system must receive a command and give an answer to it. For reception, the system has 9,5 ms and for answer idem, 9,5 ms.
First the system wait for incomming datas. when the first data arrives it has 9,5 ms second to decode the command and prepare an answer. A command has 23 bytes at 19200 bps. After this reception the system must begin to send the answer 1.5 ms after the 9,5 ms of the reception. |
A typical way of giving fast responses, would be to have the system continuously updating the data to send, in a main loop, with an interrupt driven receive loop. This loop, 'walks' a search tree for the data required. As each character comes in, it checks on reception if it is valid, and advances a state machine counter if it is. Each reception only has to check against the possible characters in this position in the message, and can therefore be a short routine in the interrupt. When the last character is received, and matched, the response can be sent immediately. 1.5mSec, is ages in computer terms. I have a 18F252, that sits monitoring a serial bus, and responds to packets. Using the tree search, it's typical response time (at 40MHz), is just 25uSec after the packet is complete. This includes verifying the checksum, and formatting the output packet.
In 1.5mSec, you have plenty of time to do the response by simply checking the incoming message against a number of examples, and sending your reply. You don't even have to program particularly efficiently. Even at 4Mhz, you are talking 1500 instructions on the processor, while at 40MHz, the code could execute 15000 instructions in this time. So long as you avoid 'slow' routines in the output (things like floating point arithmetic use a lot of time), you can do a lot in this time.
Best Wishes |
|
|
Guest
|
|
| Posted: Tue Jan 25, 2005 2:37 am |
|
|
| Ttelmah wrote: | | Anonymous wrote: | | Mark wrote: | 1. You still haven't stated the maximum allowable time between the two events.
| Quote: | | If the Task is long (or if we don't how long is its duration) |
In all most all cases this duration can be determined (worst case time).
How long is the reception? Given enough time, the Main Loop could be waiting on this data once reception begins.
I am not saying this is how you should design your system but this is a possiblity. Your details are very sketchy so it is uncertain if this approach will work. It is up to you to decide. The simpliest solution would be to do it in the interrupt so maybe that is the course you should take. |
Thanks a lot.
Ok, some details...
in an interval of 25 ms the system must receive a command and give an answer to it. For reception, the system has 9,5 ms and for answer idem, 9,5 ms.
First the system wait for incomming datas. when the first data arrives it has 9,5 ms second to decode the command and prepare an answer. A command has 23 bytes at 19200 bps. After this reception the system must begin to send the answer 1.5 ms after the 9,5 ms of the reception. |
A typical way of giving fast responses, would be to have the system continuously updating the data to send, in a main loop, with an interrupt driven receive loop. This loop, 'walks' a search tree for the data required. As each character comes in, it checks on reception if it is valid, and advances a state machine counter if it is. Each reception only has to check against the possible characters in this position in the message, and can therefore be a short routine in the interrupt. When the last character is received, and matched, the response can be sent immediately. 1.5mSec, is ages in computer terms. I have a 18F252, that sits monitoring a serial bus, and responds to packets. Using the tree search, it's typical response time (at 40MHz), is just 25uSec after the packet is complete. This includes verifying the checksum, and formatting the output packet.
In 1.5mSec, you have plenty of time to do the response by simply checking the incoming message against a number of examples, and sending your reply. You don't even have to program particularly efficiently. Even at 4Mhz, you are talking 1500 instructions on the processor, while at 40MHz, the code could execute 15000 instructions in this time. So long as you avoid 'slow' routines in the output (things like floating point arithmetic use a lot of time), you can do a lot in this time.
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
