RE: [avr-gcc-list] How to (efficeiently !!!) test a bit withinamulti-byte integer ?
So you're personally responsible for making the release? Couldn't someone help you out to make it happen faster? If it would be of any help I have some time... :) /niklo -Original Message- From: Eric Weddington [mailto:[EMAIL PROTECTED] Sent: den 8 november 2005 23:59 To: Niklas Lövgren Cc: 'Vincent Trouilliez'; 'avr-gcc' Subject: Re: [avr-gcc-list] How to (efficeiently !!!) test a bit withinamulti-byte integer ? Niklas Lövgren wrote: That's interesting it makes that much differnce between the minors. So how much better is gcc 4.x.x? And also why isn't the newer gcc versions included in a winavr release? 1. Previously, there have been bugs in that tree affecting the AVR port which has made it a no-go. 2. Because I haven't done a new WinAVR release yet. I'm planning to include 4.0.2 as soon as I can come up for air. Eric ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
[avr-gcc-list] New install not working
On a new laptop windows xp SP2 Installed winavr 20050214 version 3.4.3 Took an existing project that ran under version 3.4.1 And tried to run make all under new install with the same makefile. I get make: ** no rule to make target 'Robot.o', need by Robot.elf stop I added an additional tool menu option to compile individual files to assembler code some run some do not. For instance Make Robot.s does not work. Make FSM.s does not work. Make i2c.s does work. Make DoSonar.s does work. At first I thought it may have been case but DoSonar does work. I tried to use a new Makefile generated by the Mfile utility but I get the same results. As far as I can tell the makefile only has some new dependencies flags. I tried running make directly from the dos prompt and adding -p and -d option and I see it checking a whole lot of extra stuff not related to the makefile ie .info, .dvi,.web. I by no means claim to be a make expert so that really did not help. The demo.c and twi.c examples will compile fine however these are not multi file projects Suggestions? ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] New install not working
Hi Biill, Took an existing project that ran under version 3.4.1 And tried to run make all under new install with the same makefile. I get make: ** no rule to make target 'Robot.o', need by Robot.elf stop Compare the case of the filenames as they exist on your harddrive to the case of the files as they appear in the Mmakefile. Perhaps the make utility released with the newer WinAVR was compiled with a different set of options. -- 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] AVR assembly for fast bit bang
On Wed, 9 Nov 2005 21:25, Mike S. wrote: Thanks for the reply Daniel O'Connor, but I usually don't use the optimization until I try a couple of and optimization techniques. I already had some bad experiences with the optimization in some Texas Instruments DSPs... If you don't tell GCC to do *any* optimisation it will generate really terrible code. -O is very well tested, I suggest you use it. Just because one compiler somewhere generated bogus code when asked to optimise doesn't mean they all do it. I'm not suggesting GCC is bug free either, but trying to use unoptimised code on a microcontroller is asking for serious code size and performance issues. I use AVR-GCC. Well that's good since this is the avr-gcc list :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpngUbWiWiIy.pgp Description: PGP signature ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] AVR assembly for fast bit bang
From: David Kelly [EMAIL PROTECTED]
[...]
People keep saying C isn't fast enough. I don't belive it. First
attempt:
#include avr/io.h
#define CLOCK_B (10)
#define BIT_B (11)
void
myjunk(uint8_t byte) {
uint8_t i;
for( i = 0 ; i 8 ; i++ ) {
PORTA |= CLOCK_B; // rising edge of clock
if( byte (17) )
PORTA |= BIT_B; // set
else
PORTA = ~BIT_B;// clear
byte = 1;
PORTA = ~CLOCK_B; // falling edge of clock
}
}
[...snip assembly...]
It might be tough to do better on AVR. My standard SPI routine uses a
do-while loop, which might save an instruction or two, but made about a 30%
difference on the PIC compiler I used. Something like
void output_spi_byte(uint8_t byte)
{
uint8_t bit_ctr = 8;
do
{
output_low(SPI_DATA); // Set data bit low...
if (byte 0x80)
output_high(SPI_DATA); // ...or high, as required
output_high(SPI_CLK);
byte = 1; // Shift acts as clock dwell delay
output_low(SPI_CLK);
} while (--bit_ctr);
}
I don't have avr-gcc handy to see if it's any better than your code. I was
more concerned with size than speed, as you may be able to tell. If speed
is the ultimate object, unrolling the loop will help.
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] AVR assembly for fast bit bang
void write_data (Word towrite, Byte nbits)
{
Byte n;
for(n = 0; n nbits; n++)
{
CLK_HIGH;
if( towrite (0x0001 n))
{
SDIO_HIGH;
}
else
{
SDIO_LOW;
}
CLK_LOW;
}
}
This will give very slow code, because a left shift by a variable will allways
take lots of cycles. Even with optimisation on this will give slow code. This
should work better:
void write_data (Word towrite, Byte nbits)
{
Byte n;
for(n = 0; n nbits; n++)
{
CLK_HIGH;
if( towrite 0x001)
{
SDIO_HIGH;
}
else
{
SDIO_LOW;
}
CLK_LOW;
towrite = 1;
}
}
Now always one shift is done with each cycle of the loop.
You should look at the dissassembler listing when you get this sort of
problem. Then you can see, what the compiler does, and optimize your C code,
so the compiler can generate better assembly for you.
I also suggest, you allways turn optimization on! This works very well with
gcc, I always use -Os, and haven't had any broken code problems so far.
Regards,
Peter
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] AVR assembly for fast bit bang
You'll find this modification / correction helps with speed because you don't
have to evaluate (1n) each time through the loop. Only a single bit shift on
the 16-bit value is required.
#define ADS1210_PORT PORTF
#define SDIO_BIT 0x04 /* 0b 0100 PORTF.2*/
#define CLK_BIT 0x02 /* 0b 0010 PORTF.1*/
#define SDOUT_BIT0x01 /* 0b 0001 PORTF.0*/
#define SDIO_LOWADS1210_PORT = ~SDIO_BIT
#define SDIO_HIGH ADS1210_PORT |= SDIO_BIT
#define CLK_LOW ADS1210_PORT = ~CLK_BIT
#define CLK_HIGH ADS1210_PORT |= CLK_BIT
/*+
| Function: write_data|
| |
| Args: n_bits|
| |
| Action: Writes n_bits in the device SDIO input pin |
| |
| Efects: |
| |
+*/
void write_data (Word towrite, Byte nbits)
{
Word mask;
Byte bitbount;
for(mask=0x0001, bitcount=nbits; bitcount != 0; mask=1, bitcount--)
{
CLK_HIGH;
if( towrite mask)
{
SDIO_HIGH;
}
else
{
SDIO_LOW;
}
CLK_LOW;
}
}
Nigel Winterbottom
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] AVR assembly for fast bit bang
Hi,
I think there are two problems with the code:
- using 16 bit data
- shifting by a variable number of bits
An optimization would be to write a funktion which only shifts up to 8
bit, and to shift the data every time by one bit.
Regards,
Nils
original code:
void write_data (Word towrite, Byte nbits)
{
Byte n;
for(n = 0; n nbits; n++)
{
CLK_HIGH;
if( towrite (0x0001 n))
{
SDIO_HIGH;
}
else
{
SDIO_LOW;
}
CLK_LOW;
}
}
my version:
void write_data_byte (Byte towrite, Byte nbits)
{
while(nbits--)
{
CLK_HIGH;
if (towrite0x01)
{
SDIO_HIGH;
}
else
{
SDIO_LOW;
}
CLK_LOW;
towrite = towrite1; // shift by constant value
}
}
void write_data (Word towrite, Byte nbits)
{
if (nbits8)
{
write_data_byte((Byte)towrite, 8);
write_data_byte((Byte)(towrite8), nbits-8);
}
else
{
write_data_byte((Byte)towrite, nbits);
}
}
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] New install not working
Dave Hylands wrote: Hi Biill, Took an existing project that ran under version 3.4.1 And tried to run make all under new install with the same makefile. I get make: ** no rule to make target 'Robot.o', need by Robot.elf stop Compare the case of the filenames as they exist on your harddrive to the case of the files as they appear in the Mmakefile. Perhaps the make utility released with the newer WinAVR was compiled with a different set of options. Hi Dave, Yes, IIRC, the GNU Make is now case-sensitive, so that could be the issue. -- Eric Weddington ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Compiling avr-libc-1_2-branch from cvs
As John Altstadt wrote: This is the exact problem I reported a few months ago at http://savannah.nongnu.org/bugs/?func=detailitemitem_id=13416 Yep, these auto tools are not very consistent. While they introduced major backwards compatibility headaches to anyone using them, they simply don't manage it to pass the names they have been called with down into the generated scripts, so e.g. if you ran automake13, it will later try to call either automake or automake-1.3 (which both don't exist on my systems). The workaround given in the bug report is to temporarily rename the various autoconf files in /usr/bin. E.g. # mv autoconf autoconf.original # mv autoconf-2.13 autoconf That's why I cannot see that on my FreeBSD machines. The port maintainers of the auto tools have chosen to never install any of these tools by their generic names anymore. -- cheers, Jorg .-.-. --... ...-- -.. . 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 avr-libc-1_2-branch from cvs
Joerg Wunsch wrote: As John Altstadt wrote: This is the exact problem I reported a few months ago at http://savannah.nongnu.org/bugs/?func=detailitemitem_id=13416 Yep, these auto tools are not very consistent. While they introduced major backwards compatibility headaches to anyone using them, they simply don't manage it to pass the names they have been called with down into the generated scripts, so e.g. if you ran automake13, it will later try to call either automake or automake-1.3 (which both don't exist on my systems). I do have to say that in 20 years of designing large and small embedded systems, I have never once felt the urge to use any autotools. :-) The workaround given in the bug report is to temporarily rename the various autoconf files in /usr/bin. E.g. # mv autoconf autoconf.original # mv autoconf-2.13 autoconf That's why I cannot see that on my FreeBSD machines. The port maintainers of the auto tools have chosen to never install any of these tools by their generic names anymore. I was thinking that this particular problem is Gentoo specific. Normally they do a great job of keeping multiple versions of packages installed on the system. It looks like this package didn't quite work out though. On Gentoo, /usr/bin/autoconf is a soft link to a bash script which tries to figure out which version of autoconf to actually execute. It would appear to be optimized for use within ebuilds (similar idea to ports). John ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] AVR assembly for fast bit bang
On Wed, Nov 09, 2005 at 09:00:58AM -0500, Dave Hansen wrote:
From: David Kelly [EMAIL PROTECTED]
[...]
People keep saying C isn't fast enough. I don't belive it. First
attempt:
[...]
It might be tough to do better on AVR. My standard SPI routine uses a
do-while loop, which might save an instruction or two, but made
about a 30%
difference on the PIC compiler I used. Something like
void output_spi_byte(uint8_t byte)
{
uint8_t bit_ctr = 8;
do
{
output_low(SPI_DATA); // Set data bit low...
if (byte 0x80)
output_high(SPI_DATA); // ...or high, as required
output_high(SPI_CLK);
byte = 1; // Shift acts as clock dwell delay
output_low(SPI_CLK);
} while (--bit_ctr);
}
I don't have avr-gcc handy to see if it's any better than your
code. I was
more concerned with size than speed, as you may be able to tell.
If speed
is the ultimate object, unrolling the loop will help.
The above compiles to 14 bytes with slight changes
(output_low/output_high macros). But I would suggest putting
output_low(SPI_DATA) as an else to if (byte 0x80) as needless
transitions consume power, generate noise, and sometimes confuse the
connected device. Moving it into an else results in 16 byte code.
Forgot how big mine was. A little big bigger IIRC.
--
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] Compiling avr-libc-1_2-branch from cvs
John Altstadt [EMAIL PROTECTED] wrote: Yep, these auto tools are not very consistent. [...] I do have to say that in 20 years of designing large and small embedded systems, I have never once felt the urge to use any autotools. :-) Sure, for just your own tool, you don't need that. But if you want something that can be compiled on different OSes, where you can check for the prerequisite software, and want to offer the users some choices including that of the final installation location (configure --prefix), *something* like these tools is really handy. On Gentoo, /usr/bin/autoconf is a soft link to a bash script which tries to figure out which version of autoconf to actually execute. Well, I see the point in that idea, but guess it's hard to impossible to really do that. -- cheers, Jorg .-.-. --... ...-- -.. . 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 avr-libc-1_2-branch from cvs
Joerg Wunsch wrote: John Altstadt [EMAIL PROTECTED] wrote: Yep, these auto tools are not very consistent. [...] I do have to say that in 20 years of designing large and small embedded systems, I have never once felt the urge to use any autotools. :-) Sure, for just your own tool, you don't need that. But if you want something that can be compiled on different OSes, where you can check for the prerequisite software, and want to offer the users some choices including that of the final installation location (configure --prefix), *something* like these tools is really handy. As I said, embedded systems. When you use 2MLOC to run multiple non-heterogeneous processors on a single board (the daughter board had up to another 448 DSP cores on it, but their binary was supplied by a third party developer), you don't much care about different OSs. You also don't load something like that on an AVR. John ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
