yet another program memory question

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

Hi, I had a look through the forums, but didn't find an answer to this one.

Sometimes I like to copy some data directly into ram, without having to give it a name. ie.

char buffer[10];
memcpy(buffer, (char[]){1, 2, 3, 4, 5, 6}, 6);

This works fine, but I want to source the data from program memory to save ram. I thought this would work:

memcpy_P(buffer, (prog_char[]){1, 2, 3, 4, 5, 6}, 6);

but this just puts junk into the buffer.

I also tried this one:

memcpy_P(buffer, (const PROGMEM char[]){1, 2, 3, 4, 5, 6}, 6);

but this actually causes the compiler to crash, and asks me to submit a full bug report, which I don't really want to do.

Does somebody know how I can do this?
I basically want something like PSTR() only using a list of literals instead of a string.

Regards
, Michael.

Telling yourself something is too hard, or too complicated, is not a determination. It is a decision.

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

Have you read the thread on the PROGMEM attribute in the tutorials forum?

Regards,
Steve A.

The Board helps those that help themselves.

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

Yep.

Telling yourself something is too hard, or too complicated, is not a determination. It is a decision.

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

Pulling data out from program memory space must use pgm_read_byte(&yourconst);
maybe simple like this:

const char yourconst[10] PROGMEM = {1,2,3,4,5,6};
char[10] buffer = {0};

void main()
{
    uint8_t i=0;
    while(i<6)
        buffer[i]=pgm_read_byte(yourconst[i++]);
}

KISS - Keep It Simple Stupid!

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

Quote:
without having to give it a name

Gotta ask - what's the issue with simply naming the data?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
#include 
#include 
prog_uint8_t my_data[]= {1,2,3,4,5,6};
int main(){
    uint8_t buffer[10];
    memcpy_P(buffer,&my_data,6);
    while(1);
}
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Gotta ask - what's the issue with simply naming the data?
If one can't think of a good name for it,
one can still avoid the sniggers that might be induced by calling it fred.

Iluvatar is the better part of Valar.

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

Hello,

The casting cannot change the storage class of the array, it just changes the way others see it. Following the same scheme used in PSTR definition:

#define PDATA(type, ...) (__extension__({static type __nonamed[] PROGMEM = __VA_ARGS__ ; &__nonamed[0];}))
...
memcpy_P(buffer, PDATA(int, {1, 2, 3, 4, 5, 6}), 6 * sizeof(int));

Best regards,

Carlos.

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

Quote:
If one can't think of a good name for it,
one can still avoid the sniggers that might be induced by calling it fred

I thought all programmers used the internationally recognised 'foo' and 'bar' in fact? ;)

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

OT:

Quote:

I thought all programmers used the internationally recognised 'foo' and 'bar' in fact? Wink

Not FORTRAN programmers. They largely depend on the fact that anything named i,jk,l,m or n is an INTEGER by default. All others are REAL (or was that FLOAT?). That's all they think they need. Their mantra goes:

"If you can't do it in FORTRAN, then do it in assembler. If you can't do it in assembler, then its not worth doing"

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

carloslamas wrote:
Hello,

The casting cannot change the storage class of the array, it just changes the way others see it. Following the same scheme used in PSTR definition:

#define PDATA(type, ...) (__extension__({static type __nonamed[] PROGMEM = __VA_ARGS__ ; &__nonamed[0];}))
...
memcpy_P(buffer, PDATA(int, {1, 2, 3, 4, 5, 6}), 6 * sizeof(int));

Best regards,

Carlos.

Carlos!! you are a valuable man!!!
Thanks for your explanation and solution.
You are a true master of the squiggly brackets and underscores!

If anyone is still interested, in the meantime I have been doing this:

memcpy_P(tempbuf,PSTR("\x08\x03\x1A\x03\x05\x00\xFF"),7);

Which works, but it's not as nice.
I will use Carlos's PDATA define now.

Regards, Michael.

Telling yourself something is too hard, or too complicated, is not a determination. It is a decision.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
prog_uint8_t my_data[]= {1,2,3,4,5,6}; 

Hei, i don't know this kind of identifier... prog_uint8_t, what does it mean? is it mean something like uint8_t PROGMEM?
I don't understand this, especially typedef part:

typedef uint8_t PROGMEM prog_uint8_t;

KISS - Keep It Simple Stupid!

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

Quote:

I don't understand this, especially typedef part:
Code:
typedef uint8_t PROGMEM prog_uint8_t;

And Google didn't give any hits for "typedef in C"? You're on the internet, obviously. Please learn how to make use of it.

You could read the above type definition as "define a new type called prog_uint8_t to be equivalent to uint8_t PROGMEM".

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

hm..i think i'm getting freak here. For a whole day i just open www.avrfreak.net on my browser and now i started to think that internet is www.avrfreak.net.
I should Google it first before asking..

KISS - Keep It Simple Stupid!

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

JohanEkdahl wrote:
OT:
Quote:

I thought all programmers used the internationally recognised 'foo' and 'bar' in fact? Wink
fred is on the list too, but rather far down.
Python programmers live elsewhere.
Quote:
Not FORTRAN programmers. They largely depend on the fact that anything named i,jk,l,m or n is an INTEGER by default. All others are REAL (or was that FLOAT?). That's all they think they need. Their mantra goes:

"If you can't do it in FORTRAN, then do it in assembler. If you can't do it in assembler, then its not worth doing"

I once had the joy of reading a FORTRAN program by someone
who apparently believed in neither FORTRAN nor assembler.
His variables consisted of two arrays, one for INTEGER and one for REAL.
This one suspects he would have preferred programming in machine.

Iluvatar is the better part of Valar.