org] On Behalf Of Robert von Knobloch
Sent: Thursday, January 28, 2010 2:53 AM
To: avr-gcc-list@nongnu.org
Subject: [avr-gcc-list] Address of code segment
CODESECTION uint16_t test7(void)
{
uint8_t size7prog;
// Write assembler program to tester RAM. BEWARE of page size
hoped the cast of (PGM_VOID_P) would help, but it doesn't.
What is the 'right' way (from the compiler's view) to extract the
address of the assembler code ?
(I like a clean compile with no warnings).
Thanks,
Robert von Knobloch
___
AVR-GCC-list mailing
Wouter van Gulik wrote:
Robert von Knobloch schreef:
Thanks Jan,
I have reached this conclusion too, I didn't understand the
compiler/assembler interaction (and still don't fully, I can't get an
sts var, Y to work, but I'll work at it).
Is it me or are you looking for st var, Y
Jan,
as I replied to Wouter, I had somehow got the wrong meaning of sts fixed
in my head. Talking (mailing) to you people has unlocked the brain.
Many thanks for the help.
Robert
David Brown,
yes, I used this as an exercise to understand the in-line assembler stuff.
The actual function is not as
are feeding him the uninitialized variable 'byte'. Which is also
allocate to R24.
HTH,
Wouter
Robert von Knobloch schreef:
Hello,
I've been trying to decipher the intricacies of in-line assembler (using
the Inline Assembler Cookbook as my guide).
I have a very simple application that I
storage
later.
Robert.
Wouter van Gulik wrote:
Robert von Knobloch schreef:
Hi Wouter,
thanks for responding.
This is not quite what I want, but your comment about the sts is
interesting.
I want to achieve this:
uint8_trambyte;
uint16_t ram_address;
void get_ram_byte(void
Thanks Jan,
I have reached this conclusion too, I didn't understand the
compiler/assembler interaction (and still don't fully, I can't get an
sts var, Y to work, but I'll work at it).
Btw. I like using silly names for variables, but only in very small demo
scripts ;-)
Robert
Robert,
I think you
tarmigan wrote:
(Reading through some very old email, it looks like this one might not
have been resolved...)
On Fri, May 8, 2009 at 2:41 AM, Robert von Knoblochb...@engelking.de wrote:
Hallo,
I am writing code for an ATMega 644P and have come across some very
strange behaviour.
A
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
From: David Brown da...@westcontrol.com
I've often heard of problems with FTDI chips, and especially their
drivers, but I've found them solid and reliable (except for their demo
code for PC software, which is rubbish). The example I gave of sending
multiple megabytes at over 1 MBaud is using
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
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
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
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
writing modular software and to be version independant, I must
define a simple API.
I have flash under control, but now ram is the problem.
Best regards,
Robert von Knobloch
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org
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
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
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.
-To: lists.avr-chat
To: undisclosed-recipients: ;
The following message is a courtesy copy of an article
that has been posted to lists.avr-chat as well.
Robert von Knobloch b...@engelking.de writes:
#define ASYNCCLK0
[]
while ((ASYNCPIN _BV(ASYNCCLK)) != 1)// Wait
Jörg wrote:
The correct way would be to use two different (input) linker sections,
like .test1.text and .test1.data, and combine these into a single output
section in the linker script (as Eric already suggested). That way, you
could also place the required ALIGN(2) directive after placing the
I hope this doesn't appear twice, it bounced although the address appears ok.
Thanks for your input Stu and Eric.
I have solved the problem by creating separate sections for the strings.
What really had me confused is something that I consider may be be a bug.
If I define a string (OK - array of
Dear GCC-List,
I am writing an application that uses loadable portions of code (it is a
tester for embedded products, where the target code and test routines
will be sent to a remote location [the factory] and loaded into the
tester via an Intel Hex download routine]. These 'test modules' are in
Stu Bell wrote:
Check out
http://www.avrfreaks.net/index.php?name=PNphpBB2file=viewtopict=38003
Best regards,
Stu Bell
DataPlay (DPHI, Inc.)
I cannot find where 'prog_char is defined and would like to
know how I can force the compiler to put these strings in my
'test1'
(whose version I have, of course, forgotten). I imagine
there will be quite a few people interested in small devices who also
will get bitten here.
Regards,
Robert von Knobloch.
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org
Message: 7
Date: Thu, 5 Feb 2009 10:08:20 +0100
From: j...@lillahusetiskogen.se
Subject: Re: [avr-gcc-list] Accessing function and strings in flash in
theATMega 644
To: avr-gcc-list@nongnu.org
The expression is probably not 'too complex for the compiler' but too
complex for the programmer.
Your
?
Best regards,
Robert von Knobloch
Here are snippets of my code:
//**
// Image definitions in Flash Memory
#define NUM_IMAGES10
#define IMAGE_SIZE0x900
// Offsets in the image
// Warning 'FUSES' defined
30 matches
Mail list logo
