Using a prescaler reduces accuracy but would let you count at a higher 
frequency. Using a 8bit timer instead of a 16 bit timer is more accurate.

Sent from my iPhone

> On Jul 7, 2016, at 5:13 PM, 'Oliver Seitz' via jallib 
> <[email protected]> wrote:
> 
> Just had a look at the datasheet: 16f628 really can count 50MHz on TMR0 when 
> using the prescaler. 12f1572 can not, perhaps due to reduced power ratings.
> 
> Greets,
> Kiste
> --------------------------------------------
> 'Oliver Seitz' via jallib <[email protected]> schrieb am Do, 7.7.2016:
> 
> Betreff: AW: Re: [jallib] Freq Counter? [SOLVED+CODE]
> An: "[email protected]" <[email protected]>
> Datum: Donnerstag, 7. Juli, 2016 15:58 Uhr
> 
> That example is quite
> similar to what I proposed, just that the frequency is
> counted in TMR0, and the gate time is provided by a kind of
> delay loop. 
> If
> you count the frequency in TMR1 and use TMR0 for the gate
> time, this can easily be done in pure JAL.
> Greets,Kiste
> 
> Gesendet
> von Yahoo Mail auf Android 
> 
>   Am Do., 7.
> Juli 2016 um 14:45 hat Vasile
> Surducan<[email protected]> Folgendes
> geschrieben:   Hi Oliver, thx!
> I meant coding in pure assembler cod when
> talking about counting 50MHz.
> Of
> course I don't want in this way...
> Se here: http://www.qsl.net/dl4yhf/freq_counter/freq_counter.html
> 
> On the other hand
> the timing must be generated inside the pic, INTOSC has
> enough accuracy for my application.
> 
> thanks again guys!
> Vasile
> 
> On Thu, Jul 7, 2016 at
> 10:59 AM, 'Oliver Seitz' via jallib <[email protected]>
> wrote:
> Hi
> Vasile!
> 
> 
> 
> T1G stands for "Timer One Gate", and it can be
> used to measure low frequencies within one cycle of the
> frequency to measure. It is no good for counting high
> frequencies. You need to use T1CKI pin for that purpose.
> That pin can count 16MHz on the 12F1572 or 32MHz if you use
> the prescaler. These values are independent from the core
> frequency and result from the AC caracteristics (in my
> datasheet "TABLE 26-12: TIMER0 AND TIMER1 EXTERNAL
> CLOCK REQUIREMENTS"). The reference clock can be
> generated internally by TMR0 if the accuracy of the internal
> oscillator is enough. You can even set up TMR0 to control
> T1G to start and stop counting on TMR1, so your main program
> would only set things up and wait for TMR0 to overflow
> twice. Then TMR1 will have counted for a certain time solely
> determined by independent peripherals without any influence
> of the processor core.
> 
> 
> 
> This chip can in no way count 50MHz without external
> prescaler.
> 
> 
> 
> Greets,
> 
> Kiste
> 
> --------------------------------------------
> 
> Vasile Surducan <[email protected]> schrieb am Do,
> 7.7.2016:
> 
> 
> 
>  Betreff: Re: [jallib] Freq Counter? [SOLVED+CODE]
> 
>  An: [email protected]
> 
>  Datum: Donnerstag, 7. Juli, 2016 09:33 Uhr
> 
> 
> 
>  Hi Matt,
> 
> 
> 
>  Your code looks great,
> 
>  however I need to generate the time base inside the
> PIC.
> 
>  I will start testing after I'll
> 
>  finish the PCBs...
> 
>  In assembler it
> 
>  could be done up to 50MHz on any PIC running at 4MHz.
> 
>  The problem is I want to write it with
> 
>  the compiler...:) so perhaps with INTOSC at 32MHz (looks
> it
> 
>  should work) I will be able to measure up to 3MHz.
> 
> 
> 
>  thanks for the
> 
>  sample!
> 
> 
> 
>  On Thu, Jul 7, 2016 at 4:03
> 
>  AM, Matt Schinkel <[email protected]>
> 
>  wrote:
> 
>  From the looks of
> 
>  it T1G is just a trigger for the
> 
>  counter/timer. This is similar to what my sample
> 
>  does.
> 
>  Not sure
> 
>  if you can run a 2nd timer instead of using an external
> 1hz
> 
>  signal. I just figured a 1hz signal would make my
> sample
> 
>  fairly accurate.
> 
>  The
> 
>  other sample of mine uses the osc in pin as the signal
> 
>  input. It can measure a frequency equivalent to the max
> pic
> 
>  osc frequency. So on 18f67j50, i could measure up to
> 64mhz.
> 
>  This one would require the 1hz input for sure.
> 
>  Matt.
> 
>  On Jul 6,
> 
>  2016, at 12:27 PM, vasile <[email protected]>
> 
>  wrote:
> 
> 
> 
>  Hi Pavel,So, in the
> 
>  final version of your code, still need
> 
>  compensation?
> 
>  I need
> 
>  to measure a frequency up to 3MHz. I'm using a new
> 
>  generation PIC with T1G (PIC12F1572).I found some
> 
>  Microchip application note for measuring pulse duration
> but
> 
>  not for frequency measurement using T1G input.I
> 
>  saw also Matt frequency counter at github, but that one
> need
> 
>  an external 1Hz reference signal. 
> 
>  Anyone tried the newer PICs for
> 
>  frequency measuremets?
> 
>  thank you all,Vasile
> 
> 
> 
>  On Thursday, August 8, 2013 at
> 
>  5:02:39 AM UTC+3, Ing. Pavel Milanes Costa wrote:Hi all...
> as I promised this is the
> 
>  code...
> 
> 
> 
> 
> 
> 
> 
>  This is a home project so code is GPL...
> 
>  see comments...
> 
> 
> 
> 
> 
> 
> 
>  The hardware can and must be adjusted by
> 
>  serial port, see comments on
> 
> 
> 
>  the header of the file...
> 
> 
> 
> 
> 
> 
> 
>  This code "as is" can count up to
> 
>  5Mhz (in a proteus/isis simulation can
> 
> 
> 
>  reach to about 12 Mhz, but 5Mhz as clock/4
> 
>  is the max safe value...)
> 
> 
> 
> 
> 
> 
> 
>  on +5v RB3 the internal code will *8 the
> 
>  input freq
> 
> 
> 
>  on +5v RB4 the internal code will *64 the
> 
>  input freq
> 
> 
> 
>  both RB3 and RB4 at +5v will *8*64 the
> 
>  input freq
> 
> 
> 
> 
> 
> 
> 
>  This ARE NOT push buttons, this is TTL
> 
>  levels
> 
> 
> 
> 
> 
> 
> 
>  This is as you may guessed by now for
> 
>  prescaling purposes
> 
> 
> 
> 
> 
> 
> 
>  Feel free to make any
> 
>  comments/suggestions/critics/etc...
> 
> 
> 
> 
> 
> 
> 
>  On the next weeks I will build it for real
> 
>  (no more proteus/isis
> 
> 
> 
>  simulations) and will comment the results
> 
>  to the list.
> 
> 
> 
> 
> 
> 
> 
>  This is my first complex code that will be
> 
>  burned to a "production" pic,
> 
> 
> 
>  so I'm very excited about it.
> 
> 
> 
> 
> 
> 
> 
>  Cheers to all and thanks to all who give me
> 
>  ideas and tips about this...
> 
> 
> 
> 
> 
> 
> 
>  Again: sorry any misspelling/typo/grammar
> 
>  etc... I'm a native Spanish
> 
> 
> 
>  speaking person, I'm trying to do my
> 
>  best at English...
> 
> 
> 
> 
> 
> 
> 
>  El 03/08/13 11:05, Ing. Pavel Milanes Costa
> 
>  escribi�:
> 
> 
> 
>  > Hey!!! ... this way works 130% (thanks
> 
>  Oliver Seitz)
> 
> 
> 
>  >
> 
> 
> 
>  > I explain:
> 
> 
> 
>  >
> 
> 
> 
>  > I use a PIC16F88, I set the isr
> 
>  routine for 1ms interrupt and counting
> 
> 
> 
>  > for 500ms, this is TMR0...
> 
> 
> 
>  >
> 
> 
> 
>  > TMR1 is in pulse counter with
> 
>  prescaler 1:1, on overflow the interrupt
> 
> 
> 
>  > of TM1 increment a internal counter as
> 
>  a way of internal postcaler
> 
> 
> 
>  >
> 
> 
> 
>  > Each 500ms the TMR1 and his internal
> 
>  postcaler is read & cleared.
> 
> 
> 
>  >
> 
> 
> 
>  > Then the freq is computed, with a
> 
>  trick...
> 
> 
> 
>  >
> 
> 
> 
>  > The pic is running XTAL at 20Mhz, so
> 
>  XTAL/4 is 5 Mhz (maximum freq to
> 
> 
> 
>  > measure), that is 5000000 pulses per
> 
>  seconds or 2500000 each 1/2 sec. or
> 
> 
> 
>  > 38 * postcaler + remaining pulses...
> 
>  so postcaler is a byte var...
> 
> 
> 
>  >
> 
> 
> 
>  > But the ISR of TMR0 & TMR1 puts a
> 
>  delay on the reading that depends on
> 
> 
> 
>  > the things the pic is doing in each
> 
>  cycle of the forever loop.
> 
> 
> 
>  >
> 
> 
> 
>  > I adjust the delay as a percent of
> 
>  useful time on each postcaler cycle,
> 
> 
> 
>  > feeding the pic with almost full count
> 
>  before postcaler get incremented
> 
> 
> 
>  > and get by serial port the internal
> 
>  count, as I knows the freq I can say
> 
> 
> 
>  > how much pulses has to count for exact
> 
>  and how much pulses are the pic
> 
> 
> 
>  > counting...
> 
> 
> 
>  >
> 
> 
> 
>  > For my experimentation the percent of
> 
>  adjust if in the order of 99%
> 
> 
> 
>  > (99.0298891% of the pic reading in my
> 
>  last calibration) and of course
> 
> 
> 
>  > this correction factor must be scaled
> 
>  to every postcaler count, normally
> 
> 
> 
>  > a postcaler count will be poscaller *
> 
>  65536, but to adjust I compute
> 
> 
> 
>  > 65536 * 99.0298891%  so.
> 
> 
> 
>  >
> 
> 
> 
>  > Freq = poscaler * (65536 *
> 
>  99.0298891%)
> 
> 
> 
>  > Freq = Freq + (pulses * 99.0298891%)
> 
> 
> 
>  >
> 
> 
> 
>  > As we want an accurate reading, we
> 
>  have to work wit decimal shifting the
> 
> 
> 
>  > decimal point and div then, so
> 
> 
> 
>  >
> 
> 
> 
>  > Corr_postcaler_pulses = (65536 *
> 
>  99029) /100000 -- this is a constant
> 
> 
> 
>  > Corr_pulses = (pulses * 9903) / 10000
> 
> 
> 
>  > Freq = (postcaler *
> 
>  Corr_postcaler_pulses) + Corr_pulses
> 
> 
> 
>  >
> 
> 
> 
>  > And as I'm reading 1/2 sec
> 
> 
> 
>  >
> 
> 
> 
>  > Freq = Freq * 2
> 
> 
> 
>  >
> 
> 
> 
>  > This give me an accuracy of about +/-
> 
>  10 Hz at 5Mhz (4.99M) in the
> 
> 
> 
>  > proteus simulation, I know that the
> 
>  stability of the 20Mhz XTAL and the
> 
> 
> 
>  > source under measure will mask this
> 
>  error, but nevertheless this is GOOD
> 
> 
> 
>  > accuracy..
> 
> 
> 
>  >
> 
> 
> 
>  > This is the best method I have tried
> 
>  and the freq_meter is in his 4.0
> 
> 
> 
>  > version (aka 4th method)
> 
> 
> 
>  >
> 
> 
> 
>  > Then with a external prescaler of 8
> 
>  (5Mhz * 8) I can count up to 40
> 
> 
> 
>  > Mhz... the external prescaler can be a
> 
>  pair of 74hc74 (3 half in 3 bit
> 
> 
> 
>  > count = /8  this can work up to 60-80
> 
>  Mhz range)
> 
> 
> 
>  >
> 
> 
> 
>  > Here I can find a 250 Mhz /64 &
> 
>  /65 prescalers as well as 1Ghz /2 & /4 &
> 
> 
> 
>  > /8 external prescaler,
> 
> 
> 
>  >
> 
> 
> 
>  > So, I can make it with 5 scales
> 
> 
> 
>  >
> 
> 
> 
>  > 1Ghz    (/8 + /64 = out max 1.9Mhz,
> 
>  error max ~10Khz)
> 
> 
> 
>  > 250Mhz    (/64 = out max 3.9Mhz,
> 
>  error max ~1.2Khz)
> 
> 
> 
>  > 40Mhz    (/8 = out max 5.0Mhz, error
> 
>  max ~150hz)
> 
> 
> 
>  > 5Mhz    (direct, error max ~20hz)
> 
> 
> 
>  > 500Khz    (direct, error max ~2hz)
> 
> 
> 
>  >
> 
> 
> 
>  > The core counting engine is working,
> 
>  I'm working on the lcd output
> 
> 
> 
>  > formatting, external prescaling &
> 
>  serial interface to externally adjust
> 
> 
> 
>  > for freq compensation via serial on
> 
>  the final hardware.
> 
> 
> 
>  >
> 
> 
> 
>  > I'm thinking also in a
> 
>  abbreviated/full display option kind of
> 
> 
> 
>  >
> 
> 
> 
>  > 145.170051 Mhz => 145.170 Mhz
> 
> 
> 
>  >   51.110402 Mhz =>  51.1104 Mhz
> 
> 
> 
>  >
> 
> 
> 
>  > For "masking" the error when
> 
>  full accuracy is not needed
> 
> 
> 
>  >
> 
> 
> 
>  > And even a averaging of the last n
> 
>  readings for stable display numbers
> 
> 
> 
>  > and accurate readings on > 100 Mhz
> 
>  freqs when the error gets bigger
> 
> 
> 
>  >
> 
> 
> 
>  > When I have a working piece of this
> 
>  functions I will post the example to
> 
> 
> 
>  > the list.
> 
> 
> 
>  >
> 
> 
> 
>  > Thanks to all for the ideas and
> 
>  tips...
> 
> 
> 
>  >
> 
> 
> 
>  > Cheers.
> 
> 
> 
>  >
> 
> 
> 
>  > El 31/07/13 09:50, Oliver Seitz
> 
>  escribi�:
> 
> 
> 
>  >> My way would be:
> 
> 
> 
>  >>
> 
> 
> 
>  >> On overflow, increment an
> 
>  additional upper counter, and just leave the
> 
> 
> 
>  >> timer running until the time has
> 
>  passed. You can use variables as big as
> 
> 
> 
>  >> you want in JAL. So there's no
> 
>  need for prescalers, as long as the timer
> 
> 
> 
>  >> can keep up with the external
> 
>  frequency.
> 
> 
> 
>  >>
> 
> 
> 
>  >> On 18F26K22 chips, for example, in
> 
>  asyncronous mode, the timers can
> 
> 
> 
>  >> count 16MHz. Counting one second,
> 
>  the timer could overflow
> 
> 
> 
>  >> (16000000/65536=) 244 times, so
> 
>  only an additional one-byte variable is
> 
> 
> 
>  >> needed to count that frequency
> 
>  with 1Hz resolution.
> 
> 
> 
>  >>
> 
> 
> 
>  >> To count hundreds of MHz, you need
> 
>  to start with a high setting on the
> 
> 
> 
>  >> external prescaler, for you
> 
>  can't know if the frequency is too high for
> 
> 
> 
>  >> the timer and it might miss pulses
> 
>  then.
> 
> 
> 
>  >>
> 
> 
> 
>  >> A microcontroller can easily do
> 
>  thousands of interrupts per second
> 
> 
> 
>  >> without "going crazy",
> 
>  don't worry. I've had programs where interrupts
> 
> 
> 
>  >> occured only a few microseconds
> 
>  after another. This was on 64MHz, though.
> 
> 
> 
>  >>
> 
> 
> 
>  >> Greets,
> 
> 
> 
>  >> Kiste
> 
> 
> 
>  >>
> 
> 
> 
>  >>
> 
> 
> 
>  >>
> 
>  ------------------------------------------------------------------------
> 
> 
> 
>  >>     *Von:* Ing. Pavel Milanes
> 
>  Costa <[email protected]>
> 
> 
> 
>  >>     *An:* [email protected]
> 
> 
> 
>  >>     *Gesendet:* 14:46 Mittwoch,
> 
>  31.Juli 2013
> 
> 
> 
>  >>     *Betreff:* Re: [jallib] Freq
> 
>  Counter? + break a _usec_delay()
> 
> 
> 
>  >>     instruction?
> 
> 
> 
>  >>
> 
> 
> 
>  >>     Hi to all...
> 
> 
> 
>  >>
> 
> 
> 
>  >>     Last night I was thinking on
> 
>  the bed before sleep... I think there is
> 
> 
> 
>  >>     another more elegant KISS
> 
>  solution...
> 
> 
> 
>  >>
> 
> 
> 
>  >>     On overflow, STOP the
> 
>  counting (unset TMR1ON), and then stop the
> 
> 
> 
>  >>     counting and the overflow
> 
>  process...
> 
> 
> 
>  >>
> 
> 
> 
>  >>     As simple as that...
> 
> 
> 
>  >>
> 
> 
> 
>  >>     I will try it in the
> 
>  afternoon, I will update to all about the
> 
> 
> 
>  >> progress
> 
> 
> 
>  >>     of this instrument...
> 
> 
> 
>  >>
> 
> 
> 
>  >>     Cheers...
> 
> 
> 
>  >>
> 
> 
> 
>  >>
> 
> 
> 
>  >>     El 30/07/13 23:44, Ing.
> 
>  Pavel Milanes Costa escribi�:
> 
> 
> 
>  >>      > Hi all again.
> 
> 
> 
>  >>      >
> 
> 
> 
>  >>      > With your ideas and
> 
>  code I'm writing a frequency meter.
> 
> 
> 
>  >>      >
> 
> 
> 
>  >>      >  From 0hz to 280 Mhz
> 
>  using various "prescalers" in conjunction
> 
> 
> 
>  >>     (variable
> 
> 
> 
>  >>      > time of sampling +
> 
>  internal prescaler of TM1 + external
> 
> 
> 
>  >> prescalers)
> 
> 
> 
>  >>      >
> 
> 
> 
>  >>      > The most interesting
> 
>  features is that it "will have" an "auto
> 
> 
> 
>  >> scale"
> 
> 
> 
>  >>      > feature, for make
> 
>  readings with the more exact method for the
> 
> 
> 
>  >>     freq being
> 
> 
> 
>  >>      > measured (aka.
> 
>  minimizing the error for that freq)
> 
> 
> 
>  >>      >
> 
> 
> 
>  >>      > But... (as always) I
> 
>  have a problem...
> 
> 
> 
>  >>      >
> 
> 
> 
>  >>      > I need to BREAK the
> 
>  counting of a running _usec_delay()
> 
> 
> 
>  >>     instruction from
> 
> 
> 
>  >>      > a interrupt
> 
>  routine...
> 
> 
> 
>  >>      >
> 
> 
> 
>  >>      > I explain (code
> 
>  attached):
> 
> 
> 
>  >>      >
> 
> 
> 
>  >>      > I start counting TMR1
> 
>  pulses on RB6 for 1 sec time lapse, and with
> 
> 
> 
>  >>      > interrupts on the
> 
>  overflow of it I detect the need of jump on the
> 
> 
> 
>  >>     "range
> 
> 
> 
>  >>      > / scale", then I
> 
>  change any of the sampling period, internal
> 
> 
> 
>  >>     prescaler
> 
> 
> 
>  >>      > and/or external
> 
>  prescaler to suit the next scale and then you
> 
> 
> 
>  >> have a
> 
> 
> 
>  >>      > autorange freq.
> 
>  meter...
> 
> 
> 
>  >>      >
> 
> 
> 
>  >>      > The problem is found
> 
>  when I measure a freq that is much BIGGER
> 
> 
> 
>  >>     for the
> 
> 
> 
>  >>      > initial sampling
> 
>  period of 1s...
> 
> 
> 
>  >>      >
> 
> 
> 
>  >>      > Think on it and dive
> 
>  in the code....
> 
> 
> 
>  >>      >
> 
> 
> 
>  >>      > 7110khz (7110000
> 
>  pulses in ONE second) is around 108 interrupts
> 
> 
> 
>  >>     in ONE
> 
> 
> 
>  >>      > second... so the
> 
>  autorange function goes crazy and get to the
> 
> 
> 
>  >> top of
> 
> 
> 
>  >>      > scale from overloaded
> 
>  interrupts per seconds...
> 
> 
> 
>  >>      >
> 
> 
> 
>  >>      > The obvious solution
> 
>  is breaking the _usec_delay() instruction
> 
> 
> 
>  >>     from the
> 
> 
> 
>  >>      > interrupt routine...
> 
>  that will require asm which I do not
> 
> 
> 
>  >> know... or
> 
> 
> 
>  >>      > another dirty
> 
>  trick...
> 
> 
> 
>  >>      >
> 
> 
> 
>  >>      > But, Hey!... I
> 
>  realize NOW that using another timer for setting
> 
> 
> 
>  >> the
> 
> 
> 
>  >>      > sampling period can
> 
>  be the solution... (GGGGGRRRRR somebody
> 
> 
> 
>  >>     suggest this
> 
> 
> 
>  >>      > before and I have not
> 
>  listen to it...)
> 
> 
> 
>  >>      >
> 
> 
> 
>  >>      > Yes, forcing the
> 
>  timer of the sampling period to timeout an
> 
> 
> 
>  >> thereof
> 
> 
> 
>  >>      > ending the sampling
> 
>  period will be the way...
> 
> 
> 
>  >>      >
> 
> 
> 
>  >>      > I will try that
> 
>  tomorrow, nevertheless, the code is attached,
> 
> 
> 
>  >>     comments,
> 
> 
> 
>  >>      > suggestions, etc,
> 
>  will be welcomed...
> 
> 
> 
>  >>      >
> 
> 
> 
>  >>      > I have the proteus
> 
>  project if anyone like to try it...
> 
> 
> 
>  >>      >
> 
> 
> 
>  >>      > Just ignore the lcd
> 
>  for now and attach a serial console at 38_400
> 
> 
> 
>  >>     bauds
> 
> 
> 
>  >>      > to the PIC and see
> 
>  the debug info...
> 
> 
> 
>  >>      >
> 
> 
> 
>  >>      > The code is a work in
> 
>  progress, no optimization or cleaning yet...
> 
> 
> 
>  >>      >
> 
> 
> 
>  >>      > Cheers... and enjoy
> 
>  it
> 
> 
> 
>  >>      >
> 
> 
> 
>  >>      > PS: Forgive my
> 
>  english if you found an error or two, I'm a spanish
> 
> 
> 
>  >>      > speaking person...
> 
> 
> 
>  >>      >
> 
> 
> 
>  >>      > El 27/07/13 22:41,
> 
>  Ing. Pavel Milanes Costa escribi�:
> 
> 
> 
>  >>      >> Hi all.
> 
> 
> 
>  >>      >>
> 
> 
> 
>  >>      >> I'm here
> 
>  reading and searching but I can't find a way of
> counting
> 
> 
> 
>  >>      >> asynchronous TTL
> 
>  pulses with jal/jallib over a given time slot...
> 
> 
> 
>  >>      >>
> 
> 
> 
>  >>      >> It must be done
> 
>  with the timer module of the pic... (I think...)
> 
> 
> 
>  >>      >>
> 
> 
> 
>  >>      >> I explain:
> 
> 
> 
>  >>      >>
> 
> 
> 
>  >>      >> I want to make a
> 
>  frequency counter for zero to 250 Mhz, with 2
> 
> 
> 
>  >>     external
> 
> 
> 
>  >>      >> prescaler, using
> 
>  direct counting for low freq's, med prescaler
> 
> 
> 
>  >>     to about
> 
> 
> 
>  >>      >> 50 Mhz and a
> 
>  dedicated prescaler for above 50 Mhz - 250 Mhz+
> 
> 
> 
>  >>      >>
> 
> 
> 
>  >>      >> But I have not a
> 
>  clue how to use the timer1 as an asynconous
> 
> 
> 
>  >> 16 bit
> 
> 
> 
>  >>      >> pulse counter of
> 
>  the PIC16F88 I have for the project.
> 
> 
> 
>  >>      >>
> 
> 
> 
>  >>      >> Output will be to
> 
>  a cheap 4bit LCD or UART serial to a PC, click
> 
> 
> 
>  >>     will be
> 
> 
> 
>  >>      >> HS 20 Mhz XTAL...
> 
> 
> 
>  >>      >>
> 
> 
> 
>  >>      >> Other candidate
> 
>  is a PIC16F628 in my junkbox.
> 
> 
> 
>  >>      >>
> 
> 
> 
>  >>      >> Math is not a
> 
>  problem when I can say something like:
> 
> 
> 
>  >>      >>
> 
> 
> 
>  >>      >>
> 
>  <pseudo-code>
> 
> 
> 
>  >>      >> a =
> 
>  count(pin_b1,100) -- count pulses on pin B1 for 100ms
> 
> 
> 
>  >>      >>
> 
>  </pseudo-code>
> 
> 
> 
>  >>      >>
> 
> 
> 
>  >>      >> Any clue, sample
> 
>  code or tip is welcomed.
> 
> 
> 
>  >>      >>
> 
> 
> 
>  >>      >> 73 de CO7WT,
> 
>  Pavel in Cuba Island.
> 
> 
> 
>  >>      >>
> 
> 
> 
>  >>      >
> 
> 
> 
>  >>
> 
> 
> 
>  >>     --
> 
> 
> 
>  >>     You received this message
> 
>  because you are subscribed to the Google
> 
> 
> 
>  >>     Groups "jallib"
> 
>  group.
> 
> 
> 
>  >>     To unsubscribe from this
> 
>  group and stop receiving emails from it,
> 
> 
> 
>  >>     send an email to [email protected].
> 
> 
> 
>  >>     <mailto:[email protected].>
> 
> 
> 
>  >>     To post to this group, send
> 
>  email to [email protected].
> 
> 
> 
>  >>     <mailto:[email protected].>
> 
> 
> 
>  >>     Visit this group at http://groups.google.com/group/jallib.
> 
> 
> 
>  >>     For more options, visit https://groups.google.com/groups/opt_out.
> 
> 
> 
>  >>
> 
> 
> 
>  >>
> 
> 
> 
>  >>
> 
> 
> 
>  >> --
> 
> 
> 
>  >> You received this message because
> 
>  you are subscribed to the Google
> 
> 
> 
>  >> Groups "jallib" group.
> 
> 
> 
>  >> To unsubscribe from this group and
> 
>  stop receiving emails from it, send
> 
> 
> 
>  >> an email to [email protected].
> 
> 
> 
>  >> To post to this group, send email
> 
>  to [email protected].
> 
> 
> 
>  >> Visit this group at http://groups.google.com/group/jallib.
> 
> 
> 
>  >> For more options, visit https://groups.google.com/groups/opt_out.
> 
> 
> 
>  >>
> 
> 
> 
>  >>
> 
> 
> 
>  >
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>  --
> 
> 
> 
>  You received this message because you are subscribed to
> the
> 
>  Google Groups "jallib" group.
> 
> 
> 
>  To unsubscribe from this group and stop receiving
> emails
> 
>  from it, send an email to [email protected].
> 
> 
> 
>  To post to this group, send email to [email protected].
> 
> 
> 
>  Visit this group at https://groups.google.com/group/jallib.
> 
> 
> 
>  For more options, visit https://groups.google.com/d/optout.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>  --
> 
> 
> 
>  You received this message because you are subscribed to
> the
> 
>  Google Groups "jallib" group.
> 
> 
> 
>  To unsubscribe from this group and stop receiving
> emails
> 
>  from it, send an email to [email protected].
> 
> 
> 
>  To post to this group, send email to [email protected].
> 
> 
> 
>  Visit this group at https://groups.google.com/group/jallib.
> 
> 
> 
>  For more options, visit https://groups.google.com/d/optout.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>  --
> 
> 
> 
>  You received this message because you are subscribed to
> the
> 
>  Google Groups "jallib" group.
> 
> 
> 
>  To unsubscribe from this group and stop receiving
> emails
> 
>  from it, send an email to [email protected].
> 
> 
> 
>  To post to this group, send email to [email protected].
> 
> 
> 
>  Visit this group at https://groups.google.com/group/jallib.
> 
> 
> 
>  For more options, visit https://groups.google.com/d/optout.
> 
> 
> 
> --
> 
> You received this message because you are subscribed to the
> Google Groups "jallib" group.
> 
> To unsubscribe from this group and stop receiving emails
> from it, send an email to [email protected].
> 
> To post to this group, send email to [email protected].
> 
> Visit this group at https://groups.google.com/group/jallib.
> 
> For more options, visit https://groups.google.com/d/optout.
> 
> 
> 
> 
> 
> 
> -- 
> 
> You received this message because you are subscribed to the
> Google Groups "jallib" group.
> 
> To unsubscribe from this group and stop receiving emails
> from it, send an email to [email protected].
> 
> To post to this group, send email to [email protected].
> 
> Visit this group at https://groups.google.com/group/jallib.
> 
> For more options, visit https://groups.google.com/d/optout.
> 
> 
> 
> 
> -- 
> 
> You received this message because you are subscribed to the
> Google Groups "jallib" group.
> 
> To unsubscribe from this group and stop receiving emails
> from it, send an email to [email protected].
> 
> To post to this group, send email to [email protected].
> 
> Visit this group at https://groups.google.com/group/jallib.
> 
> For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "jallib" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to [email protected].
> To post to this group, send email to [email protected].
> Visit this group at https://groups.google.com/group/jallib.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"jallib" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/jallib.
For more options, visit https://groups.google.com/d/optout.

Reply via email to