static program memory constants in include file

Projects General Guidance
1

I have quite a few progmem constants in my sketch and am thinking about making an include file to keep them all in one place for easier debug. However, this means they will be accessible globally. Is this a bad approach or does it matter since it is stored in progmem anyway? Some functions that I would link to this include file will not use all of the constants so I am concerned that perhaps performance may suffer.

Here is an excerpt of the include file:

#include "Arduino.h"

#include <avr/pgmspace.h>

static prog_uint8_t NUM0 PROGMEM=0;
static prog_uint8_t NUM1 PROGMEM=1;
static prog_uint8_t NUM2 PROGMEM=2;
static prog_uint8_t NUM3 PROGMEM=3;
static prog_uint8_t NUM4 PROGMEM=4;
static prog_uint8_t NUM5 PROGMEM=5;
static prog_uint8_t NUM6 PROGMEM=6;
static prog_uint8_t NUM7 PROGMEM=7;
static prog_uint8_t NUM8 PROGMEM=8;
static prog_uint8_t NUM9 PROGMEM=9;
static prog_uint8_t NUM10 PROGMEM=10;
static prog_uint8_t NUM11 PROGMEM=11;
static prog_uint8_t NUM12 PROGMEM=12;
static prog_uint8_t NUM20 PROGMEM=20;
static prog_uint8_t NUM40 PROGMEM=40;
static prog_uint8_t NUM64 PROGMEM=64;
static prog_uint8_t NUM100 PROGMEM=100;
static prog_uint8_t NUM255 PROGMEM=255;
2

The scope will not change if you put the include statement in the same place that the variable declarations were.

3

DavidOConnor:
The scope will not change if you put the include statement in the same place that the variable declarations were.

True.

Perhaps a better way to word my question:

Is there a downside to making a program memory constant global vs having it local to only those functions in which the constant is used?

4

memotick:

DavidOConnor:
The scope will not change if you put the include statement in the same place that the variable declarations were.

True.

Perhaps a better way to word my question:

Is there a downside to making a program memory constant global vs having it local to only those functions in which the constant is used?

Public and private writable variables are stored in SRAM and the c++ runtime code will create SRAM copies of non-PROGMEM variables at initialization of the program. PROGMEM therefore saves SRAM at the expense of a few more machine cycles, 4 (I believe) for each read only access.

Ray
Ray

5

If they were "static const" and NOT "PROGMEM", they would probably be completely optimized away in favor of "immediate mode" constant instructions, which are more efficient (spacewise) than PROGMEM, and MUCH more execution time efficient. Putting them in PROGMEM is probably not a good idea unless you need global access.

int led = 13;
static const char scled = 13;
static const char PROGMEM scpled = 13;
const char cled = 13;

00000130 <setup>:
;;; pinMode(led, OUTPUT)
 130:	80 91 00 01 	lds	r24, 0x0100
 134:	61 e0       	ldi	r22, 0x01	; 1
 136:	0e 94 89 01 	call	0x312	; 0x312 <pinMode>
;;; pinMode(scled, OUTPUT)
 13a:	8d e0       	ldi	r24, 0x0D	; 13
 13c:	61 e0       	ldi	r22, 0x01	; 1
 13e:	0e 94 89 01 	call	0x312	; 0x312 <pinMode>
;;; pinMode(pgm_read_byte(&scpled), OUTPUT)
 142:	e8 e6       	ldi	r30, 0x68	; 104
 144:	f0 e0       	ldi	r31, 0x00	; 0
 146:	e4 91       	lpm	r30, Z
 148:	8e 2f       	mov	r24, r30
 14a:	61 e0       	ldi	r22, 0x01	; 1
 14c:	0e 94 89 01 	call	0x312	; 0x312 <pinMode>
;;  pinMode(cled, OUTPUT)
 150:	8d e0       	ldi	r24, 0x0D	; 13
 152:	61 e0       	ldi	r22, 0x01	; 1
 154:	0e 94 89 01 	call	0x312	; 0x312 <pinMode>
 158:	08 95       	ret