Searching \ for 'Concurrency Problem on a low power PIC 84' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/power.htm?key=power
Search entire site for: 'Concurrency Problem on a low power PIC 84'.

Truncated match.
PICList Thread
'Concurrency Problem on a low power PIC 84'
1996\11\06@021104 by Peter Homann

picon face
Hi,

I need to measure a continuous frequency between 0 - 250 cycles/MINUTE,
and transmit it via RS-232 at 2400 baud in a message containing 6 bytes
once 5 seconds.

The PIC I plan to use is the low power 84 variant, running at 32 KHz,
if possible.

The two separate requirements are easy to implement on their own, it's
getting the PIC to implement them concurrently that I'm having trouble
with. I need to continue measuring the input frequency even while I am
transmitting the output message.

I'd appreciate it if anybody who has solved this type of problem, can
give me a few pointers as this type of task, measure an input and
transmit it must be quite common.

With the PIC running at 32KHz, it is only operating at 8K instructions
per second. Transmitting at 2400 baud, there is time for only 7
instructions per bit.

I been tossing ideas around for a number of months now with no real
solution comming forward. I could use 2 Pics, one to do the counting,
the other to do the transmitting, but then I might as well use a
faster crystal.

Are there other alternatives? I may be blinkered down a set path.

Any input would be great. Code fragments would be fantastic.

Thanks guys,


Peter.
--
_______________________________________________________________________
Peter Homann   email: spam_OUTpeterhTakeThisOuTspamadacel.com.au       Work : +61 3 9596-2991
Adacel Pty Ltd                                   Fax  : +61 3 9596-2960
250 Bay St, Brighton 3186, VIC, AUSTRALIA      Mobile :     014 025-925

1996\11\06@034323 by Robert Lunn

flavicon
face
>I need to measure a continuous frequency between 0 - 250 cycles/MINUTE,
>and transmit it via RS-232 at 2400 baud in a message containing 6 bytes
>once 5 seconds.

       Peter, what's the six-byte message you send?

       (I want to get a handle on the processing required to
        create the message string.)

___Bob

1996\11\06@045042 by efoc

flavicon
face
Peter Homann wrote:
{Quote hidden}

Hi, I have been working on a system that counts pulses and pulse width
using the 84 .I use both the T0 clock and INT on portB0 to generate
ints.
If you set the ints up so that an int is generated on the rising edge of
portb0 and increment a counter every time an int is generated you can
count pulses. now if you also set the clock to generate an int at a set
duty cycle you can count the number of pulses on the portb0 pin within a
set time. all of this can be done in the background and due to the
nature of the ints it is also VERY presise.

I hope this is of some use

Peter........

1996\11\06@050535 by Robert Lunn

flavicon
face
>With the PIC running at 32KHz, it is only operating at 8K instructions
>per second. Transmitting at 2400 baud, there is time for only 7
>instructions per bit.

       Ah, isn't that 3.4 instructions per bit?

___Bob

1996\11\06@051156 by Robert Lunn

flavicon
face
>I need to measure a continuous frequency between 0 - 250 cycles/MINUTE,
>and transmit it via RS-232 at 2400 baud in a message containing 6 bytes
>once 5 seconds.
>
>The PIC I plan to use is the low power 84 variant, running at 32 KHz,
>if possible.

       Peter, you don't indicate the accuracy with which you need
       to measure the frequency...

       However, with a 32.768 kHz clock (which is 8192 instructions
       per second) a variation of one instruction in detecting the
       edge of a 250 rpm signal will cause an error in the calculated
       instantaneous frequency of 0.2 rpm.

       Assuming you don't want your measurement to be much less
       accurate than this, you must measure the edges of the input
       signal to within an instruction time.

       You can do this by setting up TMR0 as a free running timer
       with no prescale, configuring RB0 as an interrupt, and
       connecting your input signal to RB0.

       On each rising edge you get an interrupt, and in your ISR
       you capture TMR0.

       You must handle overflow of TMR0 in your main line code.

       You are now measuring your signal period, and thus your
       signal frequency, as accurately as it is possible.

       Ok, now to the output side of the equation...

       I can solve your problem if I can change your requirements :-)

       Use 300 baud instead of 2400 baud (which is barely possible
       anyway).

       At 300 baud you have just over 27 instructions per bit.  The
       ISR to capture TMR0 should be six instructions.  This interrupt
       can never occur more than once per character (indeed, can never
       occur more than once per six byte transmission).  Stretching
       a single bit time by 20% will _probably_ be ok...

       Don't forget to handle TMR0 overflow between each byte.

___Bob

1996\11\06@052653 by efoc

flavicon
face
Robert Lunn wrote:
>
> >I need to measure a continuous frequency between 0 - 250 cycles/MINUTE,
> >and transmit it via RS-232 at 2400 baud in a message containing 6 bytes
> >once 5 seconds.
>
>         Peter, what's the six-byte message you send?
>
>         (I want to get a handle on the processing required to
>          create the message string.)
>
> ___Bob

Bob, you could try setting up an array of say 6 bytes in memory
where the first would be an STX byte the next four would be the ascii of
the 4 digit number and the last being EOT so a value 123 would be
<stx><0><1><2><3><eot> or in hex 033031323304 this way the stx will
indicate the start of the numeric string and the eot the end. the
receiving equipment would be able to take the val of the four digits
using an ascii to int conversion. if the interupt code updates the bytes
of the output string then all you have to do is just keep sending it out
every 5 seconds or so.


Peter .......

1996\11\06@053311 by Robert Lunn

flavicon
face
>>I need to measure a continuous frequency between 0 - 250 cycles/MINUTE,
>>and transmit it via RS-232 at 2400 baud in a message containing 6 bytes
>>once 5 seconds.
>>
>>The PIC I plan to use is the low power 84 variant, running at 32 KHz,
>>if possible.
>
>        On each rising edge you get an interrupt, and in your ISR
>        you capture TMR0.
>
>        At 300 baud you have just over 27 instructions per bit.  The
>        ISR to capture TMR0 should be six instructions.

   I was a bit quite of the mark.  The ISR _is_ six instructions,
   but it executes in _seven_ cycles (because of the RETFI).  Also,
   there are two cycles spent getting into the ISR.

   That's a total of NINE cycles.

   This is a 30% error in bit timing.  At 300 baud I still think
   this will work (hopeful grin).  And because the bit timing is
   27.3 instructions rather than 27, you do make up a couple of
   cycles if the interrupt occurs early in the transmitted byte.

___Bob

1996\11\06@074519 by J. Cabral

flavicon
face
Amberdrew Ltd wrote:
{Quote hidden}

Peter Homann   email: peterhspamKILLspamadacel.com.au       Work : +61 3 9596-2991
{Quote hidden}

I think Peter solution is good. In order to improve it you program the
interrupt to be generated in the rising edge and during the int you put
a timer running and program the int for the complementary edge (if it
was up edge turns to down edge and vice-versa), you can get know
information about dutty-cycle and frequency and you can estimate the
frequency with more precision.

P.S. Sorry for the bad English!

-- Jorge.

1996\11\06@155253 by Bradley, Larry

flavicon
face
Don't know why you need to use 32 kHz --- likely to save power.

One thought. You need a higher clock  speed to transmit at 2400 baud. I
don't know if this would work, but you could have two external clocks
... one at 32 kHz and one at an appropriate higher rate for the 2400
baud stuff. Use a gate controlled by a pin on the PIC to switch clock
speeds to the higher one when you need to send the 6 bytes of data at
2400 baud, the switch back to the slower clock.

It would require some testing to see if the clock speed switch is
practicle or not.

Larry

{Quote hidden}

1996\11\06@165156 by Peter Homann

picon face
Robert Lunn wrote:
>
> >I need to measure a continuous frequency between 0 - 250 cycles/MINUTE,
> >and transmit it via RS-232 at 2400 baud in a message containing 6 bytes
> >once 5 seconds.
>
>         Peter, what's the six-byte message you send?
>
>         (I want to get a handle on the processing required to
>          create the message string.)

Bob,

Sorry, but there are only five bytes and are as follows;

Byte   Description
-----------------------------------------------------------------
 1    Start of Message ID    Constant
 2-3  Unit Identification    15 bits constant (1 bit battery low)
 4    Frequency Value        Variable
 5    Checksum               Variable

Sorry for the delay in answering, and thanks for your interest.

Regards,

Peter
--
_______________________________________________________________________
Peter Homann   email: EraseMEpeterhspam_OUTspamTakeThisOuTadacel.com.au       Work : +61 3 9596-2991
Adacel Pty Ltd                                   Fax  : +61 3 9596-2960
250 Bay St, Brighton 3186, VIC, AUSTRALIA      Mobile :     014 025-925

1996\11\06@170053 by Peter Homann

picon face
Robert Lunn wrote:
>
> >With the PIC running at 32KHz, it is only operating at 8K instructions
> >per second. Transmitting at 2400 baud, there is time for only 7
> >instructions per bit.
>
>         Ah, isn't that 3.4 instructions per bit?
>
> ___Bob

Yep, looks like the data rate will be slower, 1200 maybe.

Peter.
--
_______________________________________________________________________
Peter Homann   email: peterhspamspam_OUTadacel.com.au       Work : +61 3 9596-2991
Adacel Pty Ltd                                   Fax  : +61 3 9596-2960
250 Bay St, Brighton 3186, VIC, AUSTRALIA      Mobile :     014 025-925

1996\11\06@172107 by Peter Homann

picon face
Amberdrew Ltd wrote:
{Quote hidden}

I think the problem is that the output of serial data will be
corrupted by the interrupts.

Peter.
--
_______________________________________________________________________
Peter Homann   email: KILLspampeterhKILLspamspamadacel.com.au       Work : +61 3 9596-2991
Adacel Pty Ltd                                   Fax  : +61 3 9596-2960
250 Bay St, Brighton 3186, VIC, AUSTRALIA      Mobile :     014 025-925

1996\11\06@172311 by Peter Homann

picon face
Robert Lunn wrote:
>
> >I need to measure a continuous frequency between 0 - 250 cycles/MINUTE,
> >and transmit it via RS-232 at 2400 baud in a message containing 6 bytes
> >once 5 seconds.
> >
> >The PIC I plan to use is the low power 84 variant, running at 32 KHz,
> >if possible.
>
>         Peter, you don't indicate the accuracy with which you need
>         to measure the frequency...
Bob,

I only need an accuracy of +/- 0.5 cycles/minute.

Peter
--
_______________________________________________________________________
Peter Homann   email: RemoveMEpeterhTakeThisOuTspamadacel.com.au       Work : +61 3 9596-2991
Adacel Pty Ltd                                   Fax  : +61 3 9596-2960
250 Bay St, Brighton 3186, VIC, AUSTRALIA      Mobile :     014 025-925

1996\11\06@172314 by Peter Homann

picon face
Robert Lunn wrote:
>
> >I need to measure a continuous frequency between 0 - 250 cycles/MINUTE,
> >and transmit it via RS-232 at 2400 baud in a message containing 6 bytes
> >once 5 seconds.
> >
> >The PIC I plan to use is the low power 84 variant, running at 32 KHz,
> >if possible.
>
>         Peter, you don't indicate the accuracy with which you need
>         to measure the frequency...
>
>         However, with a 32.768 kHz clock (which is 8192 instructions
>         per second) a variation of one instruction in detecting the
>         edge of a 250 rpm signal will cause an error in the calculated
>         instantaneous frequency of 0.2 rpm.

+/- 0.5 rpm is fine.

{Quote hidden}

Seems a good solution so far.


>
>         Ok, now to the output side of the equation...
>
>         I can solve your problem if I can change your requirements :-)
>
>         Use 300 baud instead of 2400 baud (which is barely possible
>         anyway).

300 baud may be a bit slow, Ill have to check. 1200baud is preferred.
I want to use a 32KHz crystal because of its availability. Maybe I'll
have to use a faster one, so as to increase the baud rate. The reason
for the slow crystal is purely for power consumption reasons.


{Quote hidden}

Thanks again,

Peter.
--
_______________________________________________________________________
Peter Homann   email: spamBeGonepeterhspamBeGonespamadacel.com.au       Work : +61 3 9596-2991
Adacel Pty Ltd                                   Fax  : +61 3 9596-2960
250 Bay St, Brighton 3186, VIC, AUSTRALIA      Mobile :     014 025-925

1996\11\06@184552 by John Payson

picon face
> I need to measure a continuous frequency between 0 - 250 cycles/MINUTE,
> and transmit it via RS-232 at 2400 baud in a message containing 6 bytes
> once 5 seconds.
>
> The PIC I plan to use is the low power 84 variant, running at 32 KHz,
> if possible.

I'd suggest doing the following:

[1] Use the following variables:
       CurrTime        : 16-bit
       LastEvent       : 16-bit
       LastEvLatch     : 16-bit
       PrevEvent       : 16-bit
       NextOutput      : 16-bit

       NumCounts       : 8-bit
       NumCtLatch      : 8-bit
       PrevCounts      : 8-bit

[2] Every 1/256 second (note: the time from the start bit to the beginning
   of the stop bit is just under 1/256 sec at 2400 baud) do the following:

       CurrTime++;
       if (EventHappened)
       {
               LastEvent=CurrTime;
               NumCounts++;
       }
       if (--NextOutput)
       {
               NextOutput = 1560; /* 256*5 */
               LastEvLatch = LastEvent;
               NumCtLatch = NumCounts;
       }

[3] To initialize, set NextOutput to 1560 and everything else to zero.

[4] For the main loop, run this:


..gotta go--will finish later.

1996\11\06@231953 by Gerhard Fiedler

flavicon
face
At 09:02 07/11/96 +1100, Peter Homann wrote:
>I think the problem is that the output of serial data will be
>corrupted by the interrupts.

Didn't you say that you need to send only in quite big intervals? How about
stopping measuring while sending data, if there really is a timing problem?

1996\11\06@234734 by Peter Homann

picon face
Gerhard Fiedler wrote:
>
> At 09:02 07/11/96 +1100, Peter Homann wrote:
> >I think the problem is that the output of serial data will be
> >corrupted by the interrupts.
>
> Didn't you say that you need to send only in quite big intervals? How about
> stopping measuring while sending data, if there really is a timing problem?

Although I wish to initially  transmit approximately once every
five seconds, eventually I would like to speed it up. Otherwise I
could restart the measurement after the transmission has finished.

At 20 rpm the period is 3S. The worst case is when the pulse is
missed during transmission and the next pulse is not for another
3 seconds, then the next pulse is another 3 seconds a delay of
6 seconds before the frequency value is calculated.

If necessary I can live with this but its not ideal.

I plan to transmit the signal at a random interval, averaged at
once every 5 seconds. It would be nice to have the "Current"
value ready for when the transmission is required.

The reason for the random transmission is that there is more than one
unit transmitting. A poor mans ethernet with no collision detection
by the sender. If the receiver get a screwed message it ignores it
and picks up the value on the next transmission.



--
_______________________________________________________________________
Peter Homann   email: TakeThisOuTpeterhEraseMEspamspam_OUTadacel.com.au       Work : +61 3 9596-2991
Adacel Pty Ltd                                   Fax  : +61 3 9596-2960
250 Bay St, Brighton 3186, VIC, AUSTRALIA      Mobile :     014 025-925

1996\11\07@001811 by John Payson

picon face
> Although I wish to initially  transmit approximately once every
> five seconds, eventually I would like to speed it up. Otherwise I
> could restart the measurement after the transmission has finished.
>
> I plan to transmit the signal at a random interval, averaged at
> once every 5 seconds. It would be nice to have the "Current"
> value ready for when the transmission is required.
>
> The reason for the random transmission is that there is more than one
> unit transmitting. A poor mans ethernet with no collision detection
> by the sender. If the receiver get a screwed message it ignores it
> and picks up the value on the next transmission.

What would happen if you were to, after each input pulse, randomly decide
to output a packet [possibly with some random delay beforehand]?  If you
have observed the input frequency as 60bpm, you could wait up to about 800ms
after an input transition before sending your packet and still be done
in time for the next input; if your frequency is faster (e.g. 240bpm) you
can't wait as long but you have a better selection of pulses to trigger
on.

1996\11\07@001822 by John Payson

picon face
> I'd suggest doing the following:
>
[snip]

[256 times/second do this:]
{Quote hidden}

while(1)
{
 while(NumCtLatch == PrevCount)
   /* Wait... */ ;
 if (NumCtLatch-PrevCount < 5)
   output_number(15630 * (NumCtLatch-PrevCount) / (LastEvLatch-PrevEvent));
 else
  output_number(1920 * (NumCtLatch-PrevCount) / ((LastEvLatch-PrevEvent)/8)));
 PrevCount=NumCtLatch;
 PrevEvent=LastEvLatch;
}

1996\11\07@011321 by Peter Homann

picon face
Hi all,

I decided that I had better do a bit of investigation in my
problem. Below are some thoughts and a possible solution. All
comments are welcome. Be kind as this is my first cut at it.



Minimum rate = 20rpm
Max Rate = 250rpm


Therefore periods are:

       ---------------
       20rpm   250rpm
       ---------------
       3s              240ms
       ---------------


       Difference between 250 & 249 rpm

       60/249 - 60/250 = 0.96ms

       If we count over 5 beats then

       @ 20 rpm,  T = 15s
       @ 230 rpm, T = 1.2s

       Therefore I need to calculate the frequency over
       different number of Signal pulses depending on the frequency.

       When the count gets greater then  a particular value
       the frequency is then calculated.
--------------------------------------------------------
       Therefore use 1.953ms (32768/512) for timer increment so;
       @ 250rpm period is 60/250 = 240.00mS and @ 1.9531ms = 122.88 counts
       @ 249rpm period is 60/249 = 240.96mS and @ 1.9531ms = 123.37 counts

       At this rate we would need to count over at least 2 cycles.

At the minumum frequency.

       @ 20rpm period is 60/20 = 3.000S and = 1536 counts
       @ 21rpm period is 60/21 = 2.857S and = 1642 counts


       At this rate we could count over a single cycle.



Therefore we should be looking for about 300 counts.


Use of Interrupts
-----------------
Because the PIC is beign run of a 32KHz crystal, the CPU will not
need to utilise sleep modes as the current consumption is approx
65uA, therefore interrupts may not be needed as;

       o The bit banging can't be interrupted
       o If its time to send a message and we're calculating the
         signal frequency or something else, we can wait until we're
         finished. It doesn't matter that we're 1/2 sec late.
       o At 32KHz there are onky 8K instructions/sec. Overheads in
         processing the interrupts may be significant
       o Use the KISS principle whereever possible.




Message Transmission
--------------------

For 5 bytes, ie 50 bits (1 Start, 1 Stop, 8 Data)

At 1200 baud 50 / 1200 = 42ms


At 1200 baud 1 byte takes approx 5ms


If we don't get a Signal during the transmission then everything is
fine. If we do, we can't detect it until the byte is banged out as
there is not enough time during the transmission to check it.

Note: we may even be able to wait until the whole message has
been sent.  If the signal stays low for longer than 50ms we may
be able to guarantee it will still be low after the message is sent.
We could also use a flip-flop on the signal and then check
transitions in either direction. But this is more hardware and thus
more power and board real-estate.





Frequency Measurement
---------------------
To measure the frequency between 20 - 250 rpm the timer could
set up so as to overflow every 500ms. Whenever the Signal is detected,
the timer value is recorded. The period of the frequency is the
absolute difference between the timer value for a number of pulses. If
the absolute value is too small to get an accurate frequency
calculation, we can just wait for the next pulse, using the
totalled period duration.

We can also "defer" the frequency calculation if we are busy doing
other things, ie bit banging out the serial message.

The PIC 16C84  has an 8 bit timer(I think) with a prescaler.
Therefore, if we overflow at 0.5 second, we get a resolution of
just under 2 ms (1.9531ms).



Example
-------------
If we use 1.9531ms timer increments we get
       512 counts /sec
or
       30720 counts/minute



Using a bit of scaled arithmetic;

freq = 1/Period


Freq = 30720/count

for more accuracy use 30720 * 2 = 61440

Therefore the frequency is

F = ((61440 / count ) * number_of_Signals) / 2)

Example:

for a frequency of say 220 rpm over 3 pulses.

Period for 3 pulses is .818s

Count  = 0.818/.001953 = 418

Freq = ((61440/418) * 3 ) / 2

        = 219 rpm



BEGIN Main
. CALL Reset_Signal_Timing
. WHILE forever
. . CALL Check_Signal
. . CALL Check_Timer_Overflow
. . CALL Check_Transmission
. ENDWHILE
END Main


BEGIN Reset_Signal_Timing
. Set the present_count to 0
. Set the last_time_count to 0
. Set the number_of_Signals to 0
. Set the overflow_count to 0
. Set Timing_In_Progress to FALSE
END Reset_Signal_Timing



BEGIN Check_Signal
. IF Signal line has Hi to Lo transition
. . Set the present_count to the current counter value
. . Increment the number_of_Signals received
. . Set Timing_In_Progress to TRUE
. . CALL Calculate_Frequency
. ENDIF
END Check_Signal


BEGIN Calculate_Frequency
. Calculate the absolute interval
. IF the interval  > MIN_PERIOD
. . IF the interval < MAX_PERIOD
. . . Calculate Temp = ???? / interval
. . . Calculate Frequency = Temp/Number_of_Signals
. . . Set the number_of_Signals received to zero
. . . Set the last_time_count to the present_count value
. . . Set the overflow_count to 0
. . ELSE
. . . CALL Reset_Signal_Timing
. . ENDIF
. ENDIF
END Calculate_Frequency





BEGIN Check_Timer_Overflow
. IF the timer has over flowed
. . IF overflow_count > MAX_OVERFLOW_COUNT
. . . CALL Reset_Signal_Timing
. . ELSE
. . . Increment the overflow_count
. . END
. END
END Check_Timer_Overflow


BEGIN Check_Transmission
. IF it is time to transmit
. . FOR x = 1 to 5
. . . Bit bang out byte(x)
. . . IF Signal line has Hi to Lo transition
. . . . Increment number_of_Signals received
. . . ENDIF
. . ENDFOR
. . IF the counter has overflowed
. . . Increment overflow_count
. . ENDIF
. . Calculate the next transmission time
. ENDIF
END Check_Transmission






--
_______________________________________________________________________
Peter Homann   email: RemoveMEpeterhspamTakeThisOuTadacel.com.au       Work : +61 3 9596-2991
Adacel Pty Ltd                                   Fax  : +61 3 9596-2960
250 Bay St, Brighton 3186, VIC, AUSTRALIA      Mobile :     014 025-925

1996\11\07@015918 by Peter Homann

picon face
John Payson wrote:
{Quote hidden}

John,

Yes it is possible. I'm not sure that a pattern may develop because
the randomised interval may be less. I'll need to think about it. My
original concept was to have the current frequency alway available,
and the transmission part would just use that latest value when it
needed to transmit the message.

Thanks for your input. I look forward to tomorrows replys. I'm off
now and will think about the problem further.

Thanks again.



Peter.
--
_______________________________________________________________________
Peter Homann   email: peterhEraseMEspam.....adacel.com.au       Work : +61 3 9596-2991
Adacel Pty Ltd                                   Fax  : +61 3 9596-2960
250 Bay St, Brighton 3186, VIC, AUSTRALIA      Mobile :     014 025-925

1996\11\07@065643 by Keith Dowsett

flavicon
face
{Quote hidden}

Hmm. A six byte message at 1200 baud takes 0.05 seconds. At 250 rpm the
input pulses arrive every 0.3 seconds. So there's enough time between pulses
to send multiple messages if necessary.

Providing your transmit routine waits until just after a pulse (or counter
overflow when there's no input) it should have hardly any problems with
packets corrupted by interrupt servicing routines, in fact you should
probably disable the interrupt for 100mS after each pulse.

Disabling the interrupt allows for the situation where the flag is
stationary on the edges of the sensor and produces anomolously high
readings. These noise readings appear as 600 rpm and can be filtered out
(binned).

Just a few thoughts,

Keith.
==========================================================
Keith Dowsett         "Variables won't; constants aren't."

E-mail: EraseMEkdowsettspamrpms.ac.uk
WWW:    http://kd.rpms.ac.uk/index.html

1996\11\07@070443 by Gerhard Fiedler

flavicon
face
At 17:11 07/11/96 +1100, Peter Homann wrote:
>Therefore periods are:
>        ---------------
>        20rpm   250rpm
>        ---------------
>        3s              240ms
>        ---------------
>
>For 5 bytes, ie 50 bits (1 Start, 1 Stop, 8 Data)
>At 1200 baud 50 / 1200 = 42ms

This sounds as if you could pretty easyly assure that your transmission does
not interfere with your impulses.

1996\11\07@220253 by Matthew Mucker

flavicon
face
>Gerhard Fiedler wrote:
>> Didn't you say that you need to send only in quite big intervals? How about
>> stopping measuring while sending data, if there really is a timing problem?
>
>Although I wish to initially  transmit approximately once every
>five seconds, eventually I would like to speed it up. Otherwise I
>could restart the measurement after the transmission has finished.
>

As others have mentioned, it seems that the best solution is to send the
data immediately after receiving an input pulse.  It has already been
demonstrated that if you use this technique under the operating conditions
you have described, you will not miss and input pulses.

I don't know how long the 'data conversion' steps take, but it is likely
you could wait for an input pulse, do your calculations, and send the data
before another input pulse arrives.

Or am I missing something?  Also, you're guaranteed to have one measurement
at least every three seconds, according to your operating conditions.

-Matt


 "DOS Computers manufactured by companies such as IBM, Compaq, Tandy, and
millions of others are by far the most popular, with about 70 million
machines in use wordwide. Macintosh fans, on the other hand, may note that
cockroaches are far more numerous than humans, and that numbers alone do
not denote a higher life form."

1996\11\21@161951 by Norm LeMieux

picon face
    Hey, gang. I'm not sure where this thread has lead since I'm still a
    week or so behind on my digests, but...

    The 16F84-04/P through DigiKey is $6.48 in singles and $4.31 in 100s,
    while the 16C62A-04/SP is $5.35 in singles and $3.56 in 100s. This
    indicates that the '62A is cheaper than the '84 (your mileage may
    vary), even though the former is in a skinney 28 rather than the 18
    pin pkg.

    This is significant in that the '62A HAS one CCP module that you can
    capture the input waveform with WHILE you are bit-banging out the
    other end. You can use TMR0 for the baud-rate generator to interrupt
    you at the next bit time, and the CCP will interrupt you after the
    capture has occured.

    Checking two interrupt sources should not give too much of an
    erroneous bit time at 1200/2400 baud, and leaving TMR2 can be used for
    baud-rate generation using the period register for continuous
    constant-period bit-time interrupts.

    However, if you HAVE an '84 and you're just trying to use IT, then
    that is another story. If you're trying to do the most efficient job,
    though, I'd recommend the '62A.

    Norm LeMieux
    MCHIP FAE/NW

More... (looser matching)
- Last day of these posts
- In 1996 , 1997 only
- Today
- New search...