#ATTINY10 DATASHEET CODE#

#ATTINY10 DATASHEET CODE#

But the routine that generate the code to load 16bit does not know that the routine to generate a store prefer to use the Z register, so this sequence of code is generated. 8-bit AVR Microcontroller ATtiny4 / ATtiny5 / ATtiny9 / ATtiny10 DATASHEET COMPLETE Introduction The Atmel ATtiny4/5/9/10 is a low-power CMOS 8-bit. The extra steps are due to the optimization level: at no optimization, the compiler is doing a 1 to 1 translation of the code, and in the code we are specifying a 16 bit constant for the address (hidden in the macros defining CLKMSR and CCP), so this needs to be constructed. so we construct it piecewise,one byte at the time, and then use the result for an indirect addressing store. this means that to store a value at a generic address, we can't build the destination address -the content of the Z register - directly. Remember that this mcu is 8bit, with 8bit datapath and 16bit address. Why not loading everything directly to the Z register, or even directly to CCP? Then, loads 0xD8 (stored in r22) to the CCP register, addressed by the Z register. Toghether, the asm refers to them with 'Z'. r31 is the high byte, and r30 is the low byte of an address. These two destination registers are at least a bit special, because they are address registers. Then loads zero into r21.ДЄt this point loads the immediate -40 (which is 0xD8 in two's complement) into r22. Of course, to an expert, this would seem totally expected.ДЄt first loads the immediate 60 in r20. The compiler is doing something weird to my eyes. If you consider, for example from the instruction at memory addres 002c (signature loaded into CCP) to instruction at 0036, when 0 is loaded into CLKMSR, there are obviously more than 4 instructions. 10:blink-prescaler-register.c **** CCP = 0xD8 // signature to CCPДЎ1:blink-prescaler-register.c **** CLKMSR = 0 // use clock 00: Internal 8 MHz

Attiny10 datasheet