| Author |
Message |
|
|
Posted: Apr 14, 2012 - 12:51 AM |
|

Joined: Jul 04, 2009
Posts: 36
Location: Brisbane, Australia
|
|
Sorry, I should have specified I am using GCC from within AVR Studio 5.1.208.
Regards,
Stewart. |
|
|
| |
|
|
|
|
|
Posted: Apr 14, 2012 - 01:26 AM |
|

Joined: Mar 09, 2012
Posts: 1452
Location: North Carolina, USA
|
|
|
stewpye wrote:
The project I have planned is an analogue sequencer for analogue music synthesizers (similar in operation to roland TR606 or TR808 drum machine)
That sounds very cool, I'd like to hear more about that project. (I have a TR808 and a TR909.)
I suppose that is off topic in here, but there is a subforum for off topic stuff if you want to share. |
|
|
| |
|
|
|
|
|
Posted: Apr 14, 2012 - 07:49 AM |
|


Joined: Mar 27, 2002
Posts: 18746
Location: Lund, Sweden
|
|
|
SprinterSB wrote:
JohanEkdahl wrote:
Quote:
It's more of a hardware issue than a C issue.
As I hinted at above, I'd say that it is mostly a compiler implementation issue. Other tool chains are implemented so that they recognize that the variable is in flash, and generate the corect LPM instructions.
Just out of interest: Suppose there is a module A that reads a char like so
Code:
char read (const char *p)
{
return *p;
}
What is the result of compiling that module?
I lost you, Sprinter. Care to be explicit about the point you're trying to make? |
|
|
| |
|
|
|
|
|
Posted: Apr 14, 2012 - 09:31 AM |
|


Joined: Dec 21, 2006
Posts: 1545
Location: Saar-Lor-Lux
|
|
| You said:
JohanEkdahl wrote:
Other tool chains are implemented so that they recognize that the variable is in flash, and generate the corect LPM instructions.
Thus, I wonder how other toolchains compile a little C module like
Code:
char read (const char *p)
{
return *p;
}
Or is it not possible to compile modules, build libraries and link against them and instead, everything must be known at compile time and there is effectively only one big source file?
Basically, I am curious about the GNU equivalent of
Code:
avr-gcc foo.c -c -Os -mmcu=atmega8
avr-objdump -d foo.o
for the mentioned module which is
Code:
00000000 <read>:
0: fc 01 movw r30, r24
2: 80 81 ld r24, Z
4: 08 95 ret
and where the LPM you mentioned comes into play.
Notice that legal calls of read include
Code:
void read (const char*);
void read2 (char *p)
{
read (p);
}
|
|
|
| |
|
|
|
|
|
Posted: Apr 14, 2012 - 09:51 AM |
|

Joined: Feb 12, 2005
Posts: 16536
Location: Wormshill, England
|
|
Harvard compilers have always coped with this in one of two ways.
1. Use a generic pointer.
2. Use a section specific pointer.
Traditionally, 8051 compilers do both.
AVR compilers use method (2). e.g. CodeVision strcpy() and strcpyf()
An 8051 has __data, __idata, __xdata, __code, ... and several variations of the __xdata addressing.
The overhead involved with (1) is horrendous. Since an AVR only really has SRAM or FLASH, it seems inefficient to cater for (1)
__eeprom memory if available generally requires sophisticated support. In fact CodeVision manages these accesses transparently. OTOH, it does not supply strcpy_E() variants. They are simple to write yourself.
David. |
|
|
| |
|
|
|
|
|
Posted: Apr 14, 2012 - 10:47 AM |
|


Joined: Mar 27, 2002
Posts: 18746
Location: Lund, Sweden
|
|
I hereby confess that I am utterly stupid.
1) I simply tried to express that I believe some other compiles do not require you to explicitly call a function when you want to access a variable in flash.
2) I am still not understanding what you are asking. In your last post I lose you right about "Thus". What does that module have to do with a compiler recognizing that a variable is in flash and generating code to access it? In order to answer you I need you to be very explicit with what you are questioning in my statement. |
|
|
| |
|
|
|
|
|
Posted: Apr 14, 2012 - 11:27 AM |
|


Joined: Dec 21, 2006
Posts: 1545
Location: Saar-Lor-Lux
|
|
| Maybe I misunderstood what
Quote:
Other tool chains are implemented so that they recognize that the variable is in flash, and generate the corect LPM instructions.
means. If the compiler is a Standard-C compiler and recognize if a variable shall be located in flash, ten I just wonder how that works without beeing overly inefficient.
Suppose the compiler recognizes that the following varf can be located in flash:
Code:
static const char varF[] = "flash";
and you have a second variable:
Code:
extern char varR;
Now suppose you call the function read from above:
Code:
extern char read (const char*);
char read1 (void)
{
return read (varF) + read (&varR);
}
For this small fcuntions I am curious about the "recognize that a variable can be in flash and generate LPM".
If there are __flash Qualifiers or things like that needed the answer is trivial, of course, but that's not "recognizing", it's "writing down explicitly what you want". |
|
|
| |
|
|
|
|
|
Posted: Apr 14, 2012 - 11:51 AM |
|

Joined: Feb 12, 2005
Posts: 16536
Location: Wormshill, England
|
|
Just look at the way that CodeVision handles this.
An anonymous string is always in flash.
Your example is a named variable. Hence you need a qualifier if you want to override the default SRAM storage.
If you want a single function to access multiple storage areas, you either need a qualifier or a generic pointer.
You could allow a Compiler a certain amount of 'casting'. e.g. if the function prototype specifies a char*, you can 'cast' the char __flash * to a char* by copying to a common SRAM area. The function would receive the arguments that it wants.
Automatic casting of function arguments works fine for promotion e.g. extending a uint8_t to uint32_t.
However these arguments have a limited size.
Silently copying structure or array contents purely to satisfy pointer requirements is horrific. However it may often suit a User application. i.e. a User call rather than a Compiler built-in.
David. |
|
|
| |
|
|
|
|
|
Posted: Apr 14, 2012 - 12:12 PM |
|


Joined: Mar 27, 2002
Posts: 18746
Location: Lund, Sweden
|
|
I had a long post here that I lost (pilot error). In short:
1) My statement on other compilers was just a statement of fact, not an endorsement.
2) Now I see what you're asking, Sprinter.
3) I do not know the answer. I am curious but not to the point of spending time finding out (I'm a avr-gcc user myself). |
|
|
| |
|
|
|
|
|