Forum Menu




 


Log in Problems?
New User? Sign Up!
AVR Freaks Forum Index

Post new topic   Reply to topic
View previous topic Printable version Log in to check your private messages View next topic
Author Message
clawson
PostPosted: Jun 23, 2009 - 09:45 AM
10k+ Postman


Joined: Jul 18, 2005
Posts: 62220
Location: (using avr-gcc in) Finchingfield, Essex, England

1) yes, pgmspace.h just has this:
Code:
typedef uint16_t PROGMEM prog_uint16_t;


2) pointers whether they are to RAM or code flash are really just 16 bit numbers and could be passed around as such or you can use the universal get out clause which is "void *" Wink

_________________
 
 View user's profile Send private message  
Reply with quote Back to top
kakarot
PostPosted: Jul 13, 2009 - 08:56 PM
Hangaround


Joined: Nov 01, 2003
Posts: 127
Location: Greece

First of all this is a great tutorial. Thanks.
I am a little bit confused though. I am having a project in which I intend to use a menu to interface the uC.
Should I use progmem or eemem. Which one is better for LCD, menu
and a Keyboard?
 
 View user's profile Send private message  
Reply with quote Back to top
Koshchi
PostPosted: Jul 13, 2009 - 09:49 PM
10k+ Postman


Joined: Nov 17, 2004
Posts: 13815
Location: Vancouver, BC

AVRs by in large don't have much eemem, so unless you needs are small, there is probably not enough room in eemem. If you do fit in eemem, then it is up to you which you use, but I think that most would choose progmem. Reading from eemem takes longer than reading from progmem.

_________________
Regards,
Steve A.

The Board helps those that help themselves.
 
 View user's profile Send private message  
Reply with quote Back to top
kakarot
PostPosted: Jul 14, 2009 - 12:45 PM
Hangaround


Joined: Nov 01, 2003
Posts: 127
Location: Greece

thanks for the clarification.
 
 View user's profile Send private message  
Reply with quote Back to top
valpo_nz
PostPosted: Dec 11, 2009 - 02:24 AM
Newbie


Joined: Dec 09, 2009
Posts: 11


Hey guys,

Is it possible to implement PROGMEM for AVR32 ?


Regards,
 
 View user's profile Send private message  
Reply with quote Back to top
KirkCharles
PostPosted: Jan 18, 2010 - 03:03 PM
Rookie


Joined: Sep 12, 2007
Posts: 35
Location: Atlanta, GA USA

Thanks so much for this tutorial. It explains stuff that other authors miss.
May I suggest that you emphasize that PROGMEM assignments MUST be global. It took me quite a while to figure out the warning (which I think should be an error as it breaks all use of the constant)
Thanks
Kirk
 
 View user's profile Send private message  
Reply with quote Back to top
GaryStofer
PostPosted: May 17, 2010 - 08:19 PM
Newbie


Joined: May 12, 2010
Posts: 7
Location: Concord, CA, 94519

Utmost puzzling javascript:emoticon('Shocked')

So I followed this tutorial to put some strings into Program memory and then read them with pgm_read_byte(). While the string is reads correctly (when optimization is not at -Os) I can't explain what I see in the debugger!

The .lss file shows that the string is put in program memory right after the interrupt vector table, at address 0x7c. When I single step with the disassembler I can see that the LPM instruction via the Z pointer reads from address 0x7c.

HOWEVER when I bring up a memory window or scroll the disassembler to 0x7c there is no string. Instead I find the string at address 0x38, apparently right in the middle of the vector table, and I find that address 0x7c is inhabited by code. When I add a break point at 0x00007b the debugger stops there, so I'm clearly executing from there.
javascript:emoticon('Twisted Evil')
What is going on? Why does it appear that my string in memory is not where the .lss file says it should be and why am I executing code where a strings should be. What magic is this ?

Gary
 
 View user's profile Send private message Visit poster's website 
Reply with quote Back to top
sternst
PostPosted: May 17, 2010 - 08:57 PM
Raving lunatic


Joined: Jul 23, 2001
Posts: 2437
Location: Osnabrueck, Germany

You are mixing up byte and word addresses. The simulator/disassembler presents you everything related to the flash with word addresses, the GNU tools use byte addresses. So 0x7c in the .lss file is 0x3e in the simulator/disassembler.

_________________
Stefan Ernst
 
 View user's profile Send private message  
Reply with quote Back to top
chrislego88
PostPosted: Jun 25, 2010 - 08:47 PM
Newbie


Joined: Jun 23, 2010
Posts: 15


What about trying to store data in the bootloader section using PROGMEM? Is there a way to change PROGMEM's start location. I can recall strings and variables just fine from FLASH at 0x00000, but not from the bootloader section.
 
 View user's profile Send private message  
Reply with quote Back to top
sternst
PostPosted: Jun 25, 2010 - 09:56 PM
Raving lunatic


Joined: Jul 23, 2001
Posts: 2437
Location: Osnabrueck, Germany

chrislego88 wrote:
What about trying to store data in the bootloader section using PROGMEM? Is there a way to change PROGMEM's start location. I can recall strings and variables just fine from FLASH at 0x00000, but not from the bootloader section.
If you write a bootloader then you move the whole Flash stuff by relocating the .text section. This also moves the PROGMEM section. So what is you actual problem?

Or don't you write a bootloader but only want to place some data in the bootloader section (whyever)? Then simply don't use the PROGMEM section. Use your own section and place it there.

_________________
Stefan Ernst
 
 View user's profile Send private message  
Reply with quote Back to top
chrislego88
PostPosted: Jun 25, 2010 - 10:17 PM
Newbie


Joined: Jun 23, 2010
Posts: 15


I did relocate the .text section to my boot section. The problem that I am having is trying to recall data from the boot section.

For example,

Code:

I run that and it complies but I can never get buf to the init string. So I am not sure why memcpy_P cannot recall the data in FLASH.
const char init[] PROGMEM = "Boot Version";
const char flash[] PROGMEM = "FLASH";

PGM_P table[2] PROGMEM = { init,flash };

int main() {
   char buf[32];
        PGM_P p;
   memcpy_P(&p,&(table[0]),sizeof(PGM_P));
   strcpy_P(buf,p);
}



The code complies but I cannot get buf to hold any information. I am not really sure why. I always get the value of p to be 0xFFFF and then it crashes on strcpy_P command.


Last edited by chrislego88 on Jun 25, 2010 - 10:34 PM; edited 1 time in total
 
 View user's profile Send private message  
Reply with quote Back to top
sternst
PostPosted: Jun 25, 2010 - 10:33 PM
Raving lunatic


Joined: Jul 23, 2001
Posts: 2437
Location: Osnabrueck, Germany

I don't see any problem. So please be more specific about the context. What mcu? Are you aware that PROGMEM does not work beyond 64k (at least not out-of-the-box)?

_________________
Stefan Ernst
 
 View user's profile Send private message  
Reply with quote Back to top
chrislego88
PostPosted: Jun 25, 2010 - 10:50 PM
Newbie


Joined: Jun 23, 2010
Posts: 15


I have a Atxmega128a1 and the boot section starts at 0x020000.
I know that it doesn't work past 64k but my boot section is only 8k, so if I move the .text section to the boot section address I shouldn't have any problems right?
 
 View user's profile Send private message  
Reply with quote Back to top
sternst
PostPosted: Jun 25, 2010 - 10:53 PM
Raving lunatic


Joined: Jul 23, 2001
Posts: 2437
Location: Osnabrueck, Germany

chrislego88 wrote:
I have a Atxmega128a1 and the boot section starts at 0x020000.
I know that it doesn't work past 64k but my boot section is only 8k, so if I move the .text section to the boot section address I shouldn't have any problems right?
So you don't think that 0x020000 is beyond 0x010000 (64k)?

BTW: I am not familiar with the XMegas. Has an Atxmega128 more than 128k Flash? If not, how then can the boot section start at 0x020000?
EDIT: Forget this. Meanwhile I took a look into the data sheet. Wink

_________________
Stefan Ernst


Last edited by sternst on Jun 25, 2010 - 11:11 PM; edited 1 time in total
 
 View user's profile Send private message  
Reply with quote Back to top
chrislego88
PostPosted: Jun 25, 2010 - 11:07 PM
Newbie


Joined: Jun 23, 2010
Posts: 15


No it is beyond 64K but the PROGMEM doesn't travel with the .text section and have it start at 0x020000

If it doesn't then how can I store those strings in my boot section and still be able to recall them?
 
 View user's profile Send private message  
Reply with quote Back to top
sternst
PostPosted: Jun 25, 2010 - 11:41 PM
Raving lunatic


Joined: Jul 23, 2001
Posts: 2437
Location: Osnabrueck, Germany

Quote:
but the PROGMEM doesn't travel with the .text section and have it start at 0x020000
Why do you think it does not travel? Your code does not work because PROGMEN has traveled beyond 0x010000.

Quote:
how can I store those strings in my boot section and still be able to recall them?
The first thing you can do is to read at least the thread you are posting in. The 64k border was already a topic here.

_________________
Stefan Ernst
 
 View user's profile Send private message  
Reply with quote Back to top
clawson
PostPosted: Jun 28, 2010 - 10:14 AM
10k+ Postman


Joined: Jul 18, 2005
Posts: 62220
Location: (using avr-gcc in) Finchingfield, Essex, England

Search out Carlos Lamas (I may have spelt the wrong?) utilities called morepgmspace.h

EDIT: take a look at this thread:

http://www.avrfreaks.net/index.php?name ... p;p=599080

It may not be the best thread about morepgmspace.h but it includes a post by Carlos which should allow you to easily find his other posts.

_________________
 
 View user's profile Send private message  
Reply with quote Back to top
chrislego88
PostPosted: Jun 28, 2010 - 04:55 PM
Newbie


Joined: Jun 23, 2010
Posts: 15


clawson wrote:
Search out Carlos Lamas (I may have spelt the wrong?) utilities called morepgmspace.h

EDIT: take a look at this thread:

http://www.avrfreaks.net/index.php?name ... p;p=599080

It may not be the best thread about morepgmspace.h but it includes a post by Carlos which should allow you to easily find his other posts.


Thanks a lot those seem to work like a charm.
 
 View user's profile Send private message  
Reply with quote Back to top
fandres17
PostPosted: Jul 17, 2010 - 06:56 PM
Newbie


Joined: Jul 16, 2008
Posts: 3


Thanks a lot for the explanation, it has been very usefull for me!!
 
 View user's profile Send private message  
Reply with quote Back to top
Kingofthespill
PostPosted: Sep 07, 2010 - 01:26 AM
Newbie


Joined: Dec 09, 2008
Posts: 1


Thanks for explaining this Dean, ENORMOUSLY helpful.

About the eemem question above (in case your still following the thread) - That portion of memory can tolerate 100000 writes as opposed to 10000 in flash, so ultimately flash seems to me best for constant strings or at strings that rarely change.
 
 View user's profile Send private message  
Reply with quote Back to top
Display posts from previous:     
Jump to:  
All times are GMT + 1 Hour
Post new topic   Reply to topic
View previous topic Printable version Log in to check your private messages View next topic
Powered by PNphpBB2 © 2003-2006 The PNphpBB Group
Credits