Nabble - AVR

avrdude high-voltage programming

2009-11-10T04:48:30Z

I am currently working on several Attiny projects. One of these needs an
extra I/O so I must use the RESET pin. This necessitates the use of
high-voltage serial programming.
I am completely unable to get AVRDUDE to talk to my STK500v2 in hvsp mode.

*************************************************************************
avrdude -p t13 -c stk500hvsp -P /dev/ttyS1 -B 15 -t -F

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x000000
avrdude: Yikes! Invalid device signature.
avrdude: Expected signature for ATtiny13 is 1E 90 07
avrdude>
*************************************************************************
This is AVRDUDE version 5.8 on OpenSUSE 10.2

Using the same PC and STK500, over the same serial port but driven from
AVR Studio on Windows XP running in a VMware virtual machine, I can
succesfully program, read & write the part. This seems to exonerate the
hardware. Also the same combination of PC, STK500 and Tiny13 programs
fine in 'normal' mode (P stk500v2).

Has anyone experience of the high-voltage serial mode or can see what I
am doing wrong?

Many thanks,

Robert von Knobloch

_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

From forum: AVR - General

Re: __builtin_constant_p for inline func args with -Os

2009-11-08T13:04:48Z

Thanks! That works perfectly. :-)

I was totally misunderstanding the problem. Just one little attribute,
but it's a huge help.

Thanks again.

-Paul

Joerg Wunsch wrote:

> Paul Stoffregen <paul@...> wrote:
>
>
>> Indeed it works great with -O2. But with -Os, __builtin_constant_p
>> never returns 1.
>>
>
> It appears to me GCC simply thinks inlining the function would not be
> feasible with -Os -- well, partially at least. If you declare your
> function as
>
> static inline void __attribute__((always_inline))
> digitalWrite(uint8_t pin, uint8_t val)
>
> (thus overriding GCC's heuristics about inlining), it yields your
> desired result:
>
> main:
> /* prologue: function */
> /* frame size = 0 */
> sbi 43-32,2
> lds r24,num
> ldi r22,lo8(1)
> call _digitalWrite
> sbi 43-32,2
> ..L2:
> rjmp .L2
>
>

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

From forum: AVR - gcc

Re: __builtin_constant_p for inline func args with -Os

2009-11-08T12:43:50Z

Os is not inlining the function - since it believe it will cause code size to grow.

You can find this out by using inline warning option
-Winline

However, you can FORCE a function to be inlined thus

static inline void digitalWrite(uint8_t pin, uint8_t val) __attribute__((always_inline));
static inline void digitalWrite(uint8_t pin, uint8_t val)

...which fixs your problem

Andy

Paul Stoffregen wrote:

I'm trying to create an inline function (instead of a preprocessor macro) which uses __builtin_constant_p to test if its args are compile time constants. According to the manual, this is supposed to work with optimization enabled.

You may use this built-in function in either a macro or an inline
function. However, if you use it in an inlined function and pass an
argument of the function as the argument to the built-in, GCC ....
will not return 1 when you pass a constant numeric value to the
inline function unless you specify the -O option.

Indeed it works great with -O2. But with -Os, __builtin_constant_p never returns 1.

Is this a bug? Or is __builtin_constant_p just not supported with -Os? Or did I do something stupidly wrong?

My test code is attached.

Thanks,

-Paul
_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
  

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

From forum: AVR - gcc

Re: __builtin_constant_p for inline func args with -Os

2009-11-08T12:39:02Z

Paul Stoffregen <paul@...> wrote:

> Indeed it works great with -O2. But with -Os, __builtin_constant_p
> never returns 1.

It appears to me GCC simply thinks inlining the function would not be
feasible with -Os -- well, partially at least. If you declare your
function as

static inline void __attribute__((always_inline))
digitalWrite(uint8_t pin, uint8_t val)

(thus overriding GCC's heuristics about inlining), it yields your
desired result:

main:
/* prologue: function */
/* frame size = 0 */
sbi 43-32,2
lds r24,num
ldi r22,lo8(1)
call _digitalWrite
sbi 43-32,2
..L2:
rjmp .L2

--
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@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

From forum: AVR - gcc

__builtin_constant_p for inline func args with -Os

2009-11-08T12:14:10Z

I'm trying to create an inline function (instead of a preprocessor
macro) which uses __builtin_constant_p to test if its args are compile
time constants. According to the manual, this is supposed to work with
optimization enabled.

You may use this built-in function in either a macro or an inline
function. However, if you use it in an inlined function and pass an
argument of the function as the argument to the built-in, GCC ....
will not return 1 when you pass a constant numeric value to the
inline function unless you specify the -O option.

Indeed it works great with -O2. But with -Os, __builtin_constant_p
never returns 1.

Is this a bug? Or is __builtin_constant_p just not supported with -Os?
Or did I do something stupidly wrong?

My test code is attached.

Thanks,

-Paul

// compile with:
//
// avr-gcc -mmcu=atmega168 -g -Os -c test2.c
//
// disassemble with:
//
// avr-objdump -d -S test2.o

#include <avr/io.h>

extern void _digitalWrite(uint8_t pin, uint8_t val);

// With -Os __builtin_constant_p never returns true
// With -O2 __builtin_constant_p works properly

static inline void digitalWrite(uint8_t pin, uint8_t val)
{
if (__builtin_constant_p(pin) && __builtin_constant_p(val)) {
if (val) {
if (pin == 0) {
PORTD |= _BV(0);
} else if (pin == 1) {
PORTD |= _BV(1);
} else if (pin == 2) {
PORTD |= _BV(2);
} else {
}
} else {
if (pin == 0) {
PORTD &= ~_BV(0);
} else if (pin == 1) {
PORTD &= ~_BV(1);
} else if (pin == 2) {
PORTD &= ~_BV(2);
} else {
}
}
} else {
_digitalWrite(pin, val);
}
}

volatile uint8_t num=2;

int main(void)
{
PORTD |= 0x04; // should optimize to single instruction
digitalWrite(num, 1); // should call function
digitalWrite(2, 1); // should optimize to single instruction
while (1) ;
}

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

From forum: AVR - gcc

RE: passing pointers to functions

2009-11-07T20:13:25Z

Two things:

1. IIRC, there was a problem with 4.3.0 unless you had the right patches. It may not be related to your problem, but we need to know what platform you're building on, and what patches are you using. You may need to upgrade.

2. We need to have a compilable test case, preferably as small as possible, that shows the error. There is not enough information here to tell you one way or the other what is going on with your code.

Honestly I suspect something in your code, and not the compiler.

> -----Original Message-----
> From:
> avr-gcc-list-bounces+eric.weddington=atmel.com@...
> [mailto:avr-gcc-list-bounces+eric.weddington=atmel.com@nongnu.
> org] On Behalf Of don clay
> Sent: Saturday, November 07, 2009 1:08 PM
> To: avr-gcc-list@...
> Subject: [avr-gcc-list] passing pointers to functions
>
> I have been having difficulty passing a function pointer in a
> function call. In
> researching the issue, it appears that there is a compiler
> issue with doing that &
> I've tried a couple of suggested fixes with no luck.
>
> Since the version appears to required in order to get the
> correct fix, my version
> is gcc-4.3.0.
>
> This is my last attempt.
>
> 1. Here is the function prototype in the .h file
>
> void InsertTask(ptr2func TaskPtr); // line
> 42 in atm328.h
>
> 2. Here is the code in the single .c file containing all the
> code related to this
> issue.
>
> typedef void (*ptr2func)(void);
>
> Here is the function
>
> void InsertTask(ptr2func TaskPtr)
>
> Here is the call
>
> InsertTask(LEDTask);
>
>
> 3. Here is the returned error.
>
> ../atm328.h:42: error: expected ')' before 'TaskPtr'
>
>
> Before I try updating avr gcc, is there something else that I
> need to do in order
> to make this work?
>
> thanks.
>
>
>
> _______________________________________________
> AVR-GCC-list mailing list
> AVR-GCC-list@...
> http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
>

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

From forum: AVR - gcc

Re: passing pointers to functions

2009-11-07T12:21:50Z

It may be because ptr2func is not declared before the prototype. Try putting the typedef of ptr2func in the header file above the prototypes.

--John

On Sat, Nov 7, 2009 at 12:07 PM, don clay <donclay@...> wrote:

I have been having difficulty passing a function pointer in a function call. In
researching the issue, it appears that there is a compiler issue with doing that &
I've tried a couple of suggested fixes with no luck.

Since the version appears to required in order to get the correct fix, my version
is gcc-4.3.0.

This is my last attempt.

1. Here is the function prototype in the .h file

void InsertTask(ptr2func TaskPtr); // line 42 in atm328.h

2. Here is the code in the single .c file containing all the code related to this
issue.

typedef void (*ptr2func)(void);

Here is the function

void InsertTask(ptr2func TaskPtr)

Here is the call

InsertTask(LEDTask);

3. Here is the returned error.

../atm328.h:42: error: expected ')' before 'TaskPtr'

Before I try updating avr gcc, is there something else that I need to do in order
to make this work?

thanks.

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

From forum: AVR - gcc

passing pointers to functions

2009-11-07T12:07:40Z

I have been having difficulty passing a function pointer in a function call. In
researching the issue, it appears that there is a compiler issue with doing that &
I've tried a couple of suggested fixes with no luck.

Since the version appears to required in order to get the correct fix, my version
is gcc-4.3.0.

This is my last attempt.

1. Here is the function prototype in the .h file

void InsertTask(ptr2func TaskPtr); // line 42 in atm328.h

2. Here is the code in the single .c file containing all the code related to this
issue.

typedef void (*ptr2func)(void);

Here is the function

void InsertTask(ptr2func TaskPtr)

Here is the call

InsertTask(LEDTask);

3. Here is the returned error.

../atm328.h:42: error: expected ')' before 'TaskPtr'

Before I try updating avr gcc, is there something else that I need to do in order
to make this work?

thanks.

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

From forum: AVR - gcc

Re: [patch #6866] bug #26703: [Feature Request] Support device reset for 'arduino' programmer type

2009-11-06T18:26:02Z

On Nov 6, 2009, at 2:17 PM, Michael Dreher wrote:

> Follow-up Comment #11, patch #6866 (project avrdude):
> ...
> To compile this version, I had to make the following change, because sleep()
> is not available on the Win32 platform:
>
> Index: jtagmkII.c
> ===================================================================
> --- jtagmkII.c (revision 878)
> +++ jtagmkII.c (working copy)
> @@ -2847,7 +2847,7 @@
> status = jtagmkII_write_SABaddr(pgm, 0xffff0c00, 0x05, 0x0000004);
> if(status < 0) {lineno = __LINE__; goto eRR;} // Power Manager
> status = jtagmkII_write_SABaddr(pgm, 0xffff0c00, 0x05, 0x0000005);
> if(status < 0) {lineno = __LINE__; goto eRR;}
>
> - sleep(1);
> + usleep(1*1000);

If it still intended to be 1 second, shouldn't there be three more zeroes (1 million microseconds)?

Cheers,

--Dave

_______________________________________________
avrdude-dev mailing list
avrdude-dev@...
http://lists.nongnu.org/mailman/listinfo/avrdude-dev

From forum: AVR - AVRdude - Dev

RE: Re: [bug #22271] usb_reset in usb_libusb.c notnecessary in FreeBSD 6.x

2009-11-06T14:37:48Z

> -----Original Message-----
> From:
> avrdude-dev-bounces+eric.weddington=atmel.com@...
> [mailto:avrdude-dev-bounces+eric.weddington=atmel.com@...
> rg] On Behalf Of Joerg Wunsch
> Sent: Friday, November 06, 2009 3:10 PM
> To: avrdude-dev@...
> Subject: [avrdude-dev] Re: [bug #22271] usb_reset in
> usb_libusb.c notnecessary in FreeBSD 6.x
>
> Right now, the
> AVR opensource toolchain is proud to run on:
>
> . Win32
> . Linux
> . MacOS X
> . FreeBSD (probably also other *BSDs)
> . Solaris

IIRC, we've heard of it running on NetBSD.

_______________________________________________
avrdude-dev mailing list
avrdude-dev@...
http://lists.nongnu.org/mailman/listinfo/avrdude-dev

From forum: AVR - AVRdude - Dev

[patch #6866] bug #26703: [Feature Request] Support device reset for 'arduino' programmer type

2009-11-06T14:17:17Z

Follow-up Comment #11, patch #6866 (project avrdude):

Hi Michal,

I successfully tested svn revision 878 on Windows with the following
devices:
* Arduino-BT (with DIY auto-reset)
* Arduino Duemilanove with ATmega168
* Arduino Duemilanove with ATmega328

To compile this version, I had to make the following change, because sleep()
is not available on the Win32 platform:

Index: jtagmkII.c
===================================================================
--- jtagmkII.c (revision 878)
+++ jtagmkII.c (working copy)
@@ -2847,7 +2847,7 @@
status = jtagmkII_write_SABaddr(pgm, 0xffff0c00, 0x05, 0x0000004);
if(status < 0) {lineno = __LINE__; goto eRR;} // Power Manager
status = jtagmkII_write_SABaddr(pgm, 0xffff0c00, 0x05, 0x0000005);
if(status < 0) {lineno = __LINE__; goto eRR;}

- sleep(1);
+ usleep(1*1000);

val = jtagmkII_read_SABaddr(pgm, 0xfffe1408, 0x05); if(val != 0x0000a001)
{lineno = __LINE__; goto eRR;} // PLL 0

Michael

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/patch/?6866>

_______________________________________________
Nachricht geschickt von/durch Savannah
http://savannah.nongnu.org/

_______________________________________________
avrdude-dev mailing list
avrdude-dev@...
http://lists.nongnu.org/mailman/listinfo/avrdude-dev

From forum: AVR - AVRdude - Dev

Re: [bug #22271] usb_reset in usb_libusb.c not necessary in FreeBSD 6.x

2009-11-06T14:10:16Z

As David Hoerl wrote:

> PS: should avrdude migrate to the new usblib.1.0 someday?

Last time I've been looking at it, the platform support status of
libusb 1.x was lousy, only Linux was supported. Right now, the
AVR opensource toolchain is proud to run on:

. Win32
. Linux
. MacOS X
. FreeBSD (probably also other *BSDs)
. Solaris

to name those where I've got reports it is being in use. I wouldn't
want to break that.

--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL

http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

_______________________________________________
avrdude-dev mailing list
avrdude-dev@...
http://lists.nongnu.org/mailman/listinfo/avrdude-dev

From forum: AVR - AVRdude - Dev

Re: [bug #22271] usb_reset in usb_libusb.c not necessary in FreeBSD 6.x

2009-11-06T13:55:06Z

On 11/6/09 4:37 PM, David A. Mellis wrote:
>
> Follow-up Comment #5, bug #22271 (project avrdude):
>
> In my testing, the usb_reset() is necessary on Mac OS X (10.6 Snow Leopard).
> Otherwise, the upload process will stall for about 25 seconds on the second
> and subsequent attempts. I suggest that revision 873 be reverted.
>
>

David,

Well, I kind of agree. Once I made the change, I too then started seeing
more failures. But I also noticed that when it succeeds, its also a bit
slow.

As I posted the other day, what I ended up doing is installing
libusb.1.0, and libcompat.0.1. The current libusb.0.1 is quite old and
will itself never be updated. The combination of the new library and a
glue library fix a lot of issues (according to authors).

Even then, avrdude was running slowly. I actually spend a fair amount of
time putting in debugging command to find out why. It turned out its in
the two library calls to get busses and devices.

Well, it seems Apple suspends unused devices (like iSights), and the
current libusb.1.0 tries to wake them, get their info, and then put them
back to sleep. The code that does this was easily turned off, so I build
a special version of libusb-1.0, and now avrdude is running MUCH faster
than it ever did with the old libusb.0.1

My point in all this is that you can work with avrdude the way it is, do
the same things I did (take less than an hour), and have a much faster
and more reliable system.

That said, if you want it back, well, what I would then suggest is that
I add a new flag to avrdude that forces a usb reset - current systems
would get it, others could request it. This would then allows
FreeBSD/Mac people use either the new or the old library.

David

PS: should avrdude migrate to the new usblib.1.0 someday?

_______________________________________________
avrdude-dev mailing list
avrdude-dev@...
http://lists.nongnu.org/mailman/listinfo/avrdude-dev

From forum: AVR - AVRdude - Dev

[bug #22271] usb_reset in usb_libusb.c not necessary in FreeBSD 6.x

2009-11-06T13:37:19Z

Follow-up Comment #5, bug #22271 (project avrdude):

In my testing, the usb_reset() is necessary on Mac OS X (10.6 Snow Leopard).
Otherwise, the upload process will stall for about 25 seconds on the second
and subsequent attempts. I suggest that revision 873 be reverted.

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?22271>

_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/

_______________________________________________
avrdude-dev mailing list
avrdude-dev@...
http://lists.nongnu.org/mailman/listinfo/avrdude-dev

From forum: AVR - AVRdude - Dev

[patch #6951] Time posix patch.

2009-11-05T14:44:44Z

Follow-up Comment #6, patch #6951 (project avr-libc):

OK, I shall not hurry.

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/patch/?6951>

_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/

_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

From forum: AVR - Libc - Dev

FW: MPC version 0.8 released!

2009-11-05T09:28:31Z

Hi All,

This is a 'heads up' for all of you who work on the AVR GCC toolchain, please note in the email to the gcc mailing list below that MPC will very probably be required for building GCC 4.5 (current HEAD). This is another library similar to GMP and MPFR which are required for building GCC now.

I have tested building previous versions of MPC for a MinGW host and I have not run into any issues. Many other targets have been tested successfully as well, so there shouldn't be any problems in building this for your favourite platform.

Eric Weddington

> -----Original Message-----
> From: Kaveh R. GHAZI [mailto:ghazi@...]
> Sent: Thursday, November 05, 2009 8:54 AM
> To: gcc@...
> Subject: MPC version 0.8 released!
>
> MPC version 0.8 has been released:
> http://lists.gforge.inria.fr/pipermail/mpc-discuss/2009-Novemb
> er/000608.html
>
> You can download the tarball here:
> http://www.multiprecision.org/index.php?prog=mpc&page=download
>
> This release is for our purposes C99 feature-complete. After
> some wider
> portability testing, I will submit patches to make it
> mandatory for the
> GCC bootstrap process.
>
> Please test this version and report back in this thread (not to me
> privately) the results of "make check". Also include your
> target triplet,
> and the versions of your compiler, gmp and mpfr.
>
> Thanks,
> --Kaveh
>

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

From forum: AVR - gcc

RE: AVR atmega128 GCC 4.3.3 Testresults comparision

2009-11-05T08:04:57Z

> -----Original Message-----
> From: Paulo Marques [mailto:pmarques@...]
> Sent: Thursday, November 05, 2009 8:55 AM
> To: Weddington, Eric
> Cc: avr-gcc-list@...
> Subject: Re: [avr-gcc-list] AVR atmega128 GCC 4.3.3
> Testresults comparision
>
> Weddington, Eric wrote:
> >
> > Is there anyway that we could commit that feature into the
> repository?
>
> I already did :)
>

Oh, excellent! Sorry for my misunderstanding. :-)

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

From forum: AVR - gcc

Re: AVR atmega128 GCC 4.3.3 Testresults comparision

2009-11-05T07:55:28Z

Weddington, Eric wrote:

>
>
>> -----Original Message-----
>> From:
>> avr-gcc-list-bounces+eric.weddington=atmel.com@...
>> [mailto:avr-gcc-list-bounces+eric.weddington=atmel.com@nongnu.
>> org] On Behalf Of Paulo Marques
>> Sent: Thursday, November 05, 2009 8:24 AM
>> To: avr-gcc-list@...
>> Subject: Re: [avr-gcc-list] AVR atmega128 GCC 4.3.3
>> Testresults comparision
>>
>> Boyapati, Anitha wrote:
>>>> Try the files and simulator craeted as part of WINAVR
>>>>
>>>> http://winavr.cvs.sourceforge.net/viewvc/winavr/avrtest/
>>>>
>>>> Edit some paths to match your filespace.
>>> Thanks Andy. I think avrtest worked much better. I managed
>> to get 42K passes!
>>
>> BTW, I recently did an update on avrtest to include "cycle counters".
>> The wrappers to use them are in dejagnuboards/exit.c.
>>
>
> Very nice!
>
> Is there anyway that we could commit that feature into the repository?

I already did :)

Sorry for not making that part clear in the previous message :(

--
Paulo Marques
Software Development Department - Grupo PIE, S.A.
Phone: +351 252 290600, Fax: +351 252 290601
Web: www.grupopie.com

"I used to be indecisive, but now I'm not so sure."

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

From forum: AVR - gcc

RE: AVR atmega128 GCC 4.3.3 Testresults comparision

2009-11-05T07:34:38Z

Very nice!

Is there anyway that we could commit that feature into the repository?

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

From forum: AVR - gcc

Re: AVR atmega128 GCC 4.3.3 Testresults comparision

2009-11-05T07:24:28Z

Boyapati, Anitha wrote:
>
>> Try the files and simulator craeted as part of WINAVR
>>
>> http://winavr.cvs.sourceforge.net/viewvc/winavr/avrtest/
>>
>> Edit some paths to match your filespace.
>
> Thanks Andy. I think avrtest worked much better. I managed to get 42K passes!

BTW, I recently did an update on avrtest to include "cycle counters".
The wrappers to use them are in dejagnuboards/exit.c.

It allows you to write code like:

start_perf_counter(0);
...
start_perf_counter(1);
...do stuff...
stop_perf_counter(1);
...
start_perf_counter(2);
...do more stuff...
start_perf_counter(2);
...
stop_perf_counter(0);

The output would be something like:

counter 1: 1453 cycles
counter 2: 532 cycles
counter 0: 3274 cycles

So in a single run you can profile several functions and you have up to
256 counters to chose from.

Starting/stopping the counters consists of writing a single byte to a
port. This isn't exactly free, but if you use mostly counter 0, since
there is a __zero_reg__ always available, it will take a single cycle.
This cycle can be subtracted later to find the exact number of cycles
between start/stop.

Happy benchmarking,

--
Paulo Marques
Software Development Department - Grupo PIE, S.A.
Phone: +351 252 290600, Fax: +351 252 290601
Web: www.grupopie.com

"As far as we know, our computer has never had an undetected error."
Weisert

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

From forum: AVR - gcc

[patch #6951] Time posix patch.

2009-11-04T15:41:51Z

Follow-up Comment #5, patch #6951 (project avr-libc):

Hi Dmitry,

We cannot commit this code until we verify that the licenses for these
specific modules match the license of avr-libc.

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/patch/?6951>

_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/

_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

From forum: AVR - Libc - Dev

[patch #6951] Time posix patch.

2009-11-04T14:42:44Z

Update of patch #6951 (project avr-libc):

Status: None => In Progress
Assigned to: None => dmix

_______________________________________________________

Follow-up Comment #4:

After a few obvious changes (merge day/month names in one
string, replace macroses to normal functions) the size is reduced
(without called library functions):
asctime(): 104 --> 69 words
gmtime(): 339 --> 280 words
mktime(): 632 --> 461 words
(Note, the sprintf() usage in asctime() is doubtful.)
In progress...

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/patch/?6951>

_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/

_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

From forum: AVR - Libc - Dev

avrdude using libusb-1.0 and libusb-compat-0.1

2009-11-04T14:24:16Z

Sending this for the archives - had good luck getting libusb-1.0.3 and
the compatibility library (which maps the new library calls into what
avrdude expects from libusb.0.1). Its seems faster when downloading but
didn't really measure it.

For OSX Mac users, a note: if you use a portable, as I do, both old and
new libusb libraries try to get info out of suspended USB devices like
the camera. This adds many seconds of delay before the download starts.
I edited the darwin_usb.c file in libusb.1.0, and essentially commented
out code. This resulted in a much much faster download.

David

if (ret != kIOReturnSuccess) {
int try_unsuspend = 0; // DFH - was 1
#if DeviceVersion >= 3200 // DFH - was 320

_______________________________________________
avrdude-dev mailing list
avrdude-dev@...
http://lists.nongnu.org/mailman/listinfo/avrdude-dev

From forum: AVR - AVRdude - Dev

Re: Re: optimizer removes volatile pin access code. why?

2009-11-03T10:29:20Z

Joerg Desch wrote:

> On Tue, 27 Oct 2009 20:17:46 +0100 (MET)
> j@... (Joerg Wunsch) wrote:
> [...]
>> However, the
>> optimized code will just toggle the pin for a single CPU cycles only,
>> while the pin will stay a little longer at high in the non-optimized
>> example. So if your oscilloscope is too slow, you might not notice
>> the pin actually becoming high for one clock period.
>
> Tektroniks TDS784 with 4GS/s ;-)

If the pin is set to input, toggling the port might be just turning on
the internal pull-up. This will change the output from 0 to 1, but at
the rate of charging the pin capacitance through the internal pull-up.

If the pulse lasts longer, you might be able to see it, but if it is too
short, it might not have enough time to charge the pin up to your
trigger level.

Just a thought,

--
Paulo Marques
Software Development Department - Grupo PIE, S.A.
Phone: +351 252 290600, Fax: +351 252 290601
Web: www.grupopie.com

"Reality continues to ruin my life." - Calvin.

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

From forum: AVR - gcc

[patch #6866] bug #26703: [Feature Request] Support device reset for 'arduino' programmer type

2009-11-02T15:58:53Z

Update of patch #6866 (project avrdude):

Status: Ready For Test => Done

_______________________________________________________

Follow-up Comment #10:

Hi Michael,

your last patch is in SVN now. Works for me with Duemilanove on Linux. Hope
it won't break things for other arduino users.

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/patch/?6866>

_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/

_______________________________________________
avrdude-dev mailing list
avrdude-dev@...
http://lists.nongnu.org/mailman/listinfo/avrdude-dev

From forum: AVR - AVRdude - Dev

RE: Re: optimizer removes volatile pin access code.why?

2009-11-02T08:19:32Z

> -----Original Message-----
> From: Joerg Wunsch [mailto:j@...]
> Sent: Monday, November 02, 2009 8:57 AM
> To: avr-gcc-list@...
> Cc: Weddington, Eric
> Subject: Re: [avr-gcc-list] Re: optimizer removes volatile
> pin access code.why?
>
> As Weddington, Eric wrote:
>
> > To be a bit more specific (now that I've had a bit more caffiene):
> > Adding a feature (a warning) is always easier than trying to change
> > the semantics of an existing feature (always_inline).
>
> That's why I also liked the idea of just adding a warning.
>
> The only remaining potential for a debate would be whether this
> warning should always be enabled (I think so, because it's a usage
> error, according to the description of the always_inline attribute),
> or made optional. In the latter, another -Wxxx option would be
> needed, and I guess it takes also some energy to convince everybody to
> at least include it into -Wall then.

Agreed.

> > Changing
> > semantics seems to incur a bit more debate and risks earlier
> > rejection. But I agree that it's not impossible.
>
> I don't know whether I'm motivated for that though. ;-)

LOL! Don't look at me! I've got enough on my plate. ;-) Perhaps some users will get motivated enough to become developers....

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

From forum: AVR - gcc

Re: Re: optimizer removes volatile pin access code.why?

2009-11-02T07:57:02Z

As Weddington, Eric wrote:

> To be a bit more specific (now that I've had a bit more caffiene):
> Adding a feature (a warning) is always easier than trying to change
> the semantics of an existing feature (always_inline).

That's why I also liked the idea of just adding a warning.

The only remaining potential for a debate would be whether this
warning should always be enabled (I think so, because it's a usage
error, according to the description of the always_inline attribute),
or made optional. In the latter, another -Wxxx option would be
needed, and I guess it takes also some energy to convince everybody to
at least include it into -Wall then.

> Changing
> semantics seems to incur a bit more debate and risks earlier
> rejection. But I agree that it's not impossible.

I don't know whether I'm motivated for that though. ;-)

--
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@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

From forum: AVR - gcc

RE: Re: optimizer removes volatile pin access code.why?

2009-11-02T07:45:41Z

> -----Original Message-----
> From:
> avr-gcc-list-bounces+eric.weddington=atmel.com@...
> [mailto:avr-gcc-list-bounces+eric.weddington=atmel.com@nongnu.
> org] On Behalf Of Weddington, Eric
> Sent: Monday, November 02, 2009 8:33 AM
> To: Joerg Wunsch; avr-gcc-list@...
> Subject: RE: [avr-gcc-list] Re: optimizer removes volatile
> pin access code.why?
>
>
>
> > -----Original Message-----
> > From: Joerg Wunsch [mailto:j@...]
> > Sent: Monday, November 02, 2009 8:17 AM
> > To: avr-gcc-list@...
> > Cc: Weddington, Eric
> > Subject: Re: [avr-gcc-list] Re: optimizer removes volatile
> > pin access code.why?
> >
> > As Weddington, Eric wrote:
> >
> > > And IMHO, I highly doubt that this proposal will be approved. They
> > > will probably just come back to you and say that there's
> no need for
> > > it.
> >
> > Why not? Why do you think issuing a warning for something that is
> > known it cannot work would be rejected? If the always_inline
> > attribute is known to only work for a function declared inline, it
> > should be legitimate to warn the user about a situation where this
> > prerequisite is not met.
>
> Ok, *that* proposal I can understand (warning if inline not
> present). But I think that changing 'always_inline' attribute
> to imply inline might not fly. But who knows? In the end I
> think you're right in that it would be an effort to get it
> through the commit process.

To be a bit more specific (now that I've had a bit more caffiene): Adding a feature (a warning) is always easier than trying to change the semantics of an existing feature (always_inline). Changing semantics seems to incur a bit more debate and risks earlier rejection. But I agree that it's not impossible.

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

From forum: AVR - gcc

RE: Re: optimizer removes volatile pin access code.why?

2009-11-02T07:33:17Z

> -----Original Message-----
> From: Joerg Wunsch [mailto:j@...]
> Sent: Monday, November 02, 2009 8:17 AM
> To: avr-gcc-list@...
> Cc: Weddington, Eric
> Subject: Re: [avr-gcc-list] Re: optimizer removes volatile
> pin access code.why?
>
> As Weddington, Eric wrote:
>
> > And IMHO, I highly doubt that this proposal will be approved. They
> > will probably just come back to you and say that there's no need for
> > it.
>
> Why not? Why do you think issuing a warning for something that is
> known it cannot work would be rejected? If the always_inline
> attribute is known to only work for a function declared inline, it
> should be legitimate to warn the user about a situation where this
> prerequisite is not met.

Ok, *that* proposal I can understand (warning if inline not present). But I think that changing 'always_inline' attribute to imply inline might not fly. But who knows? In the end I think you're right in that it would be an effort to get it through the commit process.

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

From forum: AVR - gcc

Re: Re: optimizer removes volatile pin access code.why?

2009-11-02T07:16:45Z

As Weddington, Eric wrote:

> And IMHO, I highly doubt that this proposal will be approved. They
> will probably just come back to you and say that there's no need for
> it.

Why not? Why do you think issuing a warning for something that is
known it cannot work would be rejected? If the always_inline
attribute is known to only work for a function declared inline, it
should be legitimate to warn the user about a situation where this
prerequisite is not met.

--
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@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

From forum: AVR - gcc

RE: Re: optimizer removes volatile pin access code.why?

2009-11-02T07:05:08Z

> -----Original Message-----
> From:
> avr-gcc-list-bounces+eric.weddington=atmel.com@...
> [mailto:avr-gcc-list-bounces+eric.weddington=atmel.com@nongnu.
> org] On Behalf Of Joerg Wunsch
> Sent: Monday, November 02, 2009 2:57 AM
> To: avr-gcc-list@...
> Subject: Re: [avr-gcc-list] Re: optimizer removes volatile
> pin access code.why?
>
> In article <hcm55m$shn$1@...> you write:
>
> >As far as I have seen, the compiler has been working exactly as it
> >says in the manual (quoted above).
>
> Yes, you're right.
>
> >Alternatively, should we ask for __attribute__((always_inline)) to
> >imply inline, or give a warning if it is used for a non-inline
> >function?
>
> I'd prefer the latter, although I guess a bug report will stay forever
> unless someone is willing to also file a patch. Even then, it
> requires a bit of stamina to really get the patch through all the
> mailing lists, until someone finally gives his OK for the integration.
> Been there, done that (with the 0b binary constant patch).

And IMHO, I highly doubt that this proposal will be approved. They will probably just come back to you and say that there's no need for it.

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

From forum: AVR - gcc

RE: [patch #6951] Time posix patch.

2009-11-02T07:03:41Z

> -----Original Message-----
> From: Daniele Basile [mailto:INVALID.NOREPLY@...]
> Sent: Monday, November 02, 2009 2:51 AM
> To: joerg_wunsch@...; Daniele Basile;
> Weddington, Eric; avr-libc-dev@...
> Subject: [patch #6951] Time posix patch.
>
>
> Follow-up Comment #3, patch #6951 (project avr-libc):
>
> there are some updates on mine time.h posix patch proposal?

You will know when there are updates on your proposal, because we'll either make comments on the patch tracker item, or we will commit it and close the patch tracker. Right now I think all of the developers are busy with other things at the moment.

_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

From forum: AVR - Libc - Dev

Re: Re: optimizer removes volatile pin access code.why?

2009-11-02T01:56:40Z

In article <hcm55m$shn$1@...> you write:

>As far as I have seen, the compiler has been working exactly as it
>says in the manual (quoted above).

Yes, you're right.

>Alternatively, should we ask for __attribute__((always_inline)) to
>imply inline, or give a warning if it is used for a non-inline
>function?

I'd prefer the latter, although I guess a bug report will stay forever
unless someone is willing to also file a patch. Even then, it
requires a bit of stamina to really get the patch through all the
mailing lists, until someone finally gives his OK for the integration.
Been there, done that (with the 0b binary constant patch).
--
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@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

From forum: AVR - gcc

[patch #6951] Time posix patch.

2009-11-02T01:51:10Z

Follow-up Comment #3, patch #6951 (project avr-libc):

there are some updates on mine time.h posix patch proposal?

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/patch/?6951>

_______________________________________________
Messaggio inviato con/da Savannah
http://savannah.nongnu.org/

_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

From forum: AVR - Libc - Dev

Re: optimizer removes volatile pin access code.why?

2009-11-02T00:29:22Z

Weddington, Eric wrote:

>
>
>> -----Original Message----- From:
>> avr-gcc-list-bounces+eric.weddington=atmel.com@...
>> [mailto:avr-gcc-list-bounces+eric.weddington=atmel.com@nongnu. org]
>> On Behalf Of Joerg Wunsch Sent: Sunday, November 01, 2009 11:25 PM
>> To: avr-gcc-list@... Subject: Re: [avr-gcc-list] Re:
>> optimizer removes volatile pin access code.why?
>>
>> David Brown <david@...> wrote:
>>
>>> It might be worth filing a report for a better clarification in
>>> the documentation (does that need a bug report?) to make it
>>> clearer that "always_inline" has no effect without a normal
>>> "inline" declaration.
>
> This is what the GCC 4.3.2 manual says:
>
> always_inline Generally, functions are not inlined unless
> optimization is specified. For functions declared inline, this
> attribute inlines the function even if no optimization level was
> specified.
>
> So it does say "for functions declared inline". With this
> description, the "always_inline" attribute is really affecting how
> the optimization works, not how inlining works per se, i.e. one still
> has to mark the function as "inline" for inlining to happen. The
> always_inline attribute tells the optimizer to inline even at -O0,
> which apparently is not the default behaviour.

As far as I have seen, the compiler has been working exactly as it says
in the manual (quoted above). If anyone can post a code snippet and
compiler flags that contradict that, then please do so!

Would it be reasonable to ask for a change in the documentation, since
several people have been caught out by it? Alternatively, should we ask
for __attribute__((always_inline)) to imply inline, or give a warning if
it is used for a non-inline function? I certainly can't think of any
situation where you would want always_inline but not normal inline.

mvh.,

David

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

From forum: AVR - gcc