the ATtiny MCU series that use TPI programming

Projects that are not for RC, but are cool and worthy of development.
Post Reply
User avatar
rperkins
Posts: 1422
Joined: Sun Jan 08, 2012 12:51 pm
Country: -

the ATtiny MCU series that use TPI programming

Post by rperkins »

I purchased a couple low end AVR MCU's that use the TPI protocol for flashing in order to learn how it works in the 2011 version of usbasp firmware, and to be sure any patches made against the 2011 usbasp dont break it :) Here is some information I learned trying to program an AVR thru the TPI interface

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.
very small attiny10  .1 inch headers
very small attiny10 .1 inch headers
attiny20 with  .1 inch headers
attiny20 with .1 inch headers
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.
attiny.zip
one source and 2 hex files
(852 Bytes) Downloaded 364 times
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 :)

Post Reply

Return to “Other Electronic Projects”