Clarification about Quadrature Encoder & Timers needed

Go To Last Post
2 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

 

after the HSMCI-Issue (on my ATSAM4S4) has been luckely solved, i´d like to add an Quadrature Encoder via the QDEC-Functionality, but i have some issues to understand the

Connection between Timers and the inputs. I´ve used Quadrate Encoders before by Polling and also using Interrupts in combination with a decoding Table,

but this here is of course quite different.

 

First a simple Question: Since the Datasheet refers to Qudrature Encoders connected to TIOA0-2, but my Encoder is connected to TIOA3 and TIOB3, i would assume

that the Timer involved is Timer Instance 1 and herein Timer3 to get the position of the Encoder. Is this correct? Is there any need to involve another Timer instance

& Timer in order to get the pure Position function to work (eg Timer Instance 1/Timer3 function would need also Timer 4 for any sort of reference for decoding)?

 

Many thanks & best regards :-)

 

 

 

 

 

 

 

 

 

Last Edited: Sun. Mar 13, 2022 - 02:33 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Works, almost self-explained (yes, Counter3 on Instance 1 is involved and no additional Timer is needed) , althrough there are sometimes counter-jumps in the wrong direction even with the maximum filtering value.

But that´s another story.

 

But i have to admit: As much as the Datasheets and Application Notes are useful, they often lack practical (and in this case - additional, because relevant parts are simply not covered) information. Page 897 on the ATSAM4S Datasheet,

TC-BMR, covers two different peripheral adresses (0x400100C4, 0x400140C4), but TC0XC0S and TC1XC1S and so on also covers even 0x400140C4  - TCLK/TIOA 0-2, which is simply not correct. So, how to find the correct Pin/Timer-

inputs without trying and guessing. I know mistakes can happen, but sometimes the Datasheet "feels" like a car Owner´s manual, where acceleration is explained by pressing the brake pedal (true in some cases, depending

on the point of view) ;-)

 

I am aware that Assembly programming isn´t a thing in modern 32Bit-MCUs (besides from the fact that ESP32 for example is a fully closed thing for ASM) and using ASF is surely a fine thing to get things

fast working, but it doesn´t tell the "whole story". And in fact a 32 Bit ARM-MCU isn´t much more complicated to handle than a 8 Bit MCU by using ASM; the only problem is to get the peripherals due the shear endless

amount of possibilities and combinations working - and handling those few (and in terms of complexity not much more different to AVR) Opcodes for the programming itself isn´t too complicated either.  If you know one

Instruction set and its behaviour, you know them all.

 

Well, Time for the next peripheral :-)

 

 

 

 

 

 

 

 

 

 

 

Last Edited: Sun. Mar 13, 2022 - 04:33 PM