| Author |
Message |
|
|
Posted: Jun 23, 2009 - 09:45 AM |
|


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 *"  |
_________________
|
| |
|
|
|
|
|
Posted: Jul 13, 2009 - 08:56 PM |
|

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? |
|
|
| |
|
|
|
|
|
Posted: Jul 13, 2009 - 09:49 PM |
|

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.
|
| |
|
|
|
|
|
Posted: Jul 14, 2009 - 12:45 PM |
|

Joined: Nov 01, 2003
Posts: 127
Location: Greece
|
|
| thanks for the clarification. |
|
|
| |
|
|
|
|
|
Posted: Dec 11, 2009 - 02:24 AM |
|

Joined: Dec 09, 2009
Posts: 11
|
|
Hey guys,
Is it possible to implement PROGMEM for AVR32 ?
Regards, |
|
|
| |
|
|
|
|
|
Posted: Jan 18, 2010 - 03:03 PM |
|

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 |
|
|
| |
|
|
|
|
|
Posted: May 17, 2010 - 08:19 PM |
|

Joined: May 12, 2010
Posts: 7
Location: Concord, CA, 94519
|
|
Utmost puzzling javascript:emoticon(' ')
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(' ')
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 |
|
|
| |
|
|
|
|
|
Posted: May 17, 2010 - 08:57 PM |
|


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
|
| |
|
|
|
|
|
Posted: Jun 25, 2010 - 08:47 PM |
|

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. |
|
|
| |
|
|
|
|
|
Posted: Jun 25, 2010 - 09:56 PM |
|


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
|
| |
|
|
|
|
|
Posted: Jun 25, 2010 - 10:17 PM |
|

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
|
| |
|
|
|
|
|
Posted: Jun 25, 2010 - 10:33 PM |
|


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
|
| |
|
|
|
|
|
Posted: Jun 25, 2010 - 10:50 PM |
|

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? |
|
|
| |
|
|
|
|
|
Posted: Jun 25, 2010 - 10:53 PM |
|


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.  |
_________________ Stefan Ernst
Last edited by sternst on Jun 25, 2010 - 11:11 PM; edited 1 time in total
|
| |
|
|
|
|
|
Posted: Jun 25, 2010 - 11:07 PM |
|

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? |
|
|
| |
|
|
|
|
|
Posted: Jun 25, 2010 - 11:41 PM |
|


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
|
| |
|
|
|
|
|
Posted: Jun 28, 2010 - 10:14 AM |
|


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. |
_________________
|
| |
|
|
|
|
|
Posted: Jun 28, 2010 - 04:55 PM |
|

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. |
|
|
| |
|
|
|
|
|
Posted: Jul 17, 2010 - 06:56 PM |
|

Joined: Jul 16, 2008
Posts: 3
|
|
| Thanks a lot for the explanation, it has been very usefull for me!! |
|
|
| |
|
|
|
|
|
Posted: Sep 07, 2010 - 01:26 AM |
|

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. |
|
|
| |
|
|
|
|
|