Path: AVR_EN => Applications => IR-controlled steppers    (Diese Seite in Deutsch: Flag DE)
IR-stepper ATtiny24 Applications of
AVR Single chip controllers AT90S, ATtiny, ATmega and ATxmega
Servomotor controller with an ATtiny24

Infrared controlled stepper motors

Download this page as PDF (1,123 kB)
If you need to this here is the correct solution for all your needs.
  1. Hardware needed
    1. Stepper control hardware
    2. Controller hardware
  2. How it works
    1. The IR protocol and transmit algorithm
    2. The receiver algorithm
    3. The steppers
  3. The software needed
    1. The stepper motor software
    2. The controller software

1 The hardware needed

The hardware consists of two separate components: one that runs the model and controls the stepper motors in that, and one where you can manually control direction and position by keys and where you can transmit these commands to your model and read all that on a LCD.

1.1 Motor-control hardware

Schematic of the stepper motor controller This is the hardware for controlling the two stepper motors. It consists of The operating voltage of the ATtiny24 (VC can be between 3.3 and 5 Volts (battery operation is possible). Currents are depending from the following. The IR transmit LED consumes roughly 20 mA at average during transmission time and at maximum 100 mA during the short active LED-on times at 40 kHz.

Top of page Hardware How it works Software

1.2 IR controller hardware with LCD

Controller schematic This is the hardware needed for the controller board: The operating voltage depends from the LCD, either 3.3 or 5.0 V can be used. Battery operation is possible.

Top of page Hardware How the hardware works Software

2 How the hardware works

This chapter describes how the different components work.

2.2 IR receiving

Top of page Hardware How the hardware works Software

2.3 The steppers

The two stepper motors are implemented with the following algorithm.

On start-up and when positions change, the motor is driven with a lower frequency in cStepLow to allow for a smooth motor start. This can for example 100 Hz (0.01 ms/step) and is configurable by the source code. In each round (32 full steps, 64 half steps) the frequency is slowly increased by reducing the delay between the steps by one. This repeats until the motor is driven with the maximum frequency set in cStepHigh. The acceleration is then stopped and the motor frequency remains at that value.

Top of page Hardware How it works Software

3 The software

3.1 Download of asm source code for controller and motor

The software for the controller and the motors is written in AVR assembler source code. These can be downloaded here: controller and motors.

Both work with the standard fuses. The clock frequencies are increased by software (writing to the CLKPR portregister), so no clock fuses are to be changed.

Top of page Hardware How the hardware works Software

3.2 How the IR communication software works

Both, the controller and the motors use a bi-directional IR transmit/receive connection. The following describes how this works in detail.

3.2.1 How the IR protocol has been designed

IR protocol This is how the IR communication protocol works. It starts with phase I, where any incoming IR receiver bits are detected, and transmit is skipped if any activities on the receiver happen during that time. The register rBits starts at 32. This is resulting from
  1. the inactive signal in phase I, plus
  2. one long start signal in phase II, plus
  3. one shorter start signal in phase III, plus
  4. four bits with motor number, plus
  5. 24 bits that encode the position, plus
  6. the final phase that ends transmission and finally restarts the receiver.
rCnt is decresed every time that an inactive phase ends and the next active phase starts.

If no signals are detected in phase I, the receiver is disabled by clearing its interrupt-enable bit and the LED-active part of phase II starts. In this phase the compare match A in TC1 is set to 12.5 µs for generating a 40 kHz signal (@8 MHz = 99, @4 MHz = 49). The register rCnt counts the number of ON/OFF phases of the LED. For the 2 ms long active LED signal 2,000 / 12.5 = 160 of such phases are necessary, providing 80 cycles of 25 µs each with the LED switched on and off.

After having switched the LED on and off, a duration of 2 ms pause is performed. This is done by setting the compare match value to 16,000 (at 8 MHz clock) and setting rCnt to one. In this phase no active switching takes place.

After the 2 ms phase II is over, the 1 ms long active signal phase III starts. The following pause of 1 ms duration is again achieved by a pro-longed OCR1A value.

The following 28 single bits to be transmitted all start with a 250 µs long active phase. If a zero is to be transmitted, a pause of 250 &mico;s follows. If a one is transmitted the pause is longer, 500 µs.

Finally a last active phase of 250 µs and a prolonged pause of 750 µ follows. After that the receiver is switched on again by enabling its interrupt flag.

The complete cycle lasts for between 22 and 29 ms, depending from the number of longer-lasting one-bits to be send.

Top of page Hardware How the hardware works Software

3.2.2 How the transmission works

IR transmit flow diagram Transmit and receive both use TC1 in normal CTC mode with compare match A and the corresponding interrupt. The flow is shown in the diagram to the right.

The red clock cycle counts in the flow diagram are relevant to ensure that during active LED phases, where compare A matches occur every 12.5 µs @40 kHz LED frequency (10.4 µs @48 kHz) resp. every 100 (clock=8 MHz) or 50 clock cycles (clock=4 MHz) and the maximum number of consumed clock cycles in the compare match interrupt routine must not exceed these available clock cycles. Otherwise compare matches would be missed and the whole timing would get corrupted.

In receive mode the number of to-be-tranmitted bits in rBits is zero and OCR1A is set to 0xFFFF. If the compare match occurs, the counter is restarted at a high count to signal an illegal overflow of the TC1 to the receiver software part (normal receptions of IR signals do not last that long).

Prior to starting a transmission (by setting rBits to a non-zero value) the bits to be transmitted have to be prepared. Those are left-adjusted in the four transmit registers rTxN, where N ranges from 0 to 3 and 3 is the most significant. The toggle register rTgl has to be cleared, because transmit starts with an inactive LED. The compare match A of TC1 is set to the length of this inactive period and the cycle counter rCnt is set to one. Lastly rBits is set to the number of bits (header plus data bits plus one last bit) and transmission starts.

If rBits is not zero, the transmitting part of the TC1's compare match interrupt starts. At first, the register rTgl is written to LED input portregister. If the respective bit in rTgl is one, writing this bit toggles the port pin switching the LED on and off. As this register is zero at the beginning of the transmit cycles no toggling occurs in this stage.

Then the number of pulse counts in rCnt is decreased. If it is not zero (as it will be at start-up the transmission), the interrupt returns by restoring SREG to its initial value and a RETI. As this code sequence is needed very often, it is written as the macro RetInt to reduce source code lines and to increase code readability.

If rCnt reaches zero, the toggle bit in rTgl is reversed by ex-oring it with the active LED bit set. This operation either results in a zero- or a non-zero state. If the toggle bit now is one, an active phase starts. If it is zero, a pause starts and the flow diverts to the right side.

In case a new active phase starts (rTgl not zero), first the number of bits is decreased. If that reaches zero, the transmit process is over, the receiver interrupt is enabled and the compare match value is set to the top of TC1. As rBits now is zero until software starts a new transmit sequence, normal receive takes place. This is particularly relevant when switching from transmit to receive: to ensure that the receiver sensor does not get activated, a long pause at the end of the end of the transmit allows the receiver to get rid of pulses and to return to the normal receive situation.

If rBits does not get zero zero after decreasing it, the pulse duration in TC1 is set to 12.5 µs at 40 kHz. As this source code is also used very often, it is written into a macro SetOc, which expets as first parameter @0 the value that OCR1A should be set to.

The remaining code sets the number of LED on/off cycles in rCnt and depends from the number of rBits: If rTgl was zero after inverting it, the register rCnt has to be set one and the pause duration has to be written to OCR1A. If rBits is 30, the duration of phase III is written to OCR1A. If it is 31, the duration of phase II is written. If neither it is checked whether it is the last bit, in which case the final pause duration is written. In the other cases, the next bit to be transmitted is shifted to the carry flag, and the duration either of a zero or a one is written to OCR1A.

The longest of all these subdivisions of the interrupt service routine needs 38 clock cycles. That limits the clock frequency to at least 3 MHz at 40 kHz IR frequency or to 3.65 MHz at 48 kHz and provides even the opportunity to use even higher IR frequencies than 48 kHz with a 4 or 8 MHz controller clock.

At 8 MHz the sleep share in LED active phases is at 86%, over all transmit phases the sleep share is at 93.4%. This increase of the sleep share results from the fact that TC1 absolves the long pause cycles in an inactive manner with just counting clock cycles and without any interrupts in between until the pause ends. If many ones have to be processed, the sleep share even increases to up to 95.2%.

As all the times are configurable by changes to the source code the IR signal can be flexibly designed. The number of bits is not configurable but needs major changes in the source code if more or less than 28 are to be processed.

The first pulses of an active LED cycle To the right are the first pulses of an active LED cycle in the simulator avr_sim's oscilloscope view. Frequency and pulse width are exact.

The 2 ms pulse phase II On the left side are the active LED pulses with 2 ms length in phase II.

The first two header signals On the right you see the two header signals transmitted. The durations of 2 and 1 ms length are obvious.

The headers and the first four motor bits Left are the header signals in phase II and III and the first four bits (the motor number) have been transmitted.

The complete transmit On the right all 28 data bits and the final bit have been transmitted.

The complete transmit of ones On the left are 24 ones and four zeroes transmitted.

The complete transmit of all ones And right is the transmit of all ones.

Top of page Hardware How the hardware works Software

3.2.3 How the IR receiver software works

IR receiver algorithm The receiver procudes a PCINT interrupt every time the IR sensor sees an active IR LED (high-to-low signal) and if the LED cycle turns off (low-to-high signal). The receiver uses the 16-bit timer TC1 to measure the time over which the input pin remains low and over which it remains high. The receiver algorithm uses these durations to check whether these times are correct (= within the expected duration) and collects the 28 data bits from this stream.

In order to do the duration measurement accurate, the PCINT interrupt service rotine starts by reading the MSB of TCNT1, and by that ignoring and overwriting the LSB. TCNT1 is then cleared by writing zeroes to it. That means the timer restarts on every signal reception. Setting the bRx flag on each signal reception event to block the start of the transmission algorithm. Finally SREG is read for later recovery of the SREG flags.

The flow then is diverted depending from the polarity of the receiver pin: if it is clear, an inactive LED signal had been coming in and was measured, otherwise the receiver sensor had seen an active LED signal.

In case of a pause received (left part of the flow diagram), its duration is compared with the shortest length of pause signals (which is a data zero). If the pulse is shorter (below its minimum length, the carry flag is set), an error has happened and the bRxE bit in rFlag is set one.

If it is longer and shorter than its maximum length, the zero bit is fine, the carry flag is cleared and the zero is shifted into the reception area in the SRAM buffer. If after shifting a one comes out of the four bytes, all bits have been received correct and the received position is copied to the respective registers of the position and the bRx flag is cleared to enable transmissions to start.

If not a zero bit has been received, it has to be tested if a one has been received. If the duration is higher or equal to the minimum duration and smaller than the maximum duration, a one-bit has been received and it is proceeded similarly with a one in the carry flag.

If the duration exceeds the maximum of a one-bit, the algorithm diverts to the check of the header lengthes of header 2 and then header 1. As both the active and inactive phases of the two header signals have identical duration, this simplification is possible. If the header 1 is correct, the receiver storage buffer is set to 0x000008 to collect data bits and finalize the bit collection.

This is the complete reception of incoming IR signals. The algorithm is used in the controller board's tiny as well as in the motor's tiny. Both, the transmit and the receive algorithm can be used generally, therefore those are encoded as include source code file that can be included into both source codes without any specific modification. That structuring of the source code requires that used parameters, such as the controller's clock rate, are provided to the include. All parameters that have to be defined outside the include are listed on top of the include source code. If entry parameters are missing within the include source code the assembler run will lead to errors and assembling will fail. So when assembling other source code that uses this include take care that anything has been set correct.

Top of page Hardware How the hardware works Software

3.3 How the stepper software works

As the 16-bit timer/counter 1 is completely and permanently occupied by the IR transmit and receive algorithm, only the 8-bit timer TC0 is available for timing of the stepper motors.

3.3.1 Timing of the two steppers

The stepper motors are driven with a frequency of between, e.g., 100 to 400 Hz. That means that their stepping requires delay times between 10 and 2.5 ms. As the motor controller ATtiny24 runs with either 8 or 4 MHz and TC0 needs 256 clock cycles for its turn-around, the following times are achieved with the different prescaler values:

ClockPrescalerTurn-around timeDelayDelayMin=2Max fMax=254Min f
MHz(ms)(10 ms)(2.5 ms)(µs)Hz(µs)Hz

That means that The range of potential frequencies is broad enough with a prescaler of 1,024.

The stepper algorithm

From that the following algorithm results for driving the motors:
  1. Timer TC0 runs with the clock rate divided by 1,024 (at 7.81 resp. 3.91 kHz).
  2. On reaching compare match A, the motor advances by one step. The speed-determining delay value is then decreased, so the next step delay is shorter than the current. The compare match A value is then increased by the value that determines over the speed, by adding the delay to the current timer value.
  3. The same is done for motor 2 with compare match B.
  4. If the motors have reached their end position, the compare match value is not changed. The next compare match(es) then switch the motor driver off by writing zero to the output and restarting the longer delay time. This is repeated as long as the motor's target position remains unchanged. At 8 MHz, this repeats every 32.8 ms, at 4 MHz every 65.6 ms.
Both compare match event's interrupt service routines are programmed to set flags only. Further reactions outside the interrupt service routine are not time-critical, given the high prescaler value. The reasons for that are to keep the service routine as short as possible to reduce potential interference with the eventually on-going transmission interrupts from TC1. As TC1's OCR1A interrupts have a higher priority, it is clear that those come first (in case both interrupts occur at the same time). Even if a motor interrupt occurs shortly before the IR-transmit interrupt, the delay caused can delay the TX interrupt at maximum with 10 clock cycles, which is roughly one microsecond. TX delays of this durations are insignificant and do not lead to TC1 interrupt losses.

Within a pre-defined rate of repeated no-movement-cycles the transmission of the current position is initiated. That ensures that the controller gets current position information regularly.

Top of page Hardware How the hardware works Software

3.4 How the controller software works

Top of page Hardware How the hardware works Software

3.2 The controller software

Top of page Hardware How the hardware works Software

©2020 by