AVR Freaks

They really don't care about us assembly programmers.

Need to do a bit more digging to see what happens with your datasheet version.

Searching the version I had handy [for PWM1x] I find:

The counting sequence of the Timer/Counter1 is determined by the setting of the WGM10 and
PWM1x bits located in the Timer/Counter1 Control Registers (TCCR1A, TCCR1C and
TCCR1D).

No mention there of TCcR1B.  A later addition?  Or is it that, for assembly language programmers, publishing misleading information is frowned upon?  If it ain't a bit in the datasheet then why would there be something in the chip-include file?  Off to look for a datasheet.  Think I'll start with DigiKey.

Datasheets are prone to errors. The definitive place to look is the .atdf file. But on this occasion that does confirm the datasheet:

        <register caption="Timer/Counter Control Register B" name="TCCR1B" offset="0x4F" size="1">
          <bitfield caption="PWM Inversion Mode" mask="0x80" name="PWM1X"/>
          <bitfield caption="Timer/Counter 1 Prescaler reset" mask="0x40" name="PSR1"/>
          <bitfield caption="Dead Time Prescaler" mask="0x30" name="DTPS1" values="MISC_2BIT_SCALE"/>
          <bitfield caption="Clock Select Bits" mask="0x0F" name="CS1" values="CLK_SEL_4BIT"/>
        </register>

      <value-group caption="" name="MISC_2BIT_SCALE">
        <value caption="1x" name="VAL_0x00" value="0x00"/>
        <value caption="2x" name="VAL_0x01" value="0x01"/>
        <value caption="4x" name="VAL_0x02" value="0x02"/>
        <value caption="8x" name="VAL_0x03" value="0x03"/>
      </value-group>
      <value-group caption="" name="CLK_SEL_4BIT">
        <value caption="No Clock Source (Stopped)" name="VAL_0x00" value="0x00"/>
        <value caption="Running, No Prescaling" name="VAL_0x01" value="0x01"/>
        <value caption="Running, CLK/2" name="VAL_0x02" value="0x02"/>
        <value caption="Running, CLK/4" name="VAL_0x03" value="0x03"/>
        <value caption="Running, CLK/8" name="VAL_0x04" value="0x04"/>
        <value caption="Running, CLK/16" name="VAL_0x05" value="0x05"/>
        <value caption="Running, CLK/32" name="VAL_0x06" value="0x06"/>
        <value caption="Running, CLK/64" name="VAL_0x07" value="0x07"/>
        <value caption="Running, CLK/128" name="VAL_0x08" value="0x08"/>
        <value caption="Running, CLK/256" name="VAL_0x09" value="0x09"/>
        <value caption="Running, CLK/512" name="VAL_0x0A" value="0x0A"/>
        <value caption="Running, CLK/1024" name="VAL_0x0B" value="0x0B"/>
        <value caption="Running, CLK/2048" name="VAL_0x0C" value="0x0C"/>
        <value caption="Running, CLK/4096" name="VAL_0x0D" value="0x0D"/>
        <value caption="Running, CLK/8192" name="VAL_0x0E" value="0x0E"/>
        <value caption="Running, CLK/16384" name="VAL_0x0F" value="0x0F"/>
      </value-group>

If it helps the bit is as missing from the C .h file as it is from the Asm def.inc file...

This is \Program Files (x86)\Atmel\Studio\7.0\packs\atmel\ATtiny_DFP\1.3.229\include\avr\iotn261a.h...

#define TCCR1B _SFR_IO8(0x2F)
#define CS10 0
#define CS11 1
#define CS12 2
#define CS13 3
#define DTPS10 4
#define DTPS11 5
#define PSR1 6

All of this is kind of "odd". The def.inc and the .h are supposed to be auto-generated from the ATDF file - so wonder how it was missed??

EDIT: Oh, I see for the C compiler in the ioth261.h (no A) case there is:

#ifndef _AVR_IOTN261_H_
#define _AVR_IOTN261_H_ 1

#include <avr/iotnx61.h>
...

and in iotnx61.h there is:

#define TCCR1B  _SFR_IO8(0x2F)
#define CS10    0
#define CS11    1
#define CS12    2
#define CS13    3
#define DTPS10  4
#define DTPS11  5
#define PSR1    6
#define PWM1X   7

So for C it only afflicts tiny261A not tiny261 as they have chosen to create "per device" headers not an x61 version to collect together all of 261..861

The implication of all this is it's possible that if you build the Asm for tiny261 not timy261A it may be available.

Not on my downloaded versions of tn261.def.  It appears to have been there [errr, missing] for 10+ years.

For example, from attiny261.xml from 10+ years ago:

     <TCCR1A>
        <IO_ADDR>$30</IO_ADDR>
        <MEM_ADDR>$50</MEM_ADDR>
        <PWM1B_MASK>0x01</PWM1B_MASK>
        <PWM1A_MASK>0x02</PWM1A_MASK>
        <FOC1B_MASK>0x04</FOC1B_MASK>
        <FOC1A_MASK>0x08</FOC1A_MASK>
        <COM1B0_MASK>0x10</COM1B0_MASK>
        <COM1B1_MASK>0x20</COM1B1_MASK>
        <COM1A0_MASK>0x40</COM1A0_MASK>
        <COM1A1_MASK>0x80</COM1A1_MASK>
      </TCCR1A>
      <TCCR1B>
        <IO_ADDR>$2F</IO_ADDR>
        <MEM_ADDR>$4F</MEM_ADDR>
        <CS10_MASK>0x01</CS10_MASK>
        <CS11_MASK>0x02</CS11_MASK>
        <CS12_MASK>0x04</CS12_MASK>
        <CS13_MASK>0x08</CS13_MASK>
        <DTPS10_MASK>0x10</DTPS10_MASK>
        <DTPS11_MASK>0x20</DTPS11_MASK>
        <PSR1_MASK>0x40</PSR1_MASK>
      </TCCR1B>

Wouldn't it make sense to just automate the entire process so that at the press of a button they are ALL generated. That way any later corrections in the "master files" (ATDF) would immediately filter through into the auto-gen files on every release.

(I suppose it might be a bit of work in the first place kicking the auto-gen stuff into shape so that the generated files did not break regression testing - but in the long run it would be a more robust strategy).

... registered DEVXML-2216 internally to fix this bit