Robert,
Could you please forward this to the list? My posts are still being
blocked. The one below was sent only to the list, but it's not there on
http://lists.gnu.org/pipermail/avr-gcc-list .
Thanks,
Erik
On Mon, May 11, 2009 at 10:30:40PM +1000, Erik Christiansen wrote:
On Mon, May 11, 2009
On Wed, May 13, 2009 at 01:16:31PM +0200, Robert von Knobloch wrote:
Curiously I could not use e.g.
asm (test_pgm_read_byte:jmp pgm_read_byte);
undefined reference to 'pgm_read_byte' although it is defined and in
scope.
Where pgm_read_byte is a library function from avr-libc.
Stu Bell wrote:
If I had your problem, this is how I would solve it: Define a real table
of function pointers instead of trying to get the linker to create one
for you.
typedef void (*TestProc) (void*);
NOINLINE void test_lcd_2(void* pStr) {PGM_P string = (PGM_P) pStr;
Thanks to all who have helped me to get the best solution.
I have eventually decided that an assembler jump table was really the
best in my application:
/*
**
* Function entry points for independent test routines
Robert von Knobloch wrote:
Curiously I could not use e.g.
asm (test_pgm_read_byte:jmp pgm_read_byte);
undefined reference to 'pgm_read_byte' although it is defined and in
scope.
Where pgm_read_byte is a library function from avr-libc.
I think this is because pgm_read_byte() is a
David Kelly wrote:
On Mon, May 11, 2009 at 08:21:37AM -0600, Weddington, Eric wrote:
Sounds to me as if you are making the bootloader too big and
should simply link an entire application for every possible
target. What you are doing would make more sense if the loadable
modules could run
Erik Christiansen wrote:
I confess that GCC seems to me to be mostly something to fight with,
perhaps I have been spoiled in the past using manufacturer's C compliers
that were tailored especially for the target.
It just requires leisure time for study and experimentation. ;-)
I
I simply require a way to fix absolutely this jump table in memory.
Whether I write it in C or assembler seems to me to be irrelevant, as is
using an array of pointer to functions, because I still have the problem
of fixing these at absolute addresses.
If anyone knows a way to do this, I would
Jan Waclawek wrote:
I simply require a way to fix absolutely this jump table in memory.
Whether I write it in C or assembler seems to me to be irrelevant, as is
using an array of pointer to functions, because I still have the problem
of fixing these at absolute addresses.
If anyone knows a
Robert von Knobloch wrote:
Why would the compiler respect assembler any more than my C calls (it
changes the order of them as they are stored in memory, so I cannot
guarantee the address of test_func_1())
There is nothing in the C language that tells the compiler to preserve the
ordering of
Jan Waclawek wrote:
Why would the compiler respect assembler any more than my C calls
Because the compiler knows nothing on assembly language. It simply passes it
as a string to the assembler: it does not attempt to parse it (except for the
escape sequences), so it has no chance to
Erik Christiansen wrote:
On Tue, May 12, 2009 at 02:26:38PM +0200, Jan Waclawek wrote:
On the other hand, a compiler is free to do whatever it wants to do
with statements you pass to it: it can reorder and insert voids
wherever and whenever it wants. This is the very principle of high
Is there any way of 'fixing' a few, specific global variables at a known
location?
In flash, I can use a '.section' to do this. Is there an equivalent for ram?
I notice that the compiler puts static variables before globals, which
make it impossible to predict where the globals will be.
I am
Robert,
There is some difference, though: you can't count on such variables to be
initialised to zero.
JW
- Original Message ---
Schwichtenberg, Knut wrote:
Robert,
there is no difference in handling. So create your special section and put
the variables into it as you
Jan Waclawek wrote:
Robert,
There is some difference, though: you can't count on such variables to be
initialised to zero.
JW
This is obvious, I think, but thanks for the tip anyway.
Robert
___
AVR-GCC-list mailing list
] Allocating variables to a fixed address
Is there any way of 'fixing' a few, specific global variables
at a known
location?
In flash, I can use a '.section' to do this. Is there an
equivalent for ram?
I notice that the compiler puts static variables before globals, which
make it impossible
Weddington, Eric wrote:
Why do you need global variables to be at a specific address?
Because my software consists of a:
A fixed part - main plus User Interface - This is test equipment for
small electronic products
and
Several loadable parts which can be loaded via rs232 as Intel hex and
On Mon, May 11, 2009 at 02:55:17PM +0200, Robert von Knobloch wrote:
Weddington, Eric wrote:
Why do you need global variables to be at a specific address?
Because my software consists of a:
A fixed part - main plus User Interface - This is test equipment for
small electronic products
David Kelly wrote:
Sounds to me as if you are making the bootloader too big and should
simply link an entire application for every possible target. What you
are doing would make more sense if the loadable modules could run out of
RAM.
That would be no use, the loadables must be non-volatile.
] Allocating variables to a fixed address
David Kelly wrote:
Sounds to me as if you are making the bootloader too big
and should
simply link an entire application for every possible
target. What you
are doing would make more sense if the loadable modules
could run out of
RAM
Knobloch; avr-gcc-list@nongnu.org
Subject: Re: [avr-gcc-list] Allocating variables to a fixed address
I'd write the *jumptable* in asm. That's easy and means one
less degree of freedom for the compiler and co.
JW
-Original Message-
To realise this interface (API), I must
I have defined all cross-module routines and give them
'psuedo-calls' in a vector table so:
/*
**
* Function entry points for independent test routines
On Mon, May 11, 2009 at 03:56:34PM +0200, Robert von Knobloch wrote:
David Kelly wrote:
Sounds to me as if you are making the bootloader too big and
should simply link an entire application for every possible target.
What you are doing would make more sense if the loadable modules
could
On Mon, May 11, 2009 at 08:21:37AM -0600, Weddington, Eric wrote:
Sounds to me as if you are making the bootloader too big and
should simply link an entire application for every possible
target. What you are doing would make more sense if the loadable
modules could run out of RAM.
24 matches
Mail list logo
