On Fri, Nov 25, 2011 at 11:18:17AM +0100, Georg-Johann Lay wrote:
> >
> >In avr.md I changed:
> >return "sbi %i0,%2";
> >to
> >return "sbi %i0-0x20,%2";
> >
> >It fixed the problem. I think this needs to be done all over the place
>
> This is an incorrect fix, the problem must be somewher
I have had some issues compiling source code with the latest gcc in svn.
The following program fails me:
#include
int main(void) {
DDRB |= _BV(DDB5);
}
avr-gcc -mmcu=at90usb1287 -c test.c -o test.o -O2
/tmp/ccqKOBv9.s: Assembler messages:
/tmp/ccqKOBv9.s:16: Error: number must be positive
I got the latest gcc from svn, and with "configure --target=avr
--enable-languages=c":
When building with "make" eventually I get:
gcc -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-format-at
I am not sure that everyone wants avr to have multiple address spaces
handled by the compiler. The reason, is that now pointers are 3 or 4
bytes not 2 which makes for larger code size and slower execution.
The current way forces code to look ugly, but gives the programmer
more control and more sp
On 12/14/09, Andrew Hutchinson wrote:
> The patterns for AVR mega 256 use EICALL an EIJMP
>
> Both require EIND to be set to provide upper address bits
>
> However, we are using linker trampolines for both, so in either case the
> 16 bit jump or call is to the trampolines.
>
> Are not the trampoli
Hi,
I tried to build latest svn of gcc so I can update my fixed-point
patch to work with the new compare routines. I get an error:
../../gcc/config/avr/avr.c -o avr.o
../../gcc/config/avr/avr.c: In function �‘avr_override_options�’:
../../gcc/config/avr/avr.c:396: error: �‘PARAM_
Did you only upgrade avr libc, or also gcc? I noticed that newer gcc
(newer than 4.2.2) versions made my program 14k larger. This is a
huge increase for me and I don't like it. I don't have the time to
track it down right now.
Sean
On 5/24/09, Birger Brunswiek wrote:
> Hi,
> I have just upgra
Hi,
I saw the update, thanks.
I have a very complex case with many case of setjmp and longjmp, and
it still fails.. same code works recompiled to run on linux.. but the
problem may be something else that only occurs on the avr, I can't
blame it on setjmp/longjmp yet. I will investigate it if I
On 5/13/09, Dmitry K. 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
_
Hi
On 5/13/09, Anatoly Sokolov 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 5/13/09, Anatoly Sokolov wrote:
> Hi.
>
>
>> On 5/12/09, Weddington, Eric 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 fun
s are enabled instead of saving and
restoring SREG because I don't have __tmp_reg__ free to use. Is there
a reason it wouldn't work?
Sean
> Eric Weddington
>
>> -Original Message-
>> From: Sean D'Epagnier [mailto:geckosena...@gmail.com]
>> Sent:
Hi,
Here are some patches. Please take a look and tell me if what I did
with setjmp makes any sense. I don't really use longjmp so it's not
fully tested, and it is only to handle a case which is very difficult
to create.
I have tested the gcc patch and my program is working very well now.
The
eddington=atmel@nongnu.org
>> [mailto:avr-gcc-list-bounces+eric.weddington=atmel@nongnu.
>> org] On Behalf Of Sean D'Epagnier
>> Sent: Saturday, May 09, 2009 1:36 PM
>> To: avr-gcc-list@nongnu.org
>> Subject: [avr-gcc-list] mcall-prologues completely broken fo
Hi, I originally thought my extensive used of the gcc extension
"Address labels" was the cause of my problems. After inspection of
the assembly I realized that they worked perfectly via the trampoline
mechanism.. so what was the problem?
I found that prologue_saves calls eijmp at the end, which
I found an alternative way to solve my problem which just requires running
a parser program on preprocessed code to generate switch tables for
each protothread. This way the thread switches and each case gotos
the right label. The actual code using proto threads doesn't know the
difference. It r
On 5/8/09, Tero Sinervo wrote:
> Sean D'Epagnier wrote:
>> Any more thoughts on this? Unfortunately address labels go in a void
>> * which seems like it should remain at 2 bytes.. so it's going to be
>> difficult. Maybe instead of storing the absolute address,
Hello,
I have recently had much success by the PROGMEM definition suggested
by curtvm on the avrfreaks forum. At the end of pgmspace.h I
inserted:
//undefine
#undef PROGMEM
//redefine
#define PROGMEM MAKE_PGM_SECTION_(__LINE__)
//expand __LINE__
#define MAKE_PGM_SECTION_(line) MAKE_PGM_SECTION__
Hi,
I have been using protothreads extensively which can sit on top of
either switch statements, or address labels. The second choice is
better because it allows you to use switch statements within the
protothreads.
Address labels is a gcc extension which allows you to store the
address of a lab
ic.weddington=atmel@nongnu.
>> org] On Behalf Of Sean D'Epagnier
>> Sent: Wednesday, May 06, 2009 12:45 PM
>> To: avr-gcc-list@nongnu.org
>> Subject: [avr-gcc-list] regression in size from 4.2.2 to 4.5.0
>>
>> Hi,
>>
>> I was trying to reduce
Yes, I thought about adding another section for this.
I found a lot of external eeproms annoying because they didn't want to
write a byte at a time.
What about using internal flash? You can jump to the bootloader
section execute spm and then return, and in this way on a 64kb chip or
so, write yo
hi,
>
> gcc knows two kinds of peepholes: RTL->RTL (peephole2) and RTL->asm
> (peephole). How would you integrate your work into gcc? You would have
> to map asm to RTL in order express your rules in terms of RTL. Moreover,
> this mapping is far from being unique: it's pointless to generate
> peep
Hi,
On 4/20/09, Georg-Johann Lay wrote:
>
> Hi Sean,
>
> as far as I understand, your tool runs on asm code, i.e. you map short
> sequences of asm instructions (which must not contain code labels) to
> other instruction sequences.
>
Right, and it's far from complete. In theory it could handle c
Hi,
I posted a forum topic on a new avr superoptimizer I'm working on.
It was noted that some people on this mailing list might be interested
but don't view the forum regularly.
The forum topic also contains the source code which you can download:
http://www.avrfreaks.net/index.php?name=PNphpBB2
On 3/27/09, David VanHorn wrote:
> I was originally declaring my variable passed to lcd_puts as
>
> signed char LCD_String[LCD_Line_Len + 1]
>
> This, after discovering to my surprise that lcd_puts wants signed chars.
>
> Recently, I've converted to the portable typedefs as
>
> unit8_t and int8_t
The reason is there are limited number of hardware breakpoints, and
software breakpoints normally can only be used when executing out of
ram.
So for example, gdb requires 1 hardware breakpoint to implement single
stepping, so if you only have 2 total hardware breakpoints, you can
only set 1 in the
Hi,
I am currently using the attiny861 with 32bit fixed point. I am using
printf with fixed-point support for printing, as well as a lot of math
operations.
I doubt you can do anything useful with floating point on something
smaller than 8kb, because the floating point routines use flash.
The a
I have some experimental work which has implemented mulhi3_highpart.
It is essentially a rule for gcc to use when multiplying two 16bit
integers and you only want the high 16bits. It is also used by gcc to
generate really fast division by constants which aren't powers of 2
for 16bit integers (mult
28 matches
Mail list logo
