avr/pgmspace.h - inconsistent API

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

Hi,

Seeing as the avr/pgmspace.h API goes to all the trouble of defining these types:

typedef void PROGMEM 	prog_void
typedef char PROGMEM 	prog_char
typedef unsigned char PROGMEM 	prog_uchar
typedef int8_t PROGMEM 	prog_int8_t
typedef uint8_t PROGMEM 	prog_uint8_t
typedef int16_t PROGMEM 	prog_int16_t
typedef uint16_t PROGMEM 	prog_uint16_t
typedef int32_t PROGMEM 	prog_int32_t
typedef uint32_t PROGMEM 	prog_uint32_t
typedef int64_t PROGMEM 	prog_int64_t
typedef uint64_t PROGMEM 	prog_uint64_t

...would it not make sense for the pgm_read_XXX macros to use names like uint8, uint16 etc. instead of byte, word etc?

Also, there is no pgm_read_XXX macro for reading a void* in program space. Seeing as prog_void is defined, shouldn't there be a corresponding read macro?

Matt.

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

Surely the intention of the more generic "byte" and "word" routines is that you read the item THEN cast your own interpretation onto it?

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

Yes, it would be nice to have them by default. However, it is very simple to #define your own.

Stealing Proteus doesn't make you an engineer.

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

Quote:
Surely the intention of the more generic "byte" and "word" routines is that you read the item THEN cast your own interpretation onto it?

I fail to see why this would be a good thing.
Quote:
Yes, it would be nice to have them by default. However, it is very simple to #define your own.

Well of course, the only reason I mention it is because it would be nice to have by default.

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

MattBucknall wrote:
Also, there is no pgm_read_XXX macro for reading a void* in program space. Seeing as prog_void is defined, shouldn't there be a corresponding read macro?

Wouldn't the logical read macro actually be a pgm_read_void, ie a read of a void from program memory (via a prog_void* pointer)? If so, it's sensible that it has been omitted because you cannot read the void that is pointed to by a void* - C specifically disallows any operations on void* other than casting to some other (usually pointer) type.

Perhaps what you're thinking of is use of a void** to read an object of type void*. That's OK, and you could make the corresponding typedefs and macros for such objects stored in program memory, but where do you draw the line? A void**** accessed through a void***** perhaps?

Christopher Hicks
==

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

Quote:
Wouldn't the logical read macro actually be a pgm_read_void

I didn't say anything about pgm_read_void. As the API currently stands, it defines prog_void, which I agree is a bit misleading.

As far as void references go, I can't even imagine what sort of hideous nightmare would require the use of void*** or worse!

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

Quote:
As far as void references go, I can't even imagine what sort of hideous nightmare would require the use of void*** or worse!
Indeed. I was just making a point!

CH
==