Top  Previous  Next

At MCS we refer to the new range of TINY processors as the XTINY. This because they look like Xmega processors but smaller.

The XTINY processor is a great new processor. It uses the AVR instruction set. But it has a lot of the hardware found in the Xmega.

But do not make a mistake : these processors are different in many ways. They are the next generation of AVR processors.

They use little power.


When XMega was supported we had to make some decisions about this support. The goal is to keep the code BASCOM compatible. And for Xtiny we were faced with the same dilemmas.

So again there will be new CONFIG statements and because the hardware is different, there will be other changes as well.


You should read the data sheet of the processor like ATTINY816. We used the attiny 816/817 for testing.

The processors are not available anymore in DIP. But you can use SOIC with a converter board. Like Xmega, this makes the processor less usable for hobbyists. At least for those that do not make their own PCB's.


Like the Xmega the internal registers can not be addressed by a pointer. So we had to change code using pointers.



A big difference is that you once again need a new programmer since the programming interface is using UPDI.

The good news however is that you can use a simple serial port and a resistor to do the programming.

BASCOM-AVR supports the UPDI protocol with a dedicated programmer.

You will notice when you read the fuses that there are a lot of fuses and other settings. At the moment of writing, the fuses can not be programmed yet.



Like the Xmega, the Xtiny has extensive internal and external oscillator support. This means that you need to chose the system clock using the CONFIG SYSCLOCK statement.

This is essentially the only difference in code you need to make compared with the normal AVR.

The options and values differ from the Xmega.



In order to use the UART, you need to use CONFIG COMx. There is no default configuration when you use $baud. We would recommend to use CONFIG COM anyway. It can set all relevant settings.

Also notice that the UART has separate registers for reading and writing. That is something new, not seen earlier. For this purpose we mapped registers UDRW and UDRR to the USART0_RXDATA / TXDATA registers.




The EEPROM is more complex since it only works with pages. But the good news is that the EEPROM can be read like normal variables.




The ports have more options compared to normal AVR but less compared to Xmega. While Xmega can do a setting for an entire port, this feature is missing in Xtiny. The virtual port option is also different. In Xtiny there is just a register in the lower IO space mapped to the three most important port registers : DDR, PORT and PIN. These are named VPORTA_DIR, _OUT  and _IN.

We added DDR0, PORT0, PIN0 to make them compatible with Xmega. We also added VDDRA, VPORTA, and VPINA. All these registers are located in lower IO memory.

The reason is that we can use a simple ASM instruction that only work on registers in low IO address space. Like SBI, CBI, etc.


Lets have a look at VPORTA in the DAT file :

VPORTA_DIR = 0                      ; Data Direction

VPORTA_OUT = 1                     ; Output Value

VPORTA_IN = 2                        ; Input Value

VPORTA_INTFLAGS =3               ; Interrupt Flags

DDR0=0                                  ; alias for compatibility (DIR)

PORT0=1                                ; alias for compatibility (OUT)

PIN0=2                                  ; alias for compatibility (IN)

VDDRA=0                                ; alias for compatibility (DIR)

VPORTA=1                              ; alias for compatibility (OUT)

VPINA=2                                 ; alias for compatibility (IN)



The other alias we use are DDRA, PORTA and PINA. These are however mapped to the extended address registers.


PORTA_DIR = 1024                    ; Data Direction

PORTA_DIRSET = 1025                 ; Data Direction Set

PORTA_DIRCLR = 1026                 ; Data Direction Clear

PORTA_DIRTGL = 1027                 ; Data Direction Toggle

PORTA_OUT = 1028                    ; Output Value

PORTA_OUTSET = 1029                 ; Output Value Set

PORTA_OUTCLR = 1030                 ; Output Value Clear

PORTA_OUTTGL = 1031                 ; Output Value Toggle

PORTA_IN = 1032                     ; Input Value

PORTA_INTFLAGS = 1033               ; Interrupt Flags

PORTA_PIN0CTRL = 1040               ; Pin 0 Control

PORTA_PIN1CTRL = 1041               ; Pin 1 Control

PORTA_PIN2CTRL = 1042               ; Pin 2 Control

PORTA_PIN3CTRL = 1043               ; Pin 3 Control

PORTA_PIN4CTRL = 1044               ; Pin 4 Control

PORTA_PIN5CTRL = 1045               ; Pin 5 Control

PORTA_PIN6CTRL = 1046               ; Pin 6 Control

PORTA_PIN7CTRL = 1047               ; Pin 7 Control





The reason for this is that some statements require a pointer to the register. That will only work with extended address.

When you use code like SET PORTA.0   this will translate into setting a register, and writing this register to PORTA_OUTSET.


When you use the same code on a virtual port, the code will use one instruction to set the bit of the port using SBI.

In a later optimization we will learn the compiler to use vports when possible.

The xmega Vports are different. They can change and map ports dynamically. In Xtiny they are static mapped.



The pin behavior can be further configured using CONFIG XPIN.



The interrupt system is extended with an option to specify one high priority interrupt.

So this is a nice extension.

You should also notice that a lot of interrupts need to be cleared manually. For example using a PIN interrupt requires to reset the INTFLAG register by writing a 1.

While normal AVR pin interrupts let you guess which pin caused the interrupt, the Xtiny had registers that tell which pin caused the interrupt.




The watchdog works similar to the one found in the Xmega.



DAT files

When you look in the DAT file you will notice that almost all registers have new names. Also compared to Xmega. Of course BASCOM will use the right register when you use BASCOM code.

When using ASM you need to check the datasheet and the DAT file.

When you are familiar with Xmega the transition should be smooth.




The Xtiny chips are very complete. They also have AD converter and a DA converter on board.




The TWI is almost identical to the TWI in Xmega. This also means that when using TWI you need to create a byte variable named TWI_START in your user code.

The reason for this is that the TWI hardware sends a START and the slave address at once.

Traditionally this was separated by an I2CSTART and I2CWBYTE.

The TWI_START variable holds the state of I2CSTART. And when you write the address, it will use the proper instruction to send start and slave address.

When you want to use soft I2C, you need to use the $FORCESOFTI2C directive.




Since the ports have a different mapping, the 1wire code needed to be rewritten as well.




All Xtiny specific code you can find in Xtiny.lib

It contains overloaded versions of the code found in mcs.lib

Xtiny specific code in mcs.lib or other libs can be found by looking for the _XTINY constant.

This constant is set when you use a processor from the Xtiny range.




The XTINY has a different memory model. The BOOT area is located at the start of memory. After this memory the normal memory is located. With a FUSE you can set how many pages of the BOOT area you would like to use for boot code. A value of 1 will reserve a space of 256 bytes. When your loader binary code is 1024 bytes you would set it to : 1024/256 = 4

After the normal application code there is also the optional application data. This area can also be set with a fuse.

When using a boot loader you need to take care of the fact that your normal application code must start after the boot code. This can be done by using $ROMSTART in your code.



Add on

The addition of Xmega to BASCOM was a lot of work. This because only the instruction set was the same. We worked long on UPDI processor support and still this is a work in progress. So expects some updates specific for Xtiny/UPDI.

The Xtiny addition is not free of charge. It requires a commercial add on. It is available from the MCS shop.

The Xtiny add on will support all Xtiny processors.