On Fri, 2005-11-04 at 15:20 +0800, Ian Caddy wrote:
Hi Vince,
All your new code is doing is checking that address is non-zero as it is
a logical AND with a non-zero number, which would get optimised out.
I haven't tried this, but it might be better:
unsigned char temp;
temp =
unsigned char temp;
temp = (address 16) 0xFF;
if(temp 0x04)
Hi Vince !
You could also try to retrieve directly the 2. ( from 0) byte of ulong and check
the bit , something like this ( -Os) :
if( *((uchar*)long1+2) 0x4) PORTB = 0x1;
8c: 80 91 65 00 lds r24, 0x0065
90: 82 ff
Him
Vincent Trouilliez schrieb:
Thank you very much Ian, your code is highly efficient, and does work
perfectly, unlike or . :o) I am in heaven :
temp = (address 16) 0xFF;
28bc: ca 01 movwr24, r20
28be: aa 27 eor r26, r26
On Fri, 2005-11-04 at 10:17 +0100, Alex Wenger wrote:
Him
Vincent Trouilliez schrieb:
Thank you very much Ian, your code is highly efficient, and does work
perfectly, unlike or . :o) I am in heaven :
temp = (address 16) 0xFF;
28bc: ca 01 movwr24,
Does your lcd-routines rely on busy-waiting? That might be the reason why
opt doesn't work. I don't know but badly written wait-loops might e opt'ed
away.
/niklo
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Vincent Trouilliez
Sent: den 4 november 2005
Vincent Trouilliez wrote:
I replaced the '' operator with the more appropriate '' one works
much better... 5 instructions instead of 115 (3 + 6*18 + 4) for the
previous code.
Unfortunately, '' and '' are very different. '' is the correct bit
operator to use, '' will check the result
Now your problem with 'address 0x0004' is a real one: avr-gcc is
not yet very good with 32 bits operators
Well, this way we have nice things to be looking forward to, for
upcoming releases of gcc :-)
(BTW what version of avr-gcc do you use?).
I compiled 3.4.3 ... does 3.4.4 or 4.0
On Nov 3, 2005, at 11:35 PM, Vincent Trouilliez wrote:
static void log_address_set( uint32_t address )
{
...
...
if (address 0x0004)
PORTB |= LOG_SDA;
else
PORTB = ~LOG_SDA;
...
}
On Nov 4, 2005, at 1:20 AM, Ian Caddy wrote:
I haven't
Hey,
Any idea how to fix it for real? I just added this linker option:
/opt/avr/avr/lib/ldscripts/avr5.x
to force it to pick up avr5.x and not whatever it was. What might be a related
problem is I had to symlink crtm168.o from /opt/avr/avr/lib/crtm168.o
to /opt/avr/lib/avr5/crtm168.o
Or is it
Great!
But you still have to use the correct operator:
is bit-wise and
is logical and
You probably want otherwise why compare with 0x04?
/niklo
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of David
Kelly
Sent: den 4 november 2005 14:37
To: Vincent
Vincent,
I just remembered something that might be of use.
This is a quote
from your first message:
I just ran into a weird problem that I hardly
expected.
I wrote a trivial routine that takes a 32bit unsigned int, which holds
a
memory address, and shifts the lower 19 bits, out to a port pin
Vincent Trouilliez wrote:
Now your problem with 'address 0x0004' is a real one: avr-gcc is
not yet very good with 32 bits operators
Well, this way we have nice things to be looking forward to, for
upcoming releases of gcc :-)
(BTW what version of avr-gcc do you use?).
Lars Noschinski [EMAIL PROTECTED] wrote:
Indeed, I found the stabs+ debugging more useful than dwarf, as
ddd/gdb had problems with volatile variables.
IIRC with all (global/static) variables. The offset 0x80
for RAM access isn't being taken into account.
I've already wrote it elsewhere,
Vincent Trouilliez [EMAIL PROTECTED] wrote:
Now that I have enabled dwarf-2 and recompiled gcc, I noticed that I
still loose the annotations, if I use the -O3 optimisation flag, but
not if I use -O or -Os.
Keep in mind that -O3 will inline a lot of functions. That
could really confuse the
--- Parthasaradhi Nayani [EMAIL PROTECTED] wrote:
Hello all,
I have written a very simple bootloader and it is
working OK. I would like to eliminate the intial
interrupt vectors to get more flash space.
Have you tried to remove *(.vectors) from the linker script?
From: David Brown [EMAIL PROTECTED]
[...]
The bug is almost certainly a delay loop variable that is not declared
volatile. The delay function is probably something like:
void shortDelay(void) {
uint8_t n = 50;
while (n--);
}
That (might) work fine with little or no optomisation, but
Hello,
Seems your compiler is incorrectly patched. When I call avr-gcc with
-v, it gives me:
I used the patch at
https://savannah.nongnu.org/patch/?func=detailitemitem_id=2923 for 3.4.4. As
well I can call it like:
[EMAIL PROTECTED] ~]$ avr-gcc -v -mmcu=atmega168
Hello Bernd Trog,
--- Bernd Trog [EMAIL PROTECTED] wrote:
Have you tried to remove *(.vectors) from the
linker script?
Thanks for the reply. I was not sure if one could
remove vector table from being linked. I am under the
impression that vector table is a part and parcel of
the startup
Empty loops and optimization don't go together. Also
check to ensure you're using 'volatile' where
appropriate. I'm running into this same problem with
some inherited code at work right now.
Tubbs
--- Vincent Trouilliez
[EMAIL PROTECTED] wrote:
On Fri, 2005-11-04 at 10:04 +0100, Jurek
Colin O'Flynn [EMAIL PROTECTED] wrote:
Linking: tinyloader.elf
avr-gcc tinyloader.o --output tinyloader.elf
-Wl,--section-start=.text=0x3E00
-Wl,-Map=tinyloader.map,--cref -nostartfiles -v
Ah, now I see it. You forgot to add the -mmcu option into that
command.
--
cheers, Jorg
20 matches
Mail list logo
