SUMMARY- not many hobbyist are using these MCU's and there isnt a lot of information out there. TPI support may become more important in the future, but I didnt find any RC related projects using an MCU that requires TPI programming.
1. These are the avr20tiny architecture. Sometime called the 'Brain Dead' AVR's.
The main reasons why they don't work with C compilers today is the fact that:
1) The set of CPU registers is half that of the normal AVRs, so any compilers' code generation models that assume the presence of R0 - R15 for variable storage, function call-return conventions, or special/fixed purposes, will fail utterly.
2) Direct SRAM loads/stores take place through a different pair of op-codes (16-bits instead of 32-bits) with the same mnemonic, which have to be supported by the compiler toolchain's assembler.
3) The LPM op-code doesn't exist -- instead, Flash memory is memory-mapped into the SRAM address space (indirect addressing mode only) for table-lookup purposes.
The fact that SRAM is only 32 bytes probably doesn't help things -- that does make for a very restricted space for the stack to occupy in addition to any global variable requirements.
2. programs cant typically be written in C using avr gcc. use assembly. Some of the paid compilers say they support C programming
3. Avrdude had a configuration for the attiny10 (t10) , but not the attiny20. This #avr log said to more or less duplicate t10 entry , and that worked for me
I was able to find some assembly code to compile that toggled a bit(PB2). I used it to verify the programming. Here is the source, which has different definition requirements depending on the MCU, and a couple of hex files.
compiled like this
avr-gcc -mmcu=attinyX0 test.S -o test.elf // replace X with number
avr-objcopy -O ihex test.elf test.hex
Now I can create some patches to the 2011 usbasp firmware and verify that TPI support did not break