On 01.03.2012 14:38, Richard Zetterberg wrote:
Cory: No, setting PB0 to 1 in DDRB two times in main doesn't change
anything. Doing DDRB = 0xFF; doesn't change anything. However, if I
put that line of code inside the turn_on_pb function it works as
expected.
Why don't you include the whole
On 01.03.2012 16:00, Richard Zetterberg wrote:
With my no-existing experience I conclude that's the source of the
problem, and thus the problem is solved.
Does that make sense or is that just a coincidence that it is now
working?
This makes perfect sense. If you happened to upload a
On 01.03.2012 16:30, David Kelly wrote:
On Mar 1, 2012, at 9:10 AM, Richard Zetterberg wrote:
int main(void)
{
DDRB |= (1 PB0);
84: 20 9a sbi 0x04, 0 ; 4
turn_on_pb();
86: 0e 94 40 00 call0x80; 0x80 turn_on_pb
8a: ff cf rjmp.-2
On 27.01.2012 01:40, William Chops Westfield wrote:
(reports are that 4.5.2 produced smaller code than 4.3.2)
Hmmm...
defiant joe [~/tmp]: avr-gcc -dumpversion
4.3.4
defiant joe [~/tmp]: avr-gcc -ggdb -Os -c -mmcu=atmega328p
-mshort-calls foo.c
defiant joe [~/tmp]: avr-size foo.o
text
Am 31.08.2010 22:59, schrieb Joerg Wunsch:
Johannes Bauer jb@gmx.de wrote:
On mikrocontroller.net
there are often quite interesting postings by guest users.
It's the only forum I know of that still allows that kind of liberty,
and it requires quite a bit of moderation for this to work
Am 31.08.2010 22:53, schrieb Joerg Wunsch:
Johannes Bauer jb@gmx.de wrote:
When sporadic deadlocks occur in a system, a stacktrace can really
help find bugs.
Yes, I know. I usually end up in manually inspecting the stack then,
as this requires no specific compilation options.
Well
Am 31.08.2010 23:04, schrieb Stu Bell:
I doubt there's a
very broad audience for improved stackframes -- as I said,
people do care for the amount of code generated, next they do
care for the code size, then they compare the generated code
size with compiler XYZ, and only then they start
Am 15.08.2010 09:00, schrieb Joerg Wunsch:
Johannes Bauer jb@gmx.de wrote:
This appears to be strange to me. The clr r1 instruction should
IMO be placed after the first push r0 instruction.
I didn't verify it right now, but I think this is a very old bug that
has been fixed
Am 15.08.2010 09:02, schrieb Joerg Wunsch:
Johannes Bauer jb@gmx.de wrote:
I've got another question regarding the AVR ISR prologues: Let's say
I compile with -fno-omit-frame-pointer.
As a side note, I don't think this option has received extended
testing in AVR-GCC. People
Am 15.08.2010 09:10, schrieb Joerg Wunsch:
Johannes Bauer jb@gmx.de wrote:
Yes, I found that. But it forces you to register with that abysmal
website in order to download the file, which I will avoid at all
costs. It's probably the worstly designed, butt-ugly and confusing
webforum I've
On 13.08.2010 15:36, Wouter van Gulik wrote:
Johannes Bauer schreef:
Hello list,
once again I have a question: I'm playing around with modifications of
avr-gcc. For this I downloaded the latest stable version, 4.5.1. I was
quite surprised to see that it does not include XMega support
On 13.08.2010 10:32, Johannes Bauer wrote:
If it is not possible and I would like to change that myself for
debugging - what parts would I have to look at? Is it easily done or is
that a difficult change?
I've looked into that matter and actually already played around with it
a bit
Hello group,
I think I may have found a bug in the avr-gcc compiler. The created
prologue looks like this with avr-gcc 4.3.4 and a XMega128A1 target:
57b6 __vector_83:
57b6: 1f 92 pushr1
57b8: 0f 92 pushr0
57ba: 0f b6 in
On 12.08.2010 18:13, Johannes Bauer wrote:
This appears to be strange to me. The clr r1 instruction should IMO be
placed after the first push r0 instruction.
You are wrong, Johannes. It appears to you that the clr r1 instruction
should be placed after the SREG has been pushed (obviously
Hi,
On 12.08.2010 19:13, István wrote:
if I am not deluded by my memory, r1 permanently holds 0. Actually clr
r1 is redundant.
Not in an ISR. http://www.nongnu.org/avr-libc/user-manual/FAQ.html says
under What registers are used by the C compiler?
r1 - assumed to be always zero in any C
Hi there,
I propose the attached patch to the iox128a1.h, which includes the
NVM_CMD_ERASE_FLASH_PAGE_gc NVM_CMD_WRITE_FLASH_PAGE_gc and
NVM_CMD_ERASE_WRITE_FLASH_PAGE_gc constants and reorders the enum to be
in ascending order.
Regards,
Johannes
Index: iox128a1.h
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi there,
I've had some trouble today with the XMega. I used memcpy_P, which
usually worked just fine, except for a certain part of my code where it
suddenly produced garbled output. Tracing the source of the problem I
noticed that on the ATxmega I
Hello list,
when relocating data into the flash, this works nicely using the PROGMEM
attribute. However, when trying to relocate data into the bootloader
section of the flash by using
__attribute__ ((section(.bootloader)))
this does still relocate the data into the non-bootloader flash section
Hi Dave,
On 10.05.2010 16:22, Dave Hylands wrote:
__attribute__ ((section(.bootloader)))
this does still relocate the data into the non-bootloader flash section
(although it works perfectly for functions). What must I do to force
data into the bootloader?
The data section itself has to
Dear list,
I'm trying to do rounded (opposed to truncated) integer division with
avr-gcc with using only preprocessor magic. This proves to be difficult:
The current code I'm using is
#define __IDIV(x, y)(long)(((long)x + ((long)y / 2L)) / (long)y)
#define IDIV(x, y) (__IDIV((x),
Hi Jörg,
I've tracked down the problem to be Gentoo-specific. As such, I'm sorry
to have posted it on that list as it is in no way avr-libc/avr-gcc-related.
When using the avr-libc binaries from scratch (i.e. compiling by
yourself) eveyrthing works like a charm. Seems to be a Gentoo-related
Johannes Bauer wrote:
Currently I'll finish my work and then again install the broken Gentoo
libc. Then I'll also be able to supply the information you requested.
I'll also file a Gentoo bug report and post the # of the bug report here
as a reference.
Okay, it's all there:
http
Hi list,
while trying to solve my other problem with the functions I fear I broke
my avr-gcc - tried to get it back to life all day but no luck :-((
I wanted to update avr-gcc from 3.3 to 3.4.6. Compiled all successfully
(woking on a Gentoo system here). Compiling with new avr-gcc also works
Hello people,
I've read quite a bit about the removal of unused functions when using
avr-gcc. In particular I've read Jörg's remarks about the automatic
removal feature being useless and I think this might very well be
correct. He also made a remark about the feature being hardly maintained
and
24 matches
Mail list logo
