AVR Freaks

I change your code into something that would actually build:

#include<avr/io.h>
#include <avr/interrupt.h>

void HardwareInterface(unsigned char) __attribute__((naked));

void HardwareInterface(unsigned char DataForStuff)

{    cli();              // disable interrupts until all LEDs updated
       asm volatile
       ("     LDI R18, 0x00\n"          // Useful comment
          "label:\n"
              "OUT 0x04, R18\n"         // Useful comment
                   //Blah blah blah lots of lovely assembler >>>>
             "OUT 0x0A, R18\n"         // Useful comment
      );

      sei();            // Update complete > re-enable_interrupts
      return ;
}

int main () {
    HardwareInterface(0x55);
    HardwareInterface(0xAA);
}

and got:

00000022 <HardwareInterface>:

void HardwareInterface(unsigned char) __attribute__((naked));

void HardwareInterface(unsigned char DataForStuff)

{    cli();              // disable interrupts until all LEDs updated
  22:   f8 94           cli
       asm volatile
  24:   20 e0           ldi     r18, 0x00       ; 0

00000026 <label>:
  26:   24 b9           out     0x04, r18       ; 4
  28:   2a b9           out     0x0a, r18       ; 10
              "OUT 0x04, R18\n"         // Useful comment
                   //Blah blah blah lots of lovely assembler >>>>
             "OUT 0x0A, R18\n"         // Useful comment
      );

      sei();            // Update complete > re-enable_interrupts
  2a:   78 94           sei

0000002c <main>:
      return ;
}

int main () {
    HardwareInterface(0x55);
  2c:   85 e5           ldi     r24, 0x55       ; 85
  2e:   f9 df           rcall   .-14            ; 0x22 <HardwareInterface>
    HardwareInterface(0xAA);
  30:   8a ea           ldi     r24, 0xAA       ; 170
  32:   f7 df           rcall   .-18            ; 0x22 <HardwareInterface>
}
  34:   80 e0           ldi     r24, 0x00       ; 0
  36:   90 e0           ldi     r25, 0x00       ; 0
  38:   08 95           ret

This shows why "naked" was wrong - the invocations in main() call (actually rcall) to 0x0022 but the code there has no RET. I imagine you meant:

void HardwareInterface(unsigned char) __attribute__((always_inline));

in which case the result is:

D:\atmel_avr\avr8-gnu-toolchain-win32_x86\bin>avr-gcc -mmcu=attiny13 -Os -save-temps -g avr.c -o avr.elf
avr.c:6:6: warning: always_inline function might not be inlinable [-Wattributes]
 void HardwareInterface(unsigned char DataForStuff)
      ^
avr.s: Assembler messages:
avr.s:65: Error: symbol `label' is already defined
avr.s:88: Error: symbol `label' is already defined

which is a shame :-(

Those errors being:

main:
.LFB1:
	.loc 1 21 0
	.cfi_startproc
/* prologue: function */
/* frame size = 0 */
/* stack size = 0 */
.L__stack_usage = 0
.LVL1:
.LBB6:
.LBB7:
	.loc 1 8 0
/* #APP */
 ;  8 "avr.c" 1
	cli
 ;  0 "" 2
	.loc 1 9 0
 ;  9 "avr.c" 1
	     LDI R18, 0x00
label:
OUT 0x04, R18
OUT 0x0A, R18

 ;  0 "" 2
	.loc 1 17 0
 ;  17 "avr.c" 1
	sei
 ;  0 "" 2
.LVL2:
/* #NOAPP */
.LBE7:
.LBE6:
.LBB8:
.LBB9:
	.loc 1 8 0
/* #APP */
 ;  8 "avr.c" 1
	cli
 ;  0 "" 2
	.loc 1 9 0
 ;  9 "avr.c" 1
	     LDI R18, 0x00
label:
OUT 0x04, R18
OUT 0x0A, R18

 ;  0 "" 2
	.loc 1 17 0
 ;  17 "avr.c" 1
	sei
 ;  0 "" 2
.LVL3:
/* #NOAPP */
.LBE9:
.LBE8:
	.loc 1 24 0
	ldi r24,0
	ldi r25,0
	ret

As opposed to what? How would other approaches not be "part of the project structure"?

'Doxygen' will pick up the tags, etc 

Again, what would prevent that?

 it's something that will eventually go up someone bottom!

So, if you get fed up with this contract, you really can tell them where to stick it!

Eh?

You said:

I would prefer this way of adding the mnemonic code as it is still part of the project structure

I was asking why any other method would be any less "part of the project format" ?

And also why you feel that one method will work better than another as far as Doxygen is concerned.

To me, those assertions appear to be non-sequiturs.

See #2 and #5.

EDIT

Also #13 - and example of assembler code being called from HLLs

I had been under the impression that Doxygen was language-agnostic.

Given #18, if Doxygen is the key concern, then I now see what you mean about that!

You need a declaration AND a definiition.

SREG is definitely already defined, ideas?

You are misunderstanding what asm()  does it literally just says "take all this following text and paste it into the .s file before you assemble it". By the time you have reached .s all preprocessing is over and a macro like SREG will not be expanded. Instead the assembler expects SREG to be a symbol location.

This is why I suggest writing an actual assembler source module - rather than faffing with all these arcane details of inline assembler ...

Likewise.

The only downside is the (R)CALL/RET overhead.

so make the C/assembler partitioning at a suitable point that this is not a problem ?

How could it possibly do that?

The definition is the code of your function - how could an IDE possibly know what code you were going to write within your function?!

#2 I didn't realise that 'SREG' was a macro I thought it was just the Status register (0x5f)

That's right: as far as the code goes, "the status register" is just an address - 0x5F.

The macro - "SREG" - just give a human-meaningful name for that address.

OK, then:  

asm("out PORTD, R24");

When you do that this happens:

D:\atmel_avr\avr8-gnu-toolchain-win32_x86\bin>type avr.c
#include <avr/io.h>

int main(void) {
    while(1) {
        asm("\tout PORTD, r24\n");
    }
}

D:\atmel_avr\avr8-gnu-toolchain-win32_x86\bin>avr-gcc -c -save-temps -mmcu=atmega16 -Os avr.c -o avr.o

D:\atmel_avr\avr8-gnu-toolchain-win32_x86\bin>type avr.s
        .file   "avr.c"
__SP_H__ = 0x3e
__SP_L__ = 0x3d
__SREG__ = 0x3f
__tmp_reg__ = 0
__zero_reg__ = 1
        .section        .text.startup,"ax",@progbits
.global main
        .type   main, @function
main:
/* prologue: function */
/* frame size = 0 */
/* stack size = 0 */
.L__stack_usage = 0
.L2:
/* #APP */
 ;  5 "avr.c" 1
                out PORTD, r24

 ;  0 "" 2
/* #NOAPP */
        rjmp .L2
        .size   main, .-main
        .ident  "GCC: (AVR_8_bit_GNU_Toolchain_3.6.1_1752) 5.4.0"

This is the very source that will be passed to avr-as. When I let that happen this happens:

D:\atmel_avr\avr8-gnu-toolchain-win32_x86\bin>avr-gcc -save-temps -mmcu=atmega16 -Os avr.c -o avr.elf
avr.o: In function `main':
avr.c:(.text.startup+0x0): undefined reference to `PORTD'
collect2.exe: error: ld returned 1 exit status

That's because "PORTD" has actually been entered into a file that will NOT be pre-processed. So there's no chance of that macro being expanded out (and even if it were it's defined as a C style dereference of a volatile uint8_t pointer which won't mean anything to the assembler either!). So you have to use:

asm("out %0, R24"::  "I" (_SFR_IO_ADDR(PORTD)) : "R24");

That then gives:

D:\atmel_avr\avr8-gnu-toolchain-win32_x86\bin>type avr.c
#include <avr/io.h>

int main(void) {
    while(1) {
        asm("\tout %0, R24\n"::  "I" (_SFR_IO_ADDR(PORTD)) : "r24");
    }
}

D:\atmel_avr\avr8-gnu-toolchain-win32_x86\bin>avr-gcc -save-temps -mmcu=atmega16 -Os avr.c -o avr.elf

D:\atmel_avr\avr8-gnu-toolchain-win32_x86\bin>type avr.s
        .file   "avr.c"
__SP_H__ = 0x3e
__SP_L__ = 0x3d
__SREG__ = 0x3f
__tmp_reg__ = 0
__zero_reg__ = 1
        .section        .text.startup,"ax",@progbits
.global main
        .type   main, @function
main:
/* prologue: function */
/* frame size = 0 */
/* stack size = 0 */
.L__stack_usage = 0
.L2:
/* #APP */
 ;  5 "avr.c" 1
        out 18, R24
 ;  0 "" 2
/* #NOAPP */
        rjmp .L2
        .size   main, .-main
        .ident  "GCC: (AVR_8_bit_GNU_Toolchain_3.6.1_1752) 5.4.0"

So all of that simply to get an "out 18, r24" built into the code!!

This is why I despise these mystic runes of inline asm and personally I would do:

D:\atmel_avr\avr8-gnu-toolchain-win32_x86\bin>type asm.S
#define __SFR_OFFSET 0
#include <avr/io.h>

    .global foo

foo:
    out PORTB, r24
    ret
D:\atmel_avr\avr8-gnu-toolchain-win32_x86\bin>type avr.c
#include <avr/io.h>

void foo(void);

int main(void) {
    while(1) {
        foo();
    }
}

D:\atmel_avr\avr8-gnu-toolchain-win32_x86\bin>avr-gcc -mmcu=atmega16 -Os avr.c asm.S -o avr.elf

D:\atmel_avr\avr8-gnu-toolchain-win32_x86\bin>avr-objdump -S avr.elf

avr.elf:     file format elf32-avr

Disassembly of section .text:

00000000 <__vectors>:
   0:   0c 94 2a 00     jmp     0x54    ; 0x54 <__ctors_end>
   4:   0c 94 34 00     jmp     0x68    ; 0x68 <__bad_interrupt>
   8:   0c 94 34 00     jmp     0x68    ; 0x68 <__bad_interrupt>
   c:   0c 94 34 00     jmp     0x68    ; 0x68 <__bad_interrupt>
  10:   0c 94 34 00     jmp     0x68    ; 0x68 <__bad_interrupt>
  14:   0c 94 34 00     jmp     0x68    ; 0x68 <__bad_interrupt>
  18:   0c 94 34 00     jmp     0x68    ; 0x68 <__bad_interrupt>
  1c:   0c 94 34 00     jmp     0x68    ; 0x68 <__bad_interrupt>
  20:   0c 94 34 00     jmp     0x68    ; 0x68 <__bad_interrupt>
  24:   0c 94 34 00     jmp     0x68    ; 0x68 <__bad_interrupt>
  28:   0c 94 34 00     jmp     0x68    ; 0x68 <__bad_interrupt>
  2c:   0c 94 34 00     jmp     0x68    ; 0x68 <__bad_interrupt>
  30:   0c 94 34 00     jmp     0x68    ; 0x68 <__bad_interrupt>
  34:   0c 94 34 00     jmp     0x68    ; 0x68 <__bad_interrupt>
  38:   0c 94 34 00     jmp     0x68    ; 0x68 <__bad_interrupt>
  3c:   0c 94 34 00     jmp     0x68    ; 0x68 <__bad_interrupt>
  40:   0c 94 34 00     jmp     0x68    ; 0x68 <__bad_interrupt>
  44:   0c 94 34 00     jmp     0x68    ; 0x68 <__bad_interrupt>
  48:   0c 94 34 00     jmp     0x68    ; 0x68 <__bad_interrupt>
  4c:   0c 94 34 00     jmp     0x68    ; 0x68 <__bad_interrupt>
  50:   0c 94 34 00     jmp     0x68    ; 0x68 <__bad_interrupt>

00000054 <__ctors_end>:
  54:   11 24           eor     r1, r1
  56:   1f be           out     0x3f, r1        ; 63
  58:   cf e5           ldi     r28, 0x5F       ; 95
  5a:   d4 e0           ldi     r29, 0x04       ; 4
  5c:   de bf           out     0x3e, r29       ; 62
  5e:   cd bf           out     0x3d, r28       ; 61
  60:   0e 94 38 00     call    0x70    ; 0x70 <main>
  64:   0c 94 3b 00     jmp     0x76    ; 0x76 <_exit>

00000068 <__bad_interrupt>:
  68:   0c 94 00 00     jmp     0       ; 0x0 <__vectors>

0000006c <foo>:
  6c:   88 bb           out     0x18, r24       ; 24
  6e:   08 95           ret

00000070 <main>:
  70:   0e 94 36 00     call    0x6c    ; 0x6c <foo>
  74:   fd cf           rjmp    .-6             ; 0x70 <main>

00000076 <_exit>:
  76:   f8 94           cli

00000078 <__stop_program>:
  78:   ff cf           rjmp    .-2             ; 0x78 <__stop_program>

But, like I say, for this you pay the price of a CALL (if I'd used -mrelax that would have been RCALL).

But in .S you get to write Asm that actually looks like Asm.

Actually I screwed up my runes in #36. The PORTD was supposed to be in the output list not the input list apparently. I did wonder what I got "18" and not "0x18" !!

Even now I'm not sure what the convoluted syntax was supposed to be - life (well my life) is too short to bother trying to learn GCCs inline asm syntax!

Ha ha - hadn't spotted that one!

As noted in #2, Atmel studio (being based on MS Visual Studio) has no problem with mixed-language projects.

Top hit for just googling, "atmel studio mix assembler":

APPLICATION NOTE Atmel AT1886:

Mixing Assembly and C with AVRGCC 8-bit Atmel Microcontrollers 

 

Features

• Easily mix C and assembly source in Atmel® Studio 6

• C can call assembly routines

• Assembly can call C functions

• Passes variables and pointers between C and assembly

• Allows C and assembly to share global variables 

 

http://ww1.microchip.com/downloads/en/appnotes/doc42055.pdf

Go on, then - what errors, exactly?