Portability macros

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

Are the portability macros (such as STORE/LOAD) distributed with WINAVR? Just wondereing if I'm just being redundant by keeping my own macro header file.

Thanks,
Mike

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

Which portability macros are you referring to?

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

Example:

.macro  STORE addr,reg
    .if     \addr < 0x60
     out    \addr - 0x20,\reg
    .else
     sts    \addr,\reg
    .endif
.endm

.macro  LOAD reg,addr
    .if     \addr < 0x60
     in     \reg,\addr - 0x20
    .else
     lds    \reg,\addr
    .endif
.endm 

These are for the gcc assembler.
There are also others for bit set/clr etc. that match Atmels macro.inc file. Just wondering if these ever became an official part of the distro?

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

Eric,

Just in case it's not clear he's talking about Atmel App Note AVR001:

http://www.atmel.com/dyn/resourc...
http://www.atmel.com/dyn/resourc...

;*****************************************************************
;*	file: macros.inc
;*
;*	Description:
;*	Source file for application note AVR001 - Conditional Assembly
;*	and Portability Macros.
;*
;*	Defines a number of macros that makes it easier to access
;*	IO registers and extended IO registers (or SRAM locations up
;*  to adress $FF if applicable).
;*	The macros can be used to produce code that assembles to
;*	any target AVR, without considering if the accessed IO
;*	registers are located in low, standard or extended IO space
;*
;* $Revision: 2.2 $	
;* $Author: jllassen $
;* $Date: Wednesday, January 26, 2005 10:55:18 UTC $
;*****************************************************************

;*********************************************************
;*	BIT access anywhere in IO or lower $FF of data space
;*	SETB - SET Bit in IO of data space
;*	CLRB - CLeaR Bit in IO of data space
;*********************************************************

.MACRO SETB 		;Arguments: Address, Bit, Register
	.if @1>7
		.message "Only values 0-7 allowed for Bit parameter"
	.endif
	.if @0>0x3F
		lds  @2, @0
		sbr  @2, (1<<@1)
		sts  @0, @2
	.elif @0>0x1F
		in   @2, @0
		sbr  @2, (1<<@1)
		out  @0, @2
	.else
		sbi  @0, @1
	.endif
.ENDMACRO

.MACRO CLRB 		;Arguments: Address, Bit, Register
	.if @1>7
		.message "Only values 0-7 allowed for Bit parameter"
	.endif
	.if @0>0x3F
		lds  @2, @0
		cbr  @2, (1<<@1)
		sts  @0, @2
	.elif @0>0x1F
		in   @2, @0
		cbr  @2, (1<<@1)
		out  @0, @2
	.else
		cbi  @0, @1
	.endif
.ENDMACRO

;*********************************************************
;*	Bit test anywhere in IO or in lower $FF of data space
;*  SKBS : SKip if Bit Set
;*  SKBC : SKip if Bit Cleared
;*********************************************************
.MACRO SKBS  		;Arguments: Address, Bit, Register
	.if @1>7
		.message "Only values 0-7 allowed for Bit parameter"
	.endif
	.if @0>0x3F
		lds  @2, @0
		sbrs @2, @1
	.elif @0>0x1F
		in   @2, @0
		sbrs @2, @1
	.else
		sbis @0, @1
	.endif
.ENDMACRO

.MACRO SKBC  		;Arguments: Address, Bit, Register
	.if @1>7
		.message "Only values 0-7 allowed for Bit parameter"
	.endif
	.if @0>0x3F
		lds	 @2, @0
		sbrc @2, @1
	.elif @0>0x1F
		in	 @2, @0
		sbrc @2, @1
	.else
		sbic @0, @1
	.endif
.ENDMACRO

;*********************************************************
;*	Byte access anywhere in IO or lower $FF of data space
;* 	STORE - Store register in IO or data space
;* 	LOAD  - Load register from IO or data space
;*********************************************************

.MACRO STORE 		;Arguments: Address, Register
	.if	@0>0x3F
		sts	@0, @1
	.else
		out	@0, @1
	.endif
.ENDMACRO

.MACRO LOAD 		;Arguments: Register, Address
	.if	@1>0x3F
		lds	@0, @1
	.else
		in	@0, @1
	.endif
.ENDMACRO

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

I guess I can take the lack of a courtesy reply to mean the answer is no.

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

Does not C take care of this, behind the scenes?

When you write

IORegister = value;

It does not matter where, in memory space, the IORegister is located.

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

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

Quote:
Does not C take care of this, behind the scenes?

C does but if you add inline asm. or as an .S file then the memory space can bite you hard. :)

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

CirMicro,

Given that the .h files are not really suitable for .S use anyway (requiring the use of _SFR_IO_ADDR() on those that are within 0x00..0x3F range) then I'd have said this was the least of your worries. You already have to make the decision whether to access via that macro which already differentiates the IN/OUTs from the LDS/STSs

I guess it would be nice if there were a composite macro that made the IN/OUT or LDS/STS decision and also invoked _SFR_IO_ADDR() as necessary.

All AVR-LibC contributions are welcome.

Cliff

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

Exactly, the SFR_IO_ADDR() issue makes it even more useful to have the macros. I have been using the same macros for a while now. I think they are fairly standard these days which is why I thought they may be part of the distro by now.

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

Quote:

I think they are fairly standard

You mean they are "published" somewhere? If so where, by who and under what redistribution licence. To be included in AVR-LibC they have to signed over to some none binding licence type ("Beerware", FreeBSD, etc). To actually be included in AVR-LibC it doesn't just "happen by magic". Someone has to actually contribute them to the project. You do that by raising an issue on Savannha against the AVR-LibC project. The contribution is then reviewd by peers (and discussed on the avr-libc-developers mailing list) and if accepted it's added into the CVS on Sourceforge for the AVR-LibC project.

This is the nature of open source software - everyone is at liberty to suggest bug fixes, modifications and new features - but SOMEONE has to start the ball rolling or nothing would ever change.

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

Have another one for me ;)