AVR Freaks

AS7 on Windows, so yes you have missed many an existing thread on the subject!

I haven't missed them, they just haven't been helpful, since I'm using Linux (thought the thread title gave it away ;-)

How could you miss the sarcastic humor implied.

I didn't.  Hence my own smilie.  Here's another :)

I am trying to find a solution for you though, more eyes, Bing Fu, and the fact that I also have to use Linux for some projects.  In the end the joint effort supports the needs of the many. 

Gratitude.

I will resume my own search when I again become conscious.

The specs stuff is supported since v5

The 'specs stuff' appears to be supported in 4.9.2 as well:

$ apt-show-versions | grep gcc-avr
gcc-avr:amd64/xenial 1:4.9.2+Atmel3.5.0-1 uptodate
gcc-avr:i386 not installed
$ /usr/bin/avr-gcc --version
avr-gcc (GCC) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ locate specs | grep -i tiny
/usr/lib/gcc/avr/4.9.2/device-specs/specs-attiny10
/usr/lib/gcc/avr/4.9.2/device-specs/specs-attiny11
/usr/lib/gcc/avr/4.9.2/device-specs/specs-attiny12
/usr/lib/gcc/avr/4.9.2/device-specs/specs-attiny13
/usr/lib/gcc/avr/4.9.2/device-specs/specs-attiny13a
/usr/lib/gcc/avr/4.9.2/device-specs/specs-attiny15
/usr/lib/gcc/avr/4.9.2/device-specs/specs-attiny1634
/usr/lib/gcc/avr/4.9.2/device-specs/specs-attiny167
/usr/lib/gcc/avr/4.9.2/device-specs/specs-attiny20
/usr/lib/gcc/avr/4.9.2/device-specs/specs-attiny22
/usr/lib/gcc/avr/4.9.2/device-specs/specs-attiny2313
/usr/lib/gcc/avr/4.9.2/device-specs/specs-attiny2313a
/usr/lib/gcc/avr/4.9.2/device-specs/specs-attiny24
/usr/lib/gcc/avr/4.9.2/device-specs/specs-attiny24a
/usr/lib/gcc/avr/4.9.2/device-specs/specs-attiny25
/usr/lib/gcc/avr/4.9.2/device-specs/specs-attiny26
/usr/lib/gcc/avr/4.9.2/device-specs/specs-attiny261
/usr/lib/gcc/avr/4.9.2/device-specs/specs-attiny261a
/usr/lib/gcc/avr/4.9.2/device-specs/specs-attiny28
/usr/lib/gcc/avr/4.9.2/device-specs/specs-attiny4
/usr/lib/gcc/avr/4.9.2/device-specs/specs-attiny40
/usr/lib/gcc/avr/4.9.2/device-specs/specs-attiny4313
/usr/lib/gcc/avr/4.9.2/device-specs/specs-attiny43u
/usr/lib/gcc/avr/4.9.2/device-specs/specs-attiny44
/usr/lib/gcc/avr/4.9.2/device-specs/specs-attiny441
/usr/lib/gcc/avr/4.9.2/device-specs/specs-attiny44a
/usr/lib/gcc/avr/4.9.2/device-specs/specs-attiny45
/usr/lib/gcc/avr/4.9.2/device-specs/specs-attiny461
/usr/lib/gcc/avr/4.9.2/device-specs/specs-attiny461a
/usr/lib/gcc/avr/4.9.2/device-specs/specs-attiny48
/usr/lib/gcc/avr/4.9.2/device-specs/specs-attiny5
/usr/lib/gcc/avr/4.9.2/device-specs/specs-attiny828
/usr/lib/gcc/avr/4.9.2/device-specs/specs-attiny84
/usr/lib/gcc/avr/4.9.2/device-specs/specs-attiny841
/usr/lib/gcc/avr/4.9.2/device-specs/specs-attiny84a
/usr/lib/gcc/avr/4.9.2/device-specs/specs-attiny85
/usr/lib/gcc/avr/4.9.2/device-specs/specs-attiny861
/usr/lib/gcc/avr/4.9.2/device-specs/specs-attiny861a
/usr/lib/gcc/avr/4.9.2/device-specs/specs-attiny87
/usr/lib/gcc/avr/4.9.2/device-specs/specs-attiny88
/usr/lib/gcc/avr/4.9.2/device-specs/specs-attiny9
/usr/lib/gcc/avr/4.9.2/device-specs/specs-avrtiny

... which is why I was able to proceed as far as I did.  Note that it appears to be supported in 4.9.2 in the Ubuntu repositories for 16.04LTS, not just in the 4.9.2 from the Atmel toolchain 3.5.4.

Same vor -mmcu=avrtiny, which was added in v5.

And yet there it is above (last in the list), and below:

$ /usr/bin/avr-gcc -mmcu=attiny104
avr-gcc: error: cannot access device-specs for ‘attiny104’ expected at
‘/usr/lib/gcc/avr/4.9.2/device-specs/specs-attiny104’
avr-gcc: note: devices natively supported: ata5272 ata5505 ata5702m322 ata5782
ata5790 ata5790n ata5791 ata5795 ata5831 ata6285 ata6286 ata6289 ata6612c
ata6613c ata6614q ata6616c ata6617c ata664251 ata8210 ata 8510 atmega103
atmega128 atmega128a atmega128rfa1 atmega128rfr2 atmega1280 atmega1281
atmega1284 atmega1284p atmega1284rfr2 atmega16 atmega16a atmega16hva
atmega16hva2 atmega16hvb atmega16hvbrevb atmega16m1 atm ega16u2 atmega16u4
atmega161 atmega162 atmega163 atmega164a atmega164p atmega164pa atmega165
atmega165a atmega165p atmega165pa atmega168 atmega168a atmega168p atmega168pa
atmega168pb atmega169 atmega169a atmega 169p atmega169pa atmega256rfr2
atmega2560 atmega2561 atmega2564rfr2 atmega32 atmega32a atmega32c1 atmega32hvb
atmega32hvbrevb atmega32m1 atmega32u2 atmega32u4 atmega32u6 atmega323
atmega324a atmega324p atmega32 4pa atmega325 atmega325a atmega325p atmega325pa
atmega3250 atmega3250a atmega3250p atmega3250pa atmega328 atmega328p atmega329
atmega329a atmega329p atmega329pa atmega3290 atmega3290a atmega3290p
atmega3290pa a tmega406 atmega48 atmega48a atmega48p atmega48pa atmega48pb
atmega64 atmega64a atmega64c1 atmega64hve atmega64hve2 atmega64m1 atmega64rfr2
atmega640 atmega644 atmega644a atmega644p atmega644pa atmega644rfr2 atm ega645
atmega645a atmega645p atmega6450 atmega6450a atmega6450p atmega649 atmega649a
atmega649p atmega6490 atmega6490a atmega6490p atmega8 atmega8a atmega8hva
atmega8u2 atmega8515 atmega8535 atmega88 atmega88a atmega88p atmega88pa
atmega88pb attiny10 attiny11 attiny12 attiny13 attiny13a attiny15 attiny1634
attiny167 attiny20 attiny22 attiny2313 attiny2313a attiny24 attiny24a attiny25
attiny26 attiny261 attiny261a att iny28 attiny4 attiny40 attiny43u attiny4313
attiny44 attiny44a attiny441 attiny45 attiny461 attiny461a attiny48 attiny5
attiny828 attiny84 attiny84a attiny841 attiny85 attiny861 attiny861a attiny87
attiny88 att iny9 atxmega128a1 atxmega128a1u atxmega128a3 atxmega128a3u
atxmega128a4u atxmega128b1 atxmega128b3 atxmega128c3 atxmega128d3 atxmega128d4
atxmega16a4 atxmega16a4u atxmega16c4 atxmega16d4 atxmega16e5 atxmega192a
3 atxmega192a3u atxmega192c3 atxmega192d3 atxmega256a3 atxmega256a3b
atxmega256a3bu atxmega256a3u atxmega256c3 atxmega256d3 atxmega32a4 atxmega32a4u
atxmega32c3 atxmega32c4 atxmega32d3 atxmega32d4 atxmega32e5 a txmega384c3
atxmega384d3 atxmega64a1 atxmega64a1u atxmega64a3 atxmega64a3u atxmega64a4u
atxmega64b1 atxmega64b3 atxmega64c3 atxmega64d3 atxmega64d4 atxmega8e5
at43usb320 at43usb355 at76c711 at86rf401 at90can128 at90can32 at90can64
at90c8534 at90pwm1 at90pwm161 at90pwm2 at90pwm2b at90pwm216 at90pwm3 at90pwm3b
at90pwm316 at90pwm81 at90scr100 at90s1200 at90s2313 at90s2323 at90s2333
at90s2343 at90s4414 at90s4433 at90s443 4 at90s8515 at90s8535 at90usb1286
at90usb1287 at90usb162 at90usb646 at90usb647 at90usb82 at94k m3000
avr-gcc: note: supported core architectures: avr2 avr25 avr3 avr31 avr35 avr4
avr5 avr51 avr6 avrxmega2 avrxmega4 avrxmega5 avrxmega6 avrxmega7 avrtiny avr1
avr-gcc: note: you can provide your own specs files, see
<http://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html> for details
avr-gcc: fatal error: no input files
compilation terminated.

Since the introduction of the specs hack Atmel stopped adding device support to mainline, so you will need that specs hack even with the most recent version of the tools.

I'm not sure I understand.  Are you saying that Atmel are no longer publishing their own builds?  Isn't that contrary to the licence?

EDIT:  Fixed horrible formatting in code blocks.

If you take the route of building yourself, then will you summarize what you've learned and share? Please?

Will do.  I'm hoping I'll have luck with a pre-built package from a repo, though.

Thanks @Holle_L, but I'm aware of all of that.  I already have the DFP, and the same repo-fetched version of avr which you're using.  I'd tried to use them in the recommended way:

How to use Atmel DFPs with Stanadalone toolchain?

# Download DFP from here (e.g. Atmel.ATmega_DFP.1.0.86.atpack)

# Unzip .atpack to packs directory (/home/packs/)

# Invoke avr-gcc with additional option -B to tell gcc where to look for device specific information

e.g. avr-gcc -mmcu=atmega328pb -B /home/packs/Atmel.ATmega_DFP.1.0.86/gcc/dev/atmega328pb/

... which is of course better than copying them to /usr/lib by hand.  That will likely break as soon as the repo offers an update to the package.

Neither am I interested in having to use wine, and as I'm porting AVR GCC code, avra/avrasm2 won't be necessary or helpful.

Turns out the issue was a layer 8 problem.  I was trying all of this on Ubuntu Mate 17.10 in a VM, and I'd only installed gcc-avr.  I'd forgotten to the rest of the toolchain (avr-libc, binutils-avr, etc).  I'm so used to getting it all in one tarball from Atmel, I guess.  Silly me.  Took me a little while to absorb the implication of "<avr/io.h> not found".

In addition to using -B to point the compiler to the directory containing the crt*.o, lib*.a, and specs* device-specific files, -I must be used to point to the include directory in the DFP, or attiny104.h won't be found by io.h.

With those installed, all seems to be well.

Thanks for everyone's help.

I'd still love to see an up-to-date, prebuilt, Micromel-provided toolchain that can be deployed on any Linux system, like they used to do right up to 3.5.4.  The current toolchain seems to be 3.6.1 (thank you @gchapman), but I cannot find an official build of it (as a tarball) anywhere (Anyone from Microchip reading this?)

Looks like byte code (lto).

Yeah, it went away when I dropped LTO.

Dump all __flash and PROGMEM stuff and use open-coded C / C++.

I'd had a hunch about that, too.

I dropped down to a simple blinky test, and it builds fine:

$ cat blink104.c
#include <avr/io.h>
#include <util/delay.h>

#define FLASH_RATE 0.5

int __attribute__ ((__OS_main__)) main(void) {

  DDRA = 0;
  DDRA = 0xFF;

  while(1) {
    PORTA = 0xFF;
    _delay_ms(500.0 / FLASH_RATE);
  }   

}

$ avr-gcc -DF_CPU=1000000UL -Os -mmcu=attiny104 -g -Wall -save-temps blink104.c -o blink104.elf
$ avr-objdump -S blink104.elf

blink104.elf:     file format elf32-avr

Disassembly of section .text:

00000000 <__vectors>:
   0:	0f c0       	rjmp	.+30     	; 0x20 <__ctors_end>
   2:	16 c0       	rjmp	.+44     	; 0x30 <__bad_interrupt>
   4:	15 c0       	rjmp	.+42     	; 0x30 <__bad_interrupt>
   6:	14 c0       	rjmp	.+40     	; 0x30 <__bad_interrupt>
   8:	13 c0       	rjmp	.+38     	; 0x30 <__bad_interrupt>
   a:	12 c0       	rjmp	.+36     	; 0x30 <__bad_interrupt>
   c:	11 c0       	rjmp	.+34     	; 0x30 <__bad_interrupt>
   e:	10 c0       	rjmp	.+32     	; 0x30 <__bad_interrupt>
  10:	0f c0       	rjmp	.+30     	; 0x30 <__bad_interrupt>
  12:	0e c0       	rjmp	.+28     	; 0x30 <__bad_interrupt>
  14:	0d c0       	rjmp	.+26     	; 0x30 <__bad_interrupt>
  16:	0c c0       	rjmp	.+24     	; 0x30 <__bad_interrupt>
  18:	0b c0       	rjmp	.+22     	; 0x30 <__bad_interrupt>
  1a:	0a c0       	rjmp	.+20     	; 0x30 <__bad_interrupt>
  1c:	09 c0       	rjmp	.+18     	; 0x30 <__bad_interrupt>
  1e:	08 c0       	rjmp	.+16     	; 0x30 <__bad_interrupt>

00000020 <__ctors_end>:
  20:	11 27       	eor	r17, r17
  22:	1f bf       	out	0x3f, r17	; 63
  24:	cf e5       	ldi	r28, 0x5F	; 95
  26:	d0 e0       	ldi	r29, 0x00	; 0
  28:	de bf       	out	0x3e, r29	; 62
  2a:	cd bf       	out	0x3d, r28	; 61
  2c:	02 d0       	rcall	.+4      	; 0x32 <main>
  2e:	0f c0       	rjmp	.+30     	; 0x4e <_exit>

00000030 <__bad_interrupt>:
  30:	e7 cf       	rjmp	.-50     	; 0x0 <__vectors>

00000032 <main>:

#define FLASH_RATE 0.5

int __attribute__ ((__OS_main__)) main(void) {

  DDRA = 0;
  32:	11 b9       	out	0x01, r17	; 1
  DDRA = 0xFF;
  34:	4f ef       	ldi	r20, 0xFF	; 255
  36:	41 b9       	out	0x01, r20	; 1

  while(1) {
    PORTA = 0xFF;
  38:	42 b9       	out	0x02, r20	; 2
	#else
		//round up by default
		__ticks_dc = (uint32_t)(ceil(fabs(__tmp)));
	#endif

	__builtin_avr_delay_cycles(__ticks_dc);
  3a:	5f e3       	ldi	r21, 0x3F	; 63
  3c:	6d e0       	ldi	r22, 0x0D	; 13
  3e:	73 e0       	ldi	r23, 0x03	; 3
  40:	51 50       	subi	r21, 0x01	; 1
  42:	60 40       	sbci	r22, 0x00	; 0
  44:	70 40       	sbci	r23, 0x00	; 0
  46:	e1 f7       	brne	.-8      	; 0x40 <__SREG__+0x1>
  48:	00 c0       	rjmp	.+0      	; 0x4a <__SREG__+0xb>
  4a:	00 00       	nop
  4c:	f5 cf       	rjmp	.-22     	; 0x38 <main+0x6>

0000004e <_exit>:
  4e:	f8 94       	cli

00000050 <__stop_program>:
  50:	ff cf       	rjmp	.-2      	; 0x50 <__stop_program>

Note that I included the line DDRA = 0 to show that the compiler correctly uses r17 for __zero_reg__.

Now if I try to use __flash:

$ cat blink104.c
#include <avr/io.h>
#include <util/delay.h>

#define FLASH_RATE 0.5

int __attribute__ ((__OS_main__)) main(void) {

  static const __flash uint8_t foo[] = {
    0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, 0x80
  };

  uint8_t bar;

  DDRA = 0;
  DDRA = 0xFF;

  while(1) {
    for (bar=0; bar<sizeof(foo); bar++) {
      PORTA = foo[bar];
      _delay_ms(500.0 / FLASH_RATE);
    }
  }   

}

$ avr-gcc -DF_CPU=1000000UL -Os -mmcu=attiny104 -g -Wall -save-temps blink104.c -o blink104.elf
blink104.s: Assembler messages:
blink104.s:39: Error: illegal opcode elpm for mcu avrtiny
blink104.s:40: Error: register name or number from 16 to 31 required
blink104.s:41: Error: illegal opcode sbiw for mcu avrtiny

And looking at the .s:

$ head -n 46 blink104.s
	.file	"blink104.c"
__SP_H__ = 0x3e
__SP_L__ = 0x3d
__SREG__ = 0x3f
__CCP__ = 0x3c
__tmp_reg__ = 16
__zero_reg__ = 17
	.text
.Ltext0:
	.cfi_sections	.debug_frame
	.section	.text.startup,"ax",@progbits
.global	main
	.type	main, @function
main:
.LFB6:
	.file 1 "blink104.c"
	.loc 1 6 0
	.cfi_startproc
/* prologue: function */
/* frame size = 0 */
/* stack size = 0 */
.L__stack_usage = 0
	.loc 1 14 0
	out 0x1,__zero_reg__
	.loc 1 15 0
	ldi r20,lo8(-1)
	out 0x1,r20
	ldi r20,lo8(foo.1641)
	ldi r21,hi8(foo.1641)
	subi r20,lo8(-(8))
.L3:
.LVL0:
	.loc 1 6 0
	ldi r30,lo8(foo.1641)
	ldi r31,hi8(foo.1641)
.LVL1:
.L2:
	.loc 1 19 0 discriminator 3
	lpm
	mov r21,r0
	adiw r30,1
.LVL2:
	out 0x2,r21
.LVL3:
.LBB4:
.LBB5:

So something about using __flash assumes a full complement of GP registers.  I suppose that whichever part of avr-gcc generates the code for __flash ignores core restrictions like the number of GP registers...?

However, the curious thing is that lpm and sbiw trigger errors.

Huh?  When I look at the instruction set summary in the ATtiny102/104 datasheet, SBIW is there:

LPM is there too.

Hang on... >>everything<< is there.  There are 128 instructions in the instruction set summary.  That certainly doesn't jibe with:

... even if we account for folding some instructions together.  For example, the t25/45/85 datasheet claims 120 instrucitons, and shows 123 instructions in the summary.

Then I stumbled across this:

https://www.avrfreaks.net/comment/2210746#comment-2210746

... where Lee posted a screenshot of the datasheet:

No SBIW (or ADIW) in sight.

Lee:  what version of the datasheet was that, and where did you get it?

Some other inconsistencies:

• the break instruction shows up in the datasheet, but the t104 doesn't support debugging.
• the Microchip product page for the t104 has links to appnotes for EEPROM, but the t104 has no EEPROM

I'm forced to wonder if the t104 actually has lpm.  Since it apparently can self-program flash, surely it can also read flash for verification purposes?

However, I also see that all NVM memories are mapped to data address space, with flash at 0x4000, so perhaps there is no lpm after all, and this is the only way to access flash?:

(NOTE: This would also appear to be one of the new tinies which does not map GP registers into the the data address space.)

This map is consistent with what @SprintSB has said:

The old toolchains won't complain properly, and I'd recomment you use gcc v7.2  + binutils 2.29+.

As a test, when you compile code like the following

__attribute((externally_visible))
const int a = 1;
const int * volatile p;

int main()
{
    p = &a;
    return *p;
}

The map file should look something like this:

.rodata         0x000000000000404a        0x2 load address 0x000000000000004a
 *(.rodata)
 .rodata        0x000000000000404a        0x2 memc.elf.ltrans0.ltrans.o
                0x000000000000404a                a

i.e. "a" is located after 0x4000.  This means .rodata lives in flash and you can drop progmem and similar hacks without any overhead.

Am I to conclude that the use of const is enough to place data into flash?  Or is:

__attribute((externally_visible))

... also required?

It would appear that neither of these is sufficient, at least prior to gcc v7.2.  Note that the code examples I used above were built with 3.5.4 (4.9.2).  I tried moving the declaration of foo[] out of main():

__attribute((externally_visible))
const uint8_t foo[] = {
  0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, 0x80
};

... but building shows that it stays in SRAM:

0000002c <__do_copy_data>:
  2c:	20 e0       	ldi	r18, 0x00	; 0
  2e:	a0 e4       	ldi	r26, 0x40	; 64
  30:	b0 e0       	ldi	r27, 0x00	; 0
  32:	e6 e7       	ldi	r30, 0x76	; 118
  34:	f0 e4       	ldi	r31, 0x40	; 64
  36:	02 c0       	rjmp	.+4      	; 0x3c <__CCP__>
  38:	31 91       	ld	r19, Z+
  3a:	3d 93       	st	X+, r19
  3c:	a8 34       	cpi	r26, 0x48	; 72
  3e:	b2 07       	cpc	r27, r18
  40:	d9 f7       	brne	.-10     	; 0x38 <__do_copy_data+0xc>
  42:	02 d0       	rcall	.+4      	; 0x48 <main>
  44:	16 c0       	rjmp	.+44     	; 0x72 <_exit>

    for (bar=0; bar<sizeof(foo); bar++) {
      PORTA = foo[bar];
  52:	41 91       	ld	r20, Z+
  54:	42 b9       	out	0x02, r20	; 2

I get the same result with 3.6.1 (5.4.0).

I'd recomment you use gcc v7.2  + binutils 2.29+.

What version of the toolchain (and each component) ships with AS7?  Has that version been built for Linux by Atmel/Microchip?  I suppose not, but maybe the source is available somewhere?  Or I guess I'll likely have to 'round and gather all the pieces myself and muddle through a build.

Can anyone who has AS7 try out some of the code in this post and report back here?

EDIT:  corrected incorrect screenshot from Lee's post

In general I have to say the quality of the datasheet for the t104 is quite low.  I've found a growing list of errors, including a reference to MCUCR, which doesn't exist in that device, for the PUD bit, which doesn't exist in that device.  There are other lies, like "If PORTxn is written to '1' when the pin is configured as an input pin, the pull-up resistor is activated."

In reality, pull-ups are handled via a new set of registers, PUEx.

Even the code example reference by @gchapman above gets this wrong:

int main(void) {
  /* enable the pull-up function */
  PUEB |= 1<<PORTB1;

  /* enable pull-up for button */
  PORTB |= 1<<PORTB1;

  /* configure LED pin as output */
  DDRA |= 1<<DDRA5;
  while(1) {
    /* check the button status (press - 0 , release - 1 ) */
    if(!(PINB & (1<<PINB1))) {
      /*switch on the LED until button is pressed */
      PORTA &= ~(1<<PORTA5);
    }
    else {
      /* switch off the LED if button is released*/
      PORTA |= 1<<PORTA5;
    }
  }
}

... even though they got it right in the previous line!

The explanation following the code example in the PDF is also full of errors:

7. Code explanation:
– The application uses the mechanical button and yellow LED of ATtiny104 Xplained Nano kit. They are connected to Port Pin PB1 and PA5, respectively.
– Each PORT has three registers; DDRx, PORTx, and PINx.
– The DDRx register is used to configure the port pin direction.
  • 1 - Output
  • 0 - Input
– The kit does not have pull-up resisters onboard and hence internal pull-up has to be enabled for the button.
– Configure the PUEx register to enable internal pull-up of the corresponding port pin.
– When a pin is configured as input and the respective bit in PORTx is written logic one, the respective pin is internally pulled up.
– The PINx register is used to return the logic level available on the port pin.
– The button connected to pin PB1 is configured as input with pull-up enabled. LED connected to Pin PA5 is configured as output.
– The LED is controlled based on the button status. When the button is not pressed the LED will not glow. When pressing the button the LED will glow.

 

Micromel have got to get their act together and hire some real technical writers, instead of copy-paste-happy college interns who have done the work in the past.

Having got the blinky to build, I moved on to the original app I had intended to port.  It builds fine with PROGMEM, and the disassembly looks to be correct.  HOWEVER, the code generation is exceedingly inefficient:

#define ADC_HIST_SZ 64
.
.
.
static uint8_t moving_avg(uint16_t sample) {

  static uint16_t hst[ADC_HIST_SZ];
  static uint16_t tot;
  static uint8_t  idx;

  tot      = tot + sample - hst[idx];
  hst[idx] = sample;
  idx      = (idx + 1) % ADC_HIST_SZ;

  return tot / (ADC_HIST_SZ * 4);

}

EDIT: Let's put aside for the moment the fact that the t104 has only 32 bytes of SRAM, and that the above #define would call for 128 bytes ;-)

00000150 <moving_avg>:
}

// Compute moving average based on new sample
uint8_t moving_avg(uint16_t sample) {
 150:	3f 93       	push	r19
 152:	cf 93       	push	r28
 154:	df 93       	push	r29

  static uint16_t hst[ADC_HIST_SZ];
  static uint16_t tot;
  static uint8_t  idx;

  tot      = tot + sample - hst[idx];
 156:	c1 e8       	ldi	r28, 0x81	; 129
 158:	d0 e0       	ldi	r29, 0x00	; 0
 15a:	38 81       	ld	r19, Y
 15c:	e3 2f       	mov	r30, r19
 15e:	f0 e0       	ldi	r31, 0x00	; 0
 160:	ee 0f       	add	r30, r30
 162:	ff 1f       	adc	r31, r31
 164:	ef 5b       	subi	r30, 0xBF	; 191
 166:	ff 4f       	sbci	r31, 0xFF	; 255
 168:	40 81       	ld	r20, Z
 16a:	ef 5f       	subi	r30, 0xFF	; 255
 16c:	ff 4f       	sbci	r31, 0xFF	; 255
 16e:	50 81       	ld	r21, Z
 170:	e1 50       	subi	r30, 0x01	; 1
 172:	f0 40       	sbci	r31, 0x00	; 0
 174:	68 2f       	mov	r22, r24
 176:	79 2f       	mov	r23, r25
 178:	64 1b       	sub	r22, r20
 17a:	75 0b       	sbc	r23, r21
 17c:	a2 e8       	ldi	r26, 0x82	; 130
 17e:	b0 e0       	ldi	r27, 0x00	; 0
 180:	4c 91       	ld	r20, X
 182:	af 5f       	subi	r26, 0xFF	; 255
 184:	bf 4f       	sbci	r27, 0xFF	; 255
 186:	5c 91       	ld	r21, X
 188:	a1 50       	subi	r26, 0x01	; 1
 18a:	b0 40       	sbci	r27, 0x00	; 0
 18c:	46 0f       	add	r20, r22
 18e:	57 1f       	adc	r21, r23
 190:	4d 93       	st	X+, r20
 192:	5c 93       	st	X, r21
  hst[idx] = sample;
 194:	81 93       	st	Z+, r24
 196:	90 83       	st	Z, r25
  idx      = (idx + 1) % ADC_HIST_SZ;
 198:	3f 5f       	subi	r19, 0xFF	; 255
 19a:	3f 71       	andi	r19, 0x1F	; 31
 19c:	38 83       	st	Y, r19

  return tot / (ADC_HIST_SZ * 4);
 19e:	84 2f       	mov	r24, r20
 1a0:	95 2f       	mov	r25, r21
 1a2:	88 0f       	add	r24, r24
 1a4:	89 2f       	mov	r24, r25
 1a6:	88 1f       	adc	r24, r24
 1a8:	99 0b       	sbc	r25, r25
 1aa:	91 95       	neg	r25

}
 1ac:	df 91       	pop	r29
 1ae:	cf 91       	pop	r28
 1b0:	3f 91       	pop	r19
 1b2:	08 95       	ret

It gets worse when the function is made static and therefore inlined.

I know that the AVR backend has been getting shafted as a result of changes made to benefit ARM and x86, but this is terrible.  It's bad for other AVR as well, but it just hurts so much more on a 1K device.

I may have to go with asm, but this is for a 3rd party who will own the source code, and the preference/requirement is that it be in C.  I may have to do some convincing... either of the client, or of the compiler ;-)

Some attempts at convincing the compiler by using local copies of static variables helps, but there seems to be an insistence on using indexed addressing for what could be done with lds or sts.  Does the t104 really lack these instructions?  Or is the compiler just that stupid?

Did not search RHEL and Fedora (remainder of the Linux distributions that Microchip tests on)

Where did you see that?

joeymorin wrote:

EDIT: Let's put aside for the moment the fact that the t104 has only 32 bytes of SRAM, and that the above #define would call for 128 bytes ;-)

From #35.  No, I guess I can't put it aside--how can one complain about code generation for a fatuous example?

The app I'm porting had it #defined as 64 (for 128 bytes), but I can live with 8 (for 16 bytes).  The code I posted is unaffected, since it doesn't change with a lower define.  Only the divisor does.  Generated code is nearly identical.

If it were me, I'd build the real ported app and see how close it is to fitting.

I did.  It fits.  Not tested yet, nor validated for maximum stack usage.  I'm done for now, as I must wait for answers from the 3rd party before spending any more time on this.  Thanks.

EDIT:  typo.

The best fit is -mmcu=avrtiny which supports none of the instructions above

Got it.

the worst lost being LDD and STD addressing being no more available.

 

If the datasheed is correct, then ATtiny102/4 is more similar to AT90S2313 or ATtiny26 from avr2 family, but with only 16 GPRs and 16-bit LDS/STS.  To my knowledge, neither gcc, binutils nor avr-libc support such a device family.  So much for coverage :-P

Indeed!

Again, many thanks.