I am trying to port a basic USB CDC stack from an AT90USB162 to the LPC2148
(rather than paying for something like an FT232RL), and it seems on the atmel
chips you can use PROGMEM to store variables in flash memory rather than using
SRAM (which is good since the AT90USB162 only has 512 bytes of it).
I was wondering if there is a straight forward way to do the same with an
lpc2100? All of the description data in the USB stack is only used once, so
it's a shame to use up all that memory for nothing ... especially if
it's possible to use flash instead if access time isn't an issue.
There are probably many situations where you don't care that much about
access speed, and if you can save some memory all the better, especially on
inexpensive chips like the 2103.
Here's an example of the AVR code declaration:
U8 serial_str_desc[] PROGMEM {
0x14, // bLength: 0x14 (20 bytes = sizeof str fields + string)
STR_DESCR, // bDescriptorType: String
// Serial: Beta 0.50
'B',0, 'e',0, 't',0, 'a',0, '
',0, '0',0, '.',0, '5',0,
'0',0,
};
PROGMEM equivalent for lpc2100?
Started by ●June 15, 2009
Reply by ●June 15, 20092009-06-15
> I am trying to port a basic USB CDC stack from an
AT90USB162 to the
LPC2148
> (rather than paying for something like an FT232RL), and it seems on the
> atmel chips you can use PROGMEM to store variables in flash memory rather
> than using SRAM (which is good since the AT90USB162 only has 512 bytes of
> it).
Store it in flash.
> I was wondering if there is a straight forward way to do the same with an
> lpc2100? All of the description data in the USB stack is only used once,
> so it's a shame to use up all that memory for nothing ... especially if
> it's possible to use flash instead if access time isn't an issue. There
> are probably many situations where you don't care that much about access
> speed, and if you can save some memory all the better, especially on
> inexpensive chips like the 2103.
>
> Here's an example of the AVR code declaration:
>
> U8 serial_str_desc[] PROGMEM > {
> 0x14, // bLength: 0x14 (20 bytes = sizeof str fields + string)
> STR_DESCR, // bDescriptorType: String
> // Serial: Beta 0.50
> 'B',0, 'e',0, 't',0, 'a',0, ' ',0, '0',0, '.',0, '5',0,
> '0',0,
> };
That's because the AVR is a good-for-nuth'n Harvard machine with separate
data and code memories.
Use the tao of 'const':
const U8 serial_str_desc[] {
0x14, // bLength: 0x14 (20 bytes = sizeof str fields + string)
STR_DESCR, // bDescriptorType: String
// Serial: Beta 0.50
'B',0, 'e',0, 't',0, 'a',0, ' ',0, '0',0, '.',0, '5',0,
'0',0,
};
Yeah, like kool, dude. Goes in flash, not in RAM.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
LPC2148
> (rather than paying for something like an FT232RL), and it seems on the
> atmel chips you can use PROGMEM to store variables in flash memory rather
> than using SRAM (which is good since the AT90USB162 only has 512 bytes of
> it).
Store it in flash.
> I was wondering if there is a straight forward way to do the same with an
> lpc2100? All of the description data in the USB stack is only used once,
> so it's a shame to use up all that memory for nothing ... especially if
> it's possible to use flash instead if access time isn't an issue. There
> are probably many situations where you don't care that much about access
> speed, and if you can save some memory all the better, especially on
> inexpensive chips like the 2103.
>
> Here's an example of the AVR code declaration:
>
> U8 serial_str_desc[] PROGMEM > {
> 0x14, // bLength: 0x14 (20 bytes = sizeof str fields + string)
> STR_DESCR, // bDescriptorType: String
> // Serial: Beta 0.50
> 'B',0, 'e',0, 't',0, 'a',0, ' ',0, '0',0, '.',0, '5',0,
> '0',0,
> };
That's because the AVR is a good-for-nuth'n Harvard machine with separate
data and code memories.
Use the tao of 'const':
const U8 serial_str_desc[] {
0x14, // bLength: 0x14 (20 bytes = sizeof str fields + string)
STR_DESCR, // bDescriptorType: String
// Serial: Beta 0.50
'B',0, 'e',0, 't',0, 'a',0, ' ',0, '0',0, '.',0, '5',0,
'0',0,
};
Yeah, like kool, dude. Goes in flash, not in RAM.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
Reply by ●June 15, 20092009-06-15
> Use the tao of 'const':
>
> const U8 serial_str_desc[] > {
> 0x14, // bLength: 0x14 (20 bytes = sizeof str fields + string)
> STR_DESCR, // bDescriptorType: String
> // Serial: Beta 0.50
> 'B',0, 'e',0, 't',0, 'a',0, ' ',0, '0',0, '.',0, '5',0,
> '0',0,
> };
>
> Yeah, like kool, dude. Goes in flash, not in RAM.
Paul:
Thanks for the reply. I didn't realise that everything declared const goes into flash by default? I wouldn't have expected that, but then I'm used to writing software for Windows.
Kevin.
>
> const U8 serial_str_desc[] > {
> 0x14, // bLength: 0x14 (20 bytes = sizeof str fields + string)
> STR_DESCR, // bDescriptorType: String
> // Serial: Beta 0.50
> 'B',0, 'e',0, 't',0, 'a',0, ' ',0, '0',0, '.',0, '5',0,
> '0',0,
> };
>
> Yeah, like kool, dude. Goes in flash, not in RAM.
Paul:
Thanks for the reply. I didn't realise that everything declared const goes into flash by default? I wouldn't have expected that, but then I'm used to writing software for Windows.
Kevin.
Reply by ●June 15, 20092009-06-15
On Mon, 15 Jun 2009 15:07:23 -0000, you wrote:
>> Use the tao of 'const':
>>
>> const U8 serial_str_desc[] >> {
>> 0x14, // bLength: 0x14 (20 bytes = sizeof str fields + string)
>> STR_DESCR, // bDescriptorType: String
>> // Serial: Beta 0.50
>> 'B',0, 'e',0, 't',0, 'a',0, ' ',0, '0',0, '.',0, '5',0,
>> '0',0,
>> };
>>
>> Yeah, like kool, dude. Goes in flash, not in RAM.
>
>Paul:
>
>Thanks for the reply. I didn't realise that everything declared const goes into flash by default? I wouldn't have expected that, but then I'm used to writing software for Windows.
>
>Kevin.
const will generally go in flash, however on architectures like the AVR, it may default to RAM (i.e.
copied from flash to RAM at some point) , possibly depending on size/speed optimisation settings,
due to the extra complication of accessing data in code space, e.g. in IAR's AVR compiler you need
to prefix const with __flash to force it into flash
>> Use the tao of 'const':
>>
>> const U8 serial_str_desc[] >> {
>> 0x14, // bLength: 0x14 (20 bytes = sizeof str fields + string)
>> STR_DESCR, // bDescriptorType: String
>> // Serial: Beta 0.50
>> 'B',0, 'e',0, 't',0, 'a',0, ' ',0, '0',0, '.',0, '5',0,
>> '0',0,
>> };
>>
>> Yeah, like kool, dude. Goes in flash, not in RAM.
>
>Paul:
>
>Thanks for the reply. I didn't realise that everything declared const goes into flash by default? I wouldn't have expected that, but then I'm used to writing software for Windows.
>
>Kevin.
const will generally go in flash, however on architectures like the AVR, it may default to RAM (i.e.
copied from flash to RAM at some point) , possibly depending on size/speed optimisation settings,
due to the extra complication of accessing data in code space, e.g. in IAR's AVR compiler you need
to prefix const with __flash to force it into flash
Reply by ●June 15, 20092009-06-15
> Thanks for the reply. I didn't realise that
everything declared const
goes
> into flash by default?
Const data goes in the '.rodata' section (read-only data) which is mapped to
flash.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
goes
> into flash by default?
Const data goes in the '.rodata' section (read-only data) which is mapped to
flash.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors