Email: Password: Remember Me | Create Account (Free)

Back to Subject List

Old thread has been locked -- no new posts accepted in this thread
???
12/21/07 20:32
Read: times


 
#148603 - Isn't it too short?
Responding to: ???'s previous message
Oliver said:
The ADC ISR should just copy the ADC result sfrs to a variable and raise a flag to indicate that new data is ready.
The UART RI interrupt should copy the SBUF sfr to a variable and raise a flag.
2. The main loop checks the flags raised by the ISRs to decide what to do.

The ADC holds the result in the ADC SFRs until it finishes next conversion.
Also, the UART holds the received byte on SBUF until the end of next byte reception.
Then, is there any difference from direct polling of the ADC flag or RI in the main loop?

This implementation doesn't reduce the timing requirement for the main loop.
The main loop should round within the one byte period of the RS232.
Otherwise, the RX data will be lost.
The all tasks on the main loop cannot take more than the one byte period.

I recommend you to apply buffering on the firmware side.
Then the main loop tasks enjoy more execution time.

In the ADC ISR,
the ADC result is summed into a sum variable.
Also count up a counter.
When the counter reaches to a given value, say 16,
- copy the sum variable to a hold variable
- clear the sum variable
- raise a flag to show it to the main loop task.

In the UART ISR,
- The received byte is stored to a 16 bytes buffer, for example.
- The byte is stored in the current index on the buffer.
- Increment the index.
- When the received byte is the terminator character,
- Raise a flag to show it to the main loop.
In the main loop task,
- Handle the buffered data array.
- Clear the index. Drop the flag

I showed simple single buffer implementation here.
Depending on your protocol on RS232, you may need more elaborate buffering.
a) single buffer
b) double buffer - assign two buffers and use them in turn
c) cyclic buffer

Tsuneo

List of 34 messages in thread
TopicAuthorDate
Having problem on using interrupt            01/01/70 00:00      
   Answers            01/01/70 00:00      
      not so fast, Cristoph and to Ragu            01/01/70 00:00      
         Serial comm is slow.            01/01/70 00:00      
            if you read the OP            01/01/70 00:00      
               good interupts            01/01/70 00:00      
                  AAAAAARGH            01/01/70 00:00      
                     not AAAAAAAARGH            01/01/70 00:00      
                        OH YES            01/01/70 00:00      
                           do You ever avoid "non-debuggable"?            01/01/70 00:00      
                              always            01/01/70 00:00      
                                 nice            01/01/70 00:00      
                                    a trick for "long ISRs" better than a RTOS            01/01/70 00:00      
         Buffered RX            01/01/70 00:00      
            not much difference            01/01/70 00:00      
               You are right            01/01/70 00:00      
   Sucess with interrupts            01/01/70 00:00      
      Isn't it too short?            01/01/70 00:00      
         the reason for circular buffers            01/01/70 00:00      
            Worst case, instead of average            01/01/70 00:00      
               absolutely, just worst case is not as bad            01/01/70 00:00      
                  single, double and ring buffer            01/01/70 00:00      
                     single, double and ring buffer app dependent            01/01/70 00:00      
         and some more reasons to use (circular) buffers            01/01/70 00:00      
            buffer overflow error            01/01/70 00:00      
               Buffer overflow handling            01/01/70 00:00      
                  Buffering options            01/01/70 00:00      
                     Beauty contest !            01/01/70 00:00      
                        flexible is the best?            01/01/70 00:00      
                        Simplicity is always better            01/01/70 00:00      
                           simple is another word for            01/01/70 00:00      
                              Where is the borderline to stumble on            01/01/70 00:00      
                                 Copper Oxide            01/01/70 00:00      
               please exclude me from the 'we'            01/01/70 00:00      

Back to Subject List