Hi.
On 5/12/09, Weddington, Eric eric.wedding...@atmel.com wrote:
I don't understand what you're doing here.
You've completely removed EIJMP from gcc.
That is correct. It is better for gcc not to use this instruction.
This prevent using indirect function call in bootloader code for
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;
Robert von Knobloch wrote:
This solution, while a purer 'C' solution would require me to have all
my 'internal' functions with similar call/return requirements.
This is not, and cannot be, the case. I fear that the magig 'array of
function pointers' has only limited use and is unsuitable here.
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
On 5/13/09, Anatoly Sokolov ae...@post.ru wrote:
Hi.
On 5/12/09, Weddington, Eric eric.wedding...@atmel.com wrote:
I don't understand what you're doing here.
You've completely removed EIJMP from gcc.
That is correct. It is better for gcc not to use this instruction.
This prevent
- Original Message -
From: Sean D'Epagnier geckosena...@gmail.com
To: Anatoly Sokolov ae...@post.ru
Cc: Weddington, Eric eric.wedding...@atmel.com;
avr-gcc-list@nongnu.org
Sent: Wednesday, May 13, 2009 6:35 PM
Subject: Re: [avr-gcc-list] mcall-prologues completely broken for 128k
Hi
On 5/13/09, Anatoly Sokolov ae...@post.ru wrote:
avr-libc/crt1/gcrt1.S :
.section .init0,ax,@progbits
.weak __init
; .func __init
__init:
...
#ifdef __AVR_3_BYTE_PC__
ldi r16, hh8(pm(__vectors))
out _SFR_IO_ADDR(EIND), r16
#endif/*
On Thursday 14 May 2009 07:42, Sean D'Epagnier wrote:
[...]
Also, there is the issue of longjmp setting EIND and not restoring it.
It gets a little tricky with interrupts that can potentially set EIND
as well.
Yes, the longjmp() sets EIND. It is impossible to restore EIND,
as the EIJMP is
In any case, the rules of EIND usage must be documented.
The avr-gcc/avr-ld internally use the EIND for indirect function call, case
statement optimization (tablejump) and -mcall-prologues optimization. The
EIND always should contain hh8(pm(start of .trampolines section)) value,
i.e. 0 when
On Thursday 14 May 2009 09:23, Anatoly Sokolov wrote:
Thanks!
What about to copy yours mail into Avr-libc doc?
[...]
Calling the bootloader code from application code and
calling application from bootloader is PROHIBITED, allowed only jump from
application code to reset vector of bootloader
On Thursday 14 May 2009 09:31, you wrote:
[...]
I like that solution. Is this correct?
Index: setjmp.S
===
RCS file: /sources/avr-libc/avr-libc/libc/stdlib/setjmp.S,v
retrieving revision 1.7
diff -u -r1.7 setjmp.S
---
On Thursday 14 May 2009 14:03, Dmitry K. wrote:
And some optimization is needed to exclude pop/push sequences.
I shall fix this bug (mismatch of longjmp() to Avr-gcc's API)
at the nearest week-end.
Dmitry.
___
AVR-GCC-list mailing list
On 5/13/09, Dmitry K. dm...@marine.febras.ru wrote:
On Thursday 14 May 2009 14:03, Dmitry K. wrote:
And some optimization is needed to exclude pop/push sequences.
I shall fix this bug (mismatch of longjmp() to Avr-gcc's API)
at the nearest week-end.
Great. Sorry for all my confusion/
Sean
15 matches
Mail list logo
