This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CCS/TM4C123GH6PM: Getting a timer value for a cadence tachomoeter ~40-100rpm

Part Number: TM4C123GH6PM

Tool/software: Code Composer Studio

Hello,

My partner and I are currently working on using a timer to get a measured cadence of a bicycle crank. We plan on using a reed switch and a magnet to read when the crank passes the frame. There is only one point per revolution on the bike for us to gather our data. This spot needs to read and reset the tmer as it passes this point. We know we need a 32-bit timer because of the long period due to the low RPM(~40-100) we are using, and our 40 MHz clock. The format we plan on using is having the hardware trigger the ISR, which will read and reset the current register, and put a flag up. When the flag is up in main it will do the calculation for RPM. We are looking for advice on how to set the timer up.

Advice for set up:

1. peripheral enable

2. timer configure

3. timer load value

4. enable timer

5. enable interupt

  • Hi Michael,
    To understand how the TM4C timer works, there are several examples in the TivaWare package. Please go to <TivaWare_installation>/examples/peripherals/timers folder where you will find several examples on setting up the timer and generate interrupt.

    Here is another post that is also helpful in answering RPM measurement. e2e.ti.com/.../582964
  • Michael,
    Being on the strategy level, you'd better configure your pin as a TCCP (timer capture).
    Take a look at the timer registers: there are two registers that store counting value - one always reads the current value, and the other, when the timer is configured in capture mode, will keep the timer value of when it was last triggered.
    Inside the interrupt, all you want to do is clear the interrupt, store the counter to a variable and get out of there. Do the maths on your main code.
    No need to reset the timer every time, just evaluate the elapsed difference - it will actually be more precise.
    Take care with bouncing: the reed switch might generate a few spikes when engaging or disengaging, and your timer will give you crazy results - you can add some hardware solutions for that, as well as some software intelligence to discard "impossible values". Google for "debouncing".
    Cheers
    Bruno
  • Hi,

    Here it is an interesting bicycle ABS brake system. If interested, I have the full package, including the software. 

  • Michael Winter75 said:
    There is only one point per revolution on the bike for us to gather our data.

    Beware of, "Always, Never & Only!"   Knowing your gearing - and wheel/tire diameter - and w/the attachment of 4 to 8 regularly spaced magnets (along wheel's rim) plus a tiny hall-sensor pick-up - you should be able to generate, "More pulses/Crank revolution" - which improves (both) Crank speed measurement accuracy & resolution - AND adds bike speed, too!    (that surely necessary for a commercial effort)

    Crank speed should be a direct function of wheel speed & gearing - which enables "more pulses" and (likely) easier attachment of pick-up RX & TX.   (receiver (hall sensor) & transmitter (magnets))

    If you simply "must" maintain, "Crank rotary detection only" - I'd look into the acquisition of a commercial, "Crank Sensor" (assuming they exist) or the development of a crank driven/mounted rotary disk - both delivering many more, "Pulses per Crank Revolution."   

    Ease & speed of implementation should not trump the desire for greatly improved measurement accuracy & resolution...