attiny87 versus attiny167

Go To Last Post
12 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,

Can anyone confirm that these 2 parts are compatible (in other words, can I program a HEX file that works on a 87 into a 167?).

The datasheet implies so:

"ATtiny87 and ATtiny167 are hardware and software compatible. They differ only in memory
sizes as shown in Table 1-1.".

But my 87 firmware does't work on a 167... does not even seem to start.

Using WinAVR-20100110, if I recompile my project as a 167 project, the firmware works... and the HEX file is slightly bigger.

Confused and hoping for an answer...
Stephane

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

But my 87 firmware does't work on a 167... does not even seem to start.

As a general rule, AVR8 with 8K or less of flash use single-word interrupt vectors. Those with more flash use two-word interrupt vectors. (The '2560 e.g. has 256K of flash, but interrupt vectors are only two words, so ISRs must be in the lower 128K?)

Pulling up the datasheet...yep--see "7.1 Interrupt Vectors in ATtiny87/167". So any program with interrupts can't be just "dropped in".

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

wow, thx for the quick reply. Really appreciated...

Wonder what the datasheet means by 'hardware & software' compatible (section 1.1 Comparison Between ATtiny87 and ATtiny167). I find that a bit misleading.

Thanks again!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It means the AVR instructions have the same binary opcodes from part number to part number. What the diff is: the 8K flash part probably has 512 bytes of ram, so the compiler startup code sets the stack pointer there. The 16K part probably has 1K of ram, so the compiler sees the 16K AVR part number and thinks to himself "Well, better put the stack pointer at the end of the 1K ram" and this program will absolutely not run on the 8K AVR.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It's software compatible in the sense that you can take the same source file, just change the build target between 87 and 167 and rebuild. Given that this only takes a minute I don't really see the appeal of needing to be able to use exactly the same .hex

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As a general rule, you just have to change the device in the IDE and recompile.

Different families like mega48/88/168/328 all share the same special function registers and basic operation.
However you do have different amounts of SRAM, EEPROM and FLASH. You do have different size of vectors and rjmp/jmp too.

This is generally nothing to worry about with a C compiler. ASM programmers do enjoy writing non-maintainable code. So you need to check the JMP/RJMP and vector usage.

Other families are mega164/324/644/1284
Or tiny87/167
Or mega64/128

Note that there are some minor differences between an A or a P or a L or ... suffix.

So you can never just run a binary on the wrong AVR.
You can re-compile or re-assemble for the same family.
You can do some serious reading, then edit, compile for other AVR members.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

So you can never just run a binary on the wrong AVR.

Well, you can't say "never" IME. For example, Mega48 code will happily run on a Mega88 (if no bootloader). There are probably other examples as well. As a speculation Mega164 code would run on the other family members if there is no bootloader. But that would be unusual circumstances. And if done that way, probably a waste of memory resources.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, that was a wild generalisation on my part.

Many trivial blinky programs will run on any AVR chip that happens to share the same PORT and DDR addresses.

I have run 90S2313 binary code on a Tiny2313 (I think)

All the same, it does not seem too hard to just select the correct chip in the IDE and rebuild.

Or if you don't have the source code, buy the correct chip from the distributor in the first place.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for all the replies.

Of course it does not take long to recompile for a different target.

But in a mass production environment, changing a binary means full regression testing, changing production documentation, creating a new part #, bla bla...

Long story short: we have been producing a board with a tiny87 and firmware XXX. The hw engineers wanted to put in a tiny167 instead (in prevision of the future), and were hoping the same binary for firmware XXX could still be used.

Maybe you can see my point more clearly now - I should have stated that in my original post.

Thanks again!

Last Edited: Fri. Jan 25, 2013 - 06:04 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

We substituted a bigger AVR model on a couple small production runs when Atmel's switch to fab-less or fab-lite or whatever cause spot shortages of Mega48 and Tiny25. Indeed, I could have rebuilt the app but we chose to do a "one-time cheat" and just run the same firmware. If at the time of the next buy it would again need a substitute then I would have rebuilt and had two versions.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Maybe you can see my point more clearly now

Indeed - so does the code use any interrupts? If not you should get away with it. Even if it uses INT0 you would.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Indeed - so does the code use any interrupts? If not you should get away with it. Even if it uses INT0 you would.
If the binary is bigger than 4k, then there could be RJMPs/RCALLs relying on a wrap around.

Stefan Ernst