Same code different size on different uC

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

Hi folks,

I had been developing some code on an ATtiny2313 but ran out of room. I have switched to an ATmega168 and just compiled the same code. The ONLY difference between the codes is a definition at the top. Here is a diff file between the two:

6,11c6,11
< #define LCD_PORT PORTC
< #define LCD_DDR  DDRC
< #define LCD_CLK (1<<PC0)
< #define LCD_SIO (1<<PC1)
< #define LCD_CS  (1<<PC2)
< #define LCD_RST (1<<PC3)
---
> #define LCD_PORT PORTB
> #define LCD_DDR  DDRB
> #define LCD_CLK (1<<PB0)
> #define LCD_SIO (1<<PB1)
> #define LCD_CS  (1<<PB2)
> #define LCD_RST (1<<PB3)

So, when I compile this on the tiny2313 it takes up 2000 bytes. When i compile it on the mega168 it takes up 2178 bytes.

Why does the mega168 need 178 bytes more? It doesn't really matter for the application but I'm curious.

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

Differences in the register locations.
The tiny has it's registers at lower addresses, allowing the use of sbi and cbi instructions. The mega needs to use longer LDS/STS instructions.

/Jesper
http://www.yampp.com
The quick black AVR jumped over the lazy PIC.
What boots up, must come down.

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

Quote:

So, when I compile this on the tiny2313 it takes up 2000 bytes. When i compile it on the mega168 it takes up 2178 bytes.

Why does the mega168 need 178 bytes more? It doesn't really matter for the application but I'm curious.


Want to really confuse yourself? Rebuild for a Mega88 and you will get yet another number. ;)

Besides the differences inside the code to do the I/O work as already mentioned, there will be several other areas:
-- the number of interrupt vectors in the table is likely to be different
-- the size of each vector will be different
-- <=8k of firmware can be reached with RCALL/RJMP. Larger (like the '168) will need CALL/JMP here-and-there.
-- In the '2313 the EEPROM and SRAM space is <256 bytes. Depending on the "memory model" and the implementation, pointers only need to be "small". Any SRAM pointer operations are likely to be implemented with X,Y,Z and the xH register need not be loaded saving a word or two each time.
-- Any operation that can take advantage of the xMULx instructions is likely to be different. This will show up not only in actual multiply operations, but may also show up in operations such as array indexing.

Lee

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

Are these things I would understand better if I learned how to read assembly? I'm assuming that the space difference is "hidden" by the compiler..... same C code, different assembly after compilation.

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

If it helps, just think that they are different processors. They do share the basic AVR core, but propably have some different things like different revision of the core, which the compiler knows.

Another examples:

I have C code, and if I compile the same code to DOS, Linux and Windows programs, the size is different.

I have C code, and if I compile the same code with different C compilers, the size is different.