| Author |
Message |
|
|
 Posted: Apr 29, 2010 - 05:04 PM |
|
Joined: Dec 30, 2005
Posts: 2327
Location: Fort Collins, CO USA
|
|
|
wek wrote:
Stu, and others, may I ask you to give it a try in the wild?
I hope to give it a shot sometime today. Kinda busy on a different (embedded Linux) project so I may not get to it today, but will definitely tomorrow.
Stu |
_________________
Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.
Newbie? Be sure to read the thread Newbie? Start here!
|
| |
|
|
|
|
|
|
Posted: May 24, 2010 - 06:41 AM |
|
Joined: Apr 22, 2008
Posts: 21
|
|
|
wek wrote:
Stu, and others, may I ask you to give it a try in the wild?
Jan
Excellent. Appears to behave correctly on a set of code I tried. Code is 25k LOCs on a MEGA2560 and lots of strings amounting to some 20kbytes. No problems observed.
This is one of those things that shouldn't need to be an explicit optimization, it should be a given where possible. There should be no reason to have to compute the length of a string in PROGMEM.
I did have to do some minor reorganization of the code.
Its stating the obvious, but if the strings are not visible in the current object module, the length can't be computed at compile-time. Solving this would be really neat!
With larger projects, there will always be multiple object modules and strings may be reused across them. As a result, I had all strings in one C module. Makes things simpler when it comes to supporting multiple languages. It takes a bit of careful thought to rearrange things, into a header-file, for example. |
|
|
| |
|
|
|
|
|
|
Posted: May 24, 2010 - 07:46 AM |
|
Joined: Dec 16, 2005
Posts: 3089
Location: Bratislava, Slovakia
|
|
|
dalew1 wrote:
Appears to behave correctly on a set of code I tried.
Thanks for trying.
dalew1 wrote:
This is one of those things that shouldn't need to be an explicit optimization, it should be a given where possible. There should be no reason to have to compute the length of a string in PROGMEM.
While the string itself in FLASH won't change, the *pointer* used in this function may be a variable, pointing to various FLASH strings. In this case, the length "calculation" is inevitable. Also, part of the FLASH may be used as a permanent configuration memory, storing for example the language-dependent strings, being updated through some self-programming mechanism (bootloader), after compilation. Here, functions like strlen/strcmp etc. working on FLASH "variables" may make sense.
JW |
|
|
| |
|
|
|
|
|
|
Posted: May 24, 2010 - 03:51 PM |
|
Joined: Dec 30, 2005
Posts: 2327
Location: Fort Collins, CO USA
|
|
I forgot to report on this - my ATmega2560 app (> 90K LOC) is running perfectly with the mod. I have both cases handled by the macro. Total of 5 uses of strlen_P in the code, but they are exercised pretty often in normal usage.
Stu |
_________________
Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.
Newbie? Be sure to read the thread Newbie? Start here!
|
| |
|
|
|
|
|
|
Posted: May 24, 2010 - 06:39 PM |
|
Joined: Dec 16, 2005
Posts: 3089
Location: Bratislava, Slovakia
|
|
| Arigato gozaimasu, Stu-san. |
|
|
| |
|
|
|
|
|
|
Posted: May 25, 2010 - 03:32 PM |
|
Joined: Dec 30, 2005
Posts: 2327
Location: Fort Collins, CO USA
|
|
Domo, domo. 
Stu |
_________________
Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.
Newbie? Be sure to read the thread Newbie? Start here!
|
| |
|
|
|
|
|
FAQ
Search
Register
Log in to check your private messages
Log in
Maximize
RSS
