warning by calling eeprom_read_byte()

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

Hi,

The definition of eeprom_read_byte() is

uint8_t eeprom_read_byte (const uint8_t _addr)

I call this function with

eeprom_read_byte(4)

but get a warning:

warning: passing arg 1 of `eeprom_read_byte' makes pointer from integer without a cast

How can I avoid this?

Thank you.

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

typecast the 4 to be of the right type. In fact your prototype above is wrong, the parm is a pointer to const uint8_t and not just a const uint8_t value.

This works:

byte_read = eeprom_read_byte((const uint8_t *)4);

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

Hi,

Thank you for your answer. What about

void eeprom_read_block (void * pointer_ram, const void * pointer_-eeprom, size_t n)

?

Should I call this function with

eeprom_read_block(…, (const void *)4, …)

or

eeprom_read_block(…, (const uint8_t *)4, …)

?

Thank you.

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

Well in that case, because it's expecting a void pointer (in other words, a pointer to ANYTHING you like!) I'd just go with:

	eeprom_read_block(buffer, (void *)4, 16);

OK, I know this drops the 'const' qualifier even but the fact is that you can get away with this.

Cliff

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

Thank you for your answer.
That works fine for me but for one case. If I call this function like this:

eeprom_read_block(…, (void *)(ByteCount+2), …)

;
ByteCount is defined with UINT32 ByteCount.

I get another warning:

warning: cast to pointer from integer of different size.

Is a variable allowed at this place?

Thank you.

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

That warning is thrown because all pointer types are restricted to 16-bits in avr-gcc. You're converting from a 32-bit scalar value, so some significant bits will be truncated in the process of converting from 32-bits to 16-bits.

If you switch ByteCount to a UINT16 type, the warning will go away.

Is there a particular reason why you are accessing EEPROM using hard-coded addresses, rather than using the EEMEM attribute on named variables to manage your static EEPROM memory allocation automatically?

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

Thank you. I would like to use the way of EEMEM but could not find any reference to this topic. I suppose the functions like eeprom_read_byte() and eeprom_write_byte() should not be used any more if EEMEM takes power. Could you please tell me where to find some references?

Best Regards

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

I wrote up a tutorial on using the EEMEM attribute:

https://www.avrfreaks.net/index.p...

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!