Trouble while removing deprecated macros

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

I have the latest version of WinAVR installed and run in some trouble when I tried to remove deprecated macros from old code to be compatible with the new version.

The code uses #define _SFR_ASM_COMPAT 1

And when I replcace the old outp macro with something like this:

PORTA = 0xff;

I get compiler errors like this: error: invalid lvalue in assignment

From the avr-libc documentation I tried also #define __SFR_OFFSET 0
but result is the same error.

[Added]
One more question:

to replace:

bLoudness = eeprom_rb(EEPROM_LOUDNESS) & 0x8f;

I use the following code:

bLoudness = eeprom_read_byte((u08 *)EEPROM_LOUDNESS) & 0x8f;

no problem so far.
But when I replace:

curIndex = eeprom_rw(EEPROM_SONGPOS);

with

curPlaylist = eeprom_read_word((u16 *)EEPROM_PLAYLIST);

I get the error:
1939: warning: passing arg 1 of `eeprom_read_word' from incompatible pointer type

How can I fix this errors?

Last Edited: Wed. Feb 16, 2005 - 08:53 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Mr MIC wrote:

curPlaylist = eeprom_read_word((u16 *)EEPROM_PLAYLIST);

I get the error:
1939: warning: passing arg 1 of `eeprom_read_word' from incompatible pointer type

How can I fix this errors?

Take a look at how the functions are declared. eeprom_read_word wants a pointer to a const uint16_t. See if this helps:

curPlaylist = eeprom_read_word((const u16 *)EEPROM_PLAYLIST);

BTW, that's what eeprom_read_byte wants too, but you didn't say that you got that error with that call, so... :?:

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

Ok, tried:

curPlaylist = eeprom_read_word((const u16 *)EEPROM_PLAYLIST); 

Warning still exists.
But there is NO warning for :

eeprom_read_byte((u08 *)EEPROM_AUTOPLAY)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How do you define EEPROM_PLAYLIST compared to how you define EEPROM_AUTOPLAY?

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

EEPROM memory structure is defined like this:

// EEPROM structure

#define EEPROM_VOLUME		0x010	// 1 byte - volume
#define EEPROM_AUTOPLAY		0x011	// 1 byte - autoplay flag
#define EEPROM_RANDOM		0x012  	// 1 byte
#define EEPROM_SONGPOS		0x013	// 2 bytes - last song number
#define EEPROM_LOUDNESS		0x015  	// 1 byte
#define EEPROM_IRSTAND		0x016	// 1 byte - standard of remote codes
#define EEPROM_PLAYLIST		0x017	// 2 bytes - last song number
#define EEPROM_REPEAT		0x019  	// 1 byte
#define EEPROM_TIME		0x01A  	// 1 byte
#define EEPROM_BALANCE		0x01B  	// 1 byte
#define EEPROM_STARTPOS		0x01C	// 2 bytes - position inside song

#define EEPROM_RemCodes		0x020	// each code - 2 bytes

Any solutions for the first problem? (_SFR_ASM_COMPAT)

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

Mr MIC wrote:

Any solutions for the first problem? (_SFR_ASM_COMPAT)

See this:
http://www.nongnu.org/avr-libc/u...

According to the manual page above, when you defined that to 1, you made all the register names as constants, hence they are no longer valid lvalues, so you can't assign to them.

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

Thanks, seems I missed the point when looked at this notes. Problem is fixed with _SFR_ASM_COMPAT undefined. Code works well without. (Btw: It's not my own code, so I'm not sure why it was defined at all)

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

Oh, well that epxlains it. You're usually on top of things. ;)

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

I'm going to make the code for Jespers Yampp compatible with latest WinAVR. Dealing with two avr-libc version (one quite old for the original code) on one system is annoying.

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

Quote:

curPlaylist = eeprom_read_word((u16 *)EEPROM_PLAYLIST);

I get the error:
1939: warning: passing arg 1 of `eeprom_read_word' from incompatible pointer type

Problems with compiler warnings fixed :D , I found that 'u16' was declared as 'unsigned short', changing to 'unsigned int' solved all problems.

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

Really, you should (or Jesper should) use
#include
or
#include
since both of those are standard header files and use:
uint8_t
uint16_t
uint32_t
int8_t
int16_t
int32_t
etc.

And those are standard typedefs.

It's practically stupid these days to roll one's own fixed width types when they're freely available and standard.