Re: [avr-gcc-list] mega168 Support
"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, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] How to (efficeiently !!!) test a bit within amulti-byte integer ?
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 Szczesiul > wrote: > > 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 ffsbrs r24, 2 > > 92: 02 c0rjmp .+4 ; 0x98 > > 94: 81 e0ldi r24, 0x01 ; 1 > > 96: 88 bbout 0x18, r24 ; 24 > > Using pointers to access directly the required byte, > I did think of it, > but didn't dare ! ;-) It's technically elegant I > find, but sadly the > code is not very easy to read I find. > > About the -Os flag, I noticed this morning that it > managed MASSIVE code > size reduction ! SO far I had been using just -O (I > guess that means no > particular optimisation ?), and the program is about > 13KB in size. With > -Os, it's only 10KB !!! Sadly, for some reason, > when compiled with this > flag, my program misbehaves badly (I get massive > corruption of the LCD > display) !! Too bad... :o( > > > > -- > Vince > > > > ___ > AVR-GCC-list mailing list > AVR-GCC-list@nongnu.org > http://lists.nongnu.org/mailman/listinfo/avr-gcc-list > ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] startup file
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 file! Can you please post the exact linker script to eliminate vector table? Thank you very much. Regards Nayani __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] How to (efficeiently !!!) test abitwithinamulti-byte intege
> FWIW, I always had good luck with the delay functions in delay.h for short
> hardcoded (usec) delays. I don't have access to the code now, but I had a
> macro that calculated the minimum number of trips through the four-cycle
> loop that would guarantee the specified delay. Something like
>
>#define usec_count_(x) ((OSC_FREQ*(x))/400)
>#define delay_us(x) _delay_loop_2(usec_count_(x))
>
> It looks like the library also provides _delay_us, which might be better,
> though I've never tried it. Requires you to #define F_CPU before #including
> avr/delay.h.
I picked up this one somewhere:
#define LOOPS_PER_MS (F_CPU/1000/4)
#define LOOPS_PER_US (LOOPS_PER_MS/1000)
/* spin for us microseconds */
void us_spin(unsigned short us)
{
if (!us)
return;
/* the inner loop takes 4 cycles per iteration */
__asm__ __volatile__ (
"1: \n"
" ldi r26, %3 \n"
" ldi r27, %2 \n"
"2: sbiw r26, 1 \n"
" brne 2b \n"
" sbiw %0, 1 \n"
" brne 1b \n"
: "=w" (us)
: "w" (us), "i" (LOOPS_PER_US >> 8), "i" (0xff & LOOPS_PER_US)
);
}
/* spin for ms milliseconds */
void ms_spin(unsigned short ms)
{
if (!ms)
return;
/* the inner loop takes 4 cycles per iteration */
__asm__ __volatile__ (
"1: \n"
" ldi r26, %3 \n"
" ldi r27, %2 \n"
"2: sbiw r26, 1 \n"
" brne 2b \n"
" sbiw %0, 1 \n"
" brne 1b \n"
: "=w" (ms)
: "w" (ms), "i" (LOOPS_PER_MS >> 8), "i" (0xff & LOOPS_PER_MS)
);
}
The ones in avr/delay.h use the same core loop.
--
Dave Hylands
Vancouver, BC, Canada
http://www.DaveHylands.com/
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] mega168 Support
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=detailitem&item_id=2923 for 3.4.4. As well I can call it like: [EMAIL PROTECTED] ~]$ avr-gcc -v -mmcu=atmega168 -Wl,--section-start=.text=0x4000 -o foo foo.c Reading specs from /opt/avr/lib/gcc/avr/3.4.4/specs Configured with: ../configure --prefix=/opt/avr --target=avr --enable-languages=c,c++ --disable-nls : (reconfigured) ../configure --prefix=/opt/avr --target=avr --enable-languages=c --disable-nls Thread model: single gcc version 3.4.4 /opt/avr/libexec/gcc/avr/3.4.4/cc1 -quiet -v foo.c -quiet -dumpbase foo.c -mmcu=atmega168 -auxbase foo -version -o /tmp/ccNSNRkd.s ignoring nonexistent directory "/opt/avr/lib/gcc/avr/3.4.4/../../../../avr/sys-include" #include "..." search starts here: #include <...> search starts here: /opt/avr/lib/gcc/avr/3.4.4/include /opt/avr/lib/gcc/avr/3.4.4/../../../../avr/include End of search list. GNU C version 3.4.4 (avr) compiled by GNU C version 3.4.4 20050721 (Red Hat 3.4.4-2). GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=129224 foo.c:3:26: warning: no newline at end of file /opt/avr/lib/gcc/avr/3.4.4/../../../../avr/bin/as -mmcu=atmega168 -o /tmp/ccGpfgqi.o /tmp/ccNSNRkd.s /opt/avr/lib/gcc/avr/3.4.4/../../../../avr/bin/ld -m avr5 -Tdata 0x800100 -o foo /opt/avr/lib/gcc/avr/3.4.4/../../../../avr/lib/crtm168.o -L/opt/avr/lib/gcc/avr/3.4.4 -L/opt/avr/lib/gcc/avr/3.4.4/../../../../avr/lib --section-start=.text=0x4000 /tmp/ccGpfgqi.o -lgcc -lc -lgcc Where foo.c is just a basic C program that does nothing. So it doesn't seem to complain? Binutils is 2.16, unpatched. Does that need a patch as well, it looked to me like support got integrated into 2.16. When run from my makefile I see the following: Linking: tinyloader.elf avr-gcc tinyloader.o --output tinyloader.elf -Wl,--section-start=.text=0x3E00 -Wl,-Map=tinyloader.map,--cref -nostartfiles -v Reading specs from /opt/avr/lib/gcc/avr/3.4.4/specs Configured with: ../configure --prefix=/opt/avr --target=avr --enable-languages=c,c++ --disable-nls : (reconfigured) ../configure --prefix=/opt/avr --target=avr --enable-languages=c --disable-nls Thread model: single gcc version 3.4.4 /opt/avr/lib/gcc/avr/3.4.4/../../../../avr/bin/ld -m avr2 -o tinyloader.elf -L/opt/avr/lib/gcc/avr/3.4.4 -L/opt/avr/lib/gcc/avr/3.4.4/../../../../avr/lib tinyloader.o --section-start=.text=0x3E00 -Map=tinyloader.map --cref -lgcc -lc -lgcc /opt/avr/lib/gcc/avr/3.4.4/../../../../avr/bin/ld: address 0x3f9e of tinyloader.elf section .text is not within region text make: *** [tinyloader.elf] Error 1 The key line being: /opt/avr/lib/gcc/avr/3.4.4/../../../../avr/bin/ld -m avr2 -o tinyloader.elf Which has avr2, whereas before it was avr5. When does this get set? Regards, -Colin Regards, -Colin ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] How to (efficeiently !!!) test abitwithinamulti-byte intege
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 when
optomisation
is on, it fails. The solution is simply to make n "volatile". Note that
it
will not give you precise control of your delay - different optomisations
or
different compiler versions might give slightly different code, and may or
may not inline the function. But in a case like this it doesn't matter -
all you are looking for is a slight delay, and it doesn't matter if it is
too long. I've done exactly this sort of thing (with "volatile",
naturally)
myself for LCD routines.
FWIW, I always had good luck with the delay functions in delay.h for short
hardcoded (usec) delays. I don't have access to the code now, but I had a
macro that calculated the minimum number of trips through the four-cycle
loop that would guarantee the specified delay. Something like
#define usec_count_(x) ((OSC_FREQ*(x))/400)
#define delay_us(x) _delay_loop_2(usec_count_(x))
It looks like the library also provides _delay_us, which might be better,
though I've never tried it. Requires you to #define F_CPU before #including
avr/delay.h.
Regards,
-=Dave
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] startup file
--- 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? __ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] mega168 Support
"Colin O'Flynn" <[EMAIL PROTECTED]> wrote:
> Any idea how to fix it for real?
Seems your compiler is incorrectly patched. When I call avr-gcc with
-v, it gives me:
% avr-gcc -v -mmcu=atmega168 -Wl,--section-start=.text=0x3E00 -o foo foo.c
Reading specs from /usr/local/lib/gcc/avr/3.4.4/specs
Configured with: ./configure --target=avr --disable-nls --prefix=/usr/local
i386-portbld-freebsd5.3
Thread model: single
gcc version 3.4.4
/usr/local/libexec/gcc/avr/3.4.4/cc1 -quiet -v foo.c -quiet -dumpbase foo.c
-mmcu=atmega168 -auxbase foo -version -o /var/tmp//cc6Zs6uF.s
ignoring nonexistent directory
"/usr/local/lib/gcc/avr/3.4.4/../../../../avr/sys-include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/lib/gcc/avr/3.4.4/include
/usr/local/lib/gcc/avr/3.4.4/../../../../avr/include
End of search list.
GNU C version 3.4.4 (avr)
compiled by GNU C version 3.4.2 [FreeBSD] 20040728.
GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64436
/usr/local/lib/gcc/avr/3.4.4/../../../../avr/bin/as -mmcu=atmega168 -o
/var/tmp//ccoG61Gn.o /var/tmp//cc6Zs6uF.s
/usr/local/lib/gcc/avr/3.4.4/../../../../avr/bin/ld -m avr5 -Tdata 0x800100 -o
foo /usr/local/lib/gcc/avr/3.4.4/../../../../avr/lib/avr5/crtm168.o
-L/usr/local/lib/gcc/avr/3.4.4/avr5 -L/usr/local/lib/gcc/avr/3.4.4
-L/usr/local/lib/gcc/avr/3.4.4/../../../../avr/lib/avr5
-L/usr/local/lib/gcc/avr/3.4.4/../../../../avr/lib --section-start=.text=0x3E00
/var/tmp//ccoG61Gn.o -lgcc -lc -lgcc
Trying to allocate beyond 0x4000 doesn't give me an error either
(which is expected for avr5).
My GCC patch is:
diff -ur ../gcc-3.4.4.orig/gcc/config/avr/avr.c ./gcc/config/avr/avr.c
--- ../gcc-3.4.4.orig/gcc/config/avr/avr.c Sun Mar 20 22:14:28 2005
+++ ./gcc/config/avr/avr.c Mon Sep 12 22:54:25 2005
@@ -175,6 +175,12 @@
{ "at90c8534", 2, "__AVR_AT90C8534__" },
{ "at90s8535", 2, "__AVR_AT90S8535__" },
{ "at86rf401", 2, "__AVR_AT86RF401__" },
+/* Classic + MOVW, <= 8K. */
+ { "attiny13", 2, "__AVR_ATtiny13__" },
+ { "attiny2313", 2, "__AVR_ATtiny2313__" },
+ { "attiny25", 2, "__AVR_ATtiny25__" },
+ { "attiny45", 2, "__AVR_ATtiny45__" },
+ { "attiny85", 2, "__AVR_ATtiny85__" },
/* Classic, > 8K. */
{ "avr3", 3, NULL },
{ "atmega103", 3, "__AVR_ATmega103__" },
@@ -185,19 +191,40 @@
/* Enhanced, <= 8K. */
{ "avr4", 4, NULL },
{ "atmega8", 4, "__AVR_ATmega8__" },
+ { "atmega48", 4, "__AVR_ATmega48__" },
+ { "atmega88", 4, "__AVR_ATmega88__" },
{ "atmega8515", 4, "__AVR_ATmega8515__" },
{ "atmega8535", 4, "__AVR_ATmega8535__" },
+ { "at90pwm2", 4, "__AVR_AT90PWM2__" },
+ { "at90pwm3", 4, "__AVR_AT90PWM3__" },
/* Enhanced, > 8K. */
{ "avr5", 5, NULL },
{ "atmega16", 5, "__AVR_ATmega16__" },
{ "atmega161", 5, "__AVR_ATmega161__" },
{ "atmega162", 5, "__AVR_ATmega162__" },
{ "atmega163", 5, "__AVR_ATmega163__" },
+ { "atmega164", 5, "__AVR_ATmega164__" },
+ { "atmega165", 5, "__AVR_ATmega165__" },
+ { "atmega168", 5, "__AVR_ATmega168__" },
{ "atmega169", 5, "__AVR_ATmega169__" },
{ "atmega32", 5, "__AVR_ATmega32__" },
{ "atmega323", 5, "__AVR_ATmega323__" },
+ { "atmega324", 5, "__AVR_ATmega324__" },
+ { "atmega325", 5, "__AVR_ATmega325__" },
+ { "atmega3250", 5, "__AVR_ATmega3250__" },
+ { "atmega329", 5, "__AVR_ATmega329__" },
+ { "atmega3290", 5, "__AVR_ATmega3290__" },
+ { "atmega640", 5, "__AVR_ATmega640__" },
{ "atmega64", 5, "__AVR_ATmega64__" },
+ { "atmega644", 5, "__AVR_ATmega644__" },
+ { "atmega645", 5, "__AVR_ATmega645__" },
+ { "atmega6450", 5, "__AVR_ATmega6450__" },
+ { "atmega649", 5, "__AVR_ATmega649__" },
+ { "atmega6490", 5, "__AVR_ATmega6490__" },
{ "atmega128", 5, "__AVR_ATmega128__" },
+ { "atmega1280",5, "__AVR_ATmega1280__" },
+ { "atmega1281",5, "__AVR_ATmega1281__" },
+ { "at90can128", 5, "__AVR_AT90CAN128__" },
--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Compiling gcc-avr : how to enable dwarf-2 option ?
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 dissassembly annotation. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Compiling gcc-avr : how to enable dwarf-2 option ?
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, it's merely incidentical that avr-gdb already works with DWARF-2 at all. This has never been designed or activated by someone for the AVR target, it's only a by-product of DWARF-2 being enabled for GCC/GDB's major platforms (i386/amd64). -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] How to (efficeiently !!!) test a bit within a multi-byte integer ?
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?). I compiled 3.4.3 ... does 3.4.4 or 4.0 do a better job at it ? With gcc-3.4.4 and -Os, the compiler loads 4 registers with the 32 bits value (address) and then use 'sbrs ,2' to perform the test. Hence it is very fast. It would be faster if it needs only one register to test however. I did not test with gcc-4.x Well, as we saw earlier today: uint8_t temp; temp = (address >> 16) & 0xFF; if (temp & 0x04) works perfectly, much simpler and cleaner than all the union stuff ! :o) It's still dirty: one do not understand why there is such a mess unless it's documented. And optimization is again compiler dependent: use of 'sbrs' is probably quicker... I am not sure if it's anymore portable (does the >> operator shift left in systems where MSB is stored first ?) but my program won't ever be Yes '>>' will work the same everywhere otherwise portability would be a nightmare. Bernard ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] How to (efficeiently !!!) test a bit within amulti-byte integer ?
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 (this >feeds cascaded shift registers, that in turn drive the 19 address lines >of a memory chip). > For a long time I always put address bit 0 on address pin A0 of the memory, bit 1 on A1, etc. But this is not always needed! Especially for a RAM device where you the AVR is the only one having access, the address lines can be swapped as you like. The same holds for the data lines. For ROM memory I have use this as well to enable better PCB routing and just swapped the contents before flashing. In your case if your reverse the order of A0-A18 to A18-A0, you could start with outputting bit 0. I'm not sure if this results in smaller/faster code in your case, but I found it a nice extra design parameter I could play with. Regards, Martijn. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Compiling gcc-avr : how to enable dwarf-2 option ?
* Joerg Wunsch <[EMAIL PROTECTED]> [2005-11-04 13:46]: Vincent Trouilliez <[EMAIL PROTECTED]> wrote: I put it there http://www.007.org.uk/~vtrouilliez/temp/ it's the one called "object.list". Something else must be wrong. The backannotated disassembly listing is also supposed to work with stabs debugging. Indeed, I found the stabs+ debugging more useful than dwarf, as ddd/gdb had problems with volatile variables. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] How to (efficeiently !!!) test a bitwithinamulti-byte intege
> From: Vincent Trouilliez <[EMAIL PROTECTED]>
>
> [...]
>
> >About the -Os flag, I noticed this morning that it managed MASSIVE code
> >size reduction ! SO far I had been using just -O (I guess that means no
> >particular optimisation ?), and the program is about 13KB in size. With
> >-Os, it's only 10KB !!! Sadly, for some reason, when compiled with this
> >flag, my program misbehaves badly (I get massive corruption of the LCD
> >display) !! Too bad... :o(
>
> I believe it was Gerry Weinburg who once wrote that "optimization is
easy --
> if you don't have to get the right answer."
>
> I suspect, though, that some of your code might be relying on behavior
> that's not guaranteed (e.g., the value of an uninitialized variable)
rather
> than a bug in the optimizer.
>
> Regards,
>
>-=Dave
>
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 when optomisation
is on, it fails. The solution is simply to make n "volatile". Note that it
will not give you precise control of your delay - different optomisations or
different compiler versions might give slightly different code, and may or
may not inline the function. But in a case like this it doesn't matter -
all you are looking for is a slight delay, and it doesn't matter if it is
too long. I've done exactly this sort of thing (with "volatile", naturally)
myself for LCD routines.
mvh.,
David
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] How to (efficeiently !!!) test a bit within amulti-byte integer ?
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 Trouilliez
Cc: avr-gcc
Subject: Re: [avr-gcc-list] How to (efficeiently !!!) test a bit within
amulti-byte integer ?
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 tried this, but it might be better:
>
> unsigned char temp;
>
> temp = (address >> 16) & 0xFF;
>
> if(temp & 0x04)
> {
>/* Your code */
> }
In other messages & has been replaced with &&.
Ian is close to how I would have handled it. I use a "union32_t" type
a fair bit in my code for no other purpose than to pluck values out
of the middle painlessly.
typedef union union32_t {
struct __attribute__ ((packed)) {
uint8_t a, b, c, d;
} u8;
struct __attribute__ ((packed)) {
uint8_t a;
uint16_t bc;
uint8_t d;
} mixed;
struct __attribute__ ((packed)) {
uint16_t ab, cd;
} u16;
uint32_t u32;
};
union32_t address;
if( address.u8.c && 0x04 )
...
avr-gcc does the expected without "__attribute__ ((packed))" but if
you get to playing in Linux or FreeBSD its needed to do the same as
what avr-gcc does.
Also note the above is sensitive to machine endianess. Macintosh,
Sun, and Irix are big-endian.
--
David Kelly N4HHE, [EMAIL PROTECTED]
Whom computers would destroy, they must first drive mad.
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] mega168 Support
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 just my installation has a problem? Warm Regards, -Colin ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] How to (efficeiently !!!) test a bit withinamulti-byte intege
From: Vincent Trouilliez <[EMAIL PROTECTED]> [...] About the -Os flag, I noticed this morning that it managed MASSIVE code size reduction ! SO far I had been using just -O (I guess that means no particular optimisation ?), and the program is about 13KB in size. With -Os, it's only 10KB !!! Sadly, for some reason, when compiled with this flag, my program misbehaves badly (I get massive corruption of the LCD display) !! Too bad... :o( I believe it was Gerry Weinburg who once wrote that "optimization is easy -- if you don't have to get the right answer." I suspect, though, that some of your code might be relying on behavior that's not guaranteed (e.g., the value of an uninitialized variable) rather than a bug in the optimizer. Regards, -=Dave ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] How to (efficeiently !!!) test a bit within a multi-byte integer ?
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 tried this, but it might be better:
unsigned char temp;
temp = (address >> 16) & 0xFF;
if(temp & 0x04)
{
/* Your code */
}
In other messages & has been replaced with &&.
Ian is close to how I would have handled it. I use a "union32_t" type
a fair bit in my code for no other purpose than to pluck values out
of the middle painlessly.
typedef union union32_t {
struct __attribute__ ((packed)) {
uint8_t a, b, c, d;
} u8;
struct __attribute__ ((packed)) {
uint8_t a;
uint16_t bc;
uint8_t d;
} mixed;
struct __attribute__ ((packed)) {
uint16_t ab, cd;
} u16;
uint32_t u32;
};
union32_t address;
if( address.u8.c && 0x04 )
...
avr-gcc does the expected without "__attribute__ ((packed))" but if
you get to playing in Linux or FreeBSD its needed to do the same as
what avr-gcc does.
Also note the above is sensitive to machine endianess. Macintosh,
Sun, and Irix are big-endian.
--
David Kelly N4HHE, [EMAIL PROTECTED]
Whom computers would destroy, they must first drive mad.
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] How to (efficeiently !!!) test a bit within a multi-byte integer ?
> 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 do a better job at it ?
> To solve such speed problems, you have to tell the compiler that you
> want to perform just a 8 bit operation. So use something like:
>
> union {
> uint32_t my_ulong;;
> struct {
> uint8_t a;
> uint8_t b;
> uint8_t c;
> uint8_t d;
>} my_bytes;
> } value;
>
> value.my_ulong=address;
> if(value.my_bytes.c & 0x40)
>
>
>
> This is very dirty:
>
> Now it solves your problem today, so it's up to you to decide to use it
> or not.
>
> Bernard
Well, as we saw earlier today:
uint8_t temp;
temp = (address >> 16) & 0xFF;
if (temp & 0x04)
works perfectly, much simpler and cleaner than all the union stuff ! :o)
I am not sure if it's anymore portable (does the >> operator shift left
in systems where MSB is stored first ?) but my program won't ever be
ported, it's only a prototype/one-off for my personal use... and
although I do intend to "upgrade" it in the coming years, with a
graphical LCD module instead of a text module, and some basic data
processing and graphing functionality, I think/guess AVR chips should
still be up to the job, when clocked at 16MHz.
--
Vince
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] How to (efficeiently !!!) test a bit within a multi-byte integer ?
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 of an expression. So
if ( address && 0x0004)
is always true if address is not null.
The assembly output is much smaller since the optimizer took away '&&
0x0004' since this part is always true! I gess that if you look at
the full assembly, you'll see 'address' being loaded in r18-r21. So the
compiler just checks that 'address' is not null... (r1 is always at zero
for avr-gcc).
Now your problem with 'address & 0x0004' is a real one: avr-gcc is
not yet very good with 32 bits operators (BTW what version of avr-gcc do
you use?).
To solve such speed problems, you have to tell the compiler that you
want to perform just a 8 bit operation. So use something like:
union {
uint32_t my_ulong;;
struct {
uint8_t a;
uint8_t b;
uint8_t c;
uint8_t d;
} my_bytes;
} value;
value.my_ulong=address;
if(value.my_bytes.c & 0x40)
This is very dirty:
- it is not portable since it relies on the endieness of the target and
compiler (note that it may be value.my_bytes.b to test to have the code
really working, I did not test!)
- It's a pain to maintain since some other people will look at this code
in a few weeks/months/years and think that the person who wrote it was
nut unless it is very well documented.
- In a later version of the compiler it can have the opposite effect and
be less efficient than to have the compiler do correctly its job.
Now it solves your problem today, so it's up to you to decide to use it
or not.
Bernard
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] How to (efficeiently !!!) test a bit withinamulti-byte integer ?
On Fri, 2005-11-04 at 13:23 +0100, niklo wrote: > 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. Yeah I think we got the same idea... I did replace the _delay_us(40) delay loop by a custom made empty for loop, as it's so much more efficient, at least in this particular routine. But looks like -Os doesn't like empty for loops ! I just checked the disassembler output, and the loop has indeed been simply ignored/deleted ! I know, I know, I should wire the LCD R/W line and poll the 'busy' flag instead I will get round to doing it... later... too many other, more important pieces of code to write at the moment, plus, I don't think the program will grow much bigger than 20KB max, and I have 32KB to play with... But that's no excuse for using empty loops instead of proper polling, as polling it the only reliable way of doing it anyway... -- Vince, hiding in the corner... ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] How to (efficeiently !!!) test a bit withinamulti-byte integer ?
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 13:11 To: avr-gcc Subject: Re: [avr-gcc-list] How to (efficeiently !!!) test a bit withinamulti-byte integer ? On Fri, 2005-11-04 at 10:04 +0100, Jurek Szczesiul wrote: > 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 ffsbrs r24, 2 > 92: 02 c0rjmp .+4 ; 0x98 > 94: 81 e0ldi r24, 0x01 ; 1 > 96: 88 bbout 0x18, r24 ; 24 Using pointers to access directly the required byte, I did think of it, but didn't dare ! ;-) It's technically elegant I find, but sadly the code is not very easy to read I find. About the -Os flag, I noticed this morning that it managed MASSIVE code size reduction ! SO far I had been using just -O (I guess that means no particular optimisation ?), and the program is about 13KB in size. With -Os, it's only 10KB !!! Sadly, for some reason, when compiled with this flag, my program misbehaves badly (I get massive corruption of the LCD display) !! Too bad... :o( -- Vince ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] How to (efficeiently !!!) test a bit within amulti-byte integer ?
On Fri, 2005-11-04 at 10:04 +0100, Jurek Szczesiul wrote: > 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 ffsbrs r24, 2 > 92: 02 c0rjmp .+4 ; 0x98 > 94: 81 e0ldi r24, 0x01 ; 1 > 96: 88 bbout 0x18, r24 ; 24 Using pointers to access directly the required byte, I did think of it, but didn't dare ! ;-) It's technically elegant I find, but sadly the code is not very easy to read I find. About the -Os flag, I noticed this morning that it managed MASSIVE code size reduction ! SO far I had been using just -O (I guess that means no particular optimisation ?), and the program is about 13KB in size. With -Os, it's only 10KB !!! Sadly, for some reason, when compiled with this flag, my program misbehaves badly (I get massive corruption of the LCD display) !! Too bad... :o( -- Vince ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] How to (efficeiently !!!) test a bit within a multi-byte integer ?
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, r20 > > 28be: aa 27 eor r26, r26 > > 28c0: bb 27 eor r27, r27 > > if (temp & 0x04) > > 28c2: 82 ff sbrsr24, 2 > > 28c4: 02 c0 rjmp.+4 ; 0x28ca > > > > can't get any better than that really :o))) > > if you make temp unsigned char, it should be even better. Yes I see what you mean, the two 'eor' instructions that clear the two upper bytes The problem is that 'temp' IS declared as uint8_t, and I have no idea why the compiler insists on clearing the upper bytes as if it were casting it into a 32bit integer (then what about the second byte in this case, should get cleared as well ?!). It's only testing a bit in the first (and only) byte, r24, so I don't understand why it care for upper bytes at all. I tried to reword the statement a bit: temp = (uint8_t) (address >> 16) 0xFF; ,as well as change optimisation flags, but it really insists on clearing these two bytes. God knows why. I guess it's doing something very subtle that escapes me... -- Vince ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] How to (efficeiently !!!) test a bit within a multi-byte integer ?
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 > 28c0: bb 27 eor r27, r27 > if (temp & 0x04) > 28c2: 82 ff sbrsr24, 2 > 28c4: 02 c0 rjmp.+4 ; 0x28ca > > can't get any better than that really :o))) if you make temp unsigned char, it should be even better. -Blueloop ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] How to (efficeiently !!!) test a bit within amulti-byte integer ?
>> >> 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 ffsbrs r24, 2 92: 02 c0rjmp .+4 ; 0x98 94: 81 e0ldi r24, 0x01 ; 1 96: 88 bbout 0x18, r24 ; 24 (long1 located at 0x63-0x66 here - Atmega8) HTH Best regards Jurek S. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] How to (efficeiently !!!) test a bit within a multi-byte integer ?
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 = (address >> 16) & 0xFF; > > if(temp & 0x04) 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 28c0: bb 27 eor r27, r27 if (temp & 0x04) 28c2: 82 ff sbrsr24, 2 28c4: 02 c0 rjmp.+4 ; 0x28ca can't get any better than that really :o))) Thanks again -- Vince ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
