AVRFreaks.net

why the F_CPU frequency divide by 4 on the code.

Do you have a 6Mhz crystal attached? How are you getting a 6Mhz clock? If you do have the crystal did you program the fuses in the Tiny85 to use an external crystal?

Im using external clock. it is 6 MHZ

why the F_CPU frequency divide by 4 on the code.

It's not "dividing the frequency", it's calculating a number of cycles to iterate to generate a requested delay. The fact that you spotted a 4 in there, and your results are of by a factor of 4 is pure coincidence.

How are they currently configured ? What programmer and software are you using ?

Aren't you getting a compilation error or at least a warning on that ?
What you probably wanted there is
notice no equals sign and no semicolon.

But when using AVRStudio, don't (re-)define it in a source file, but enter it in the "Project Options" under "Frequency", that way it will be passed as a commandline-switch on compilation of every file.
I believe you will get a warning if you redefine it in a source file.

i want to try

but i have one question in my mind , which toolchain is more power-full?

which toolchain is more power-full?

Curious, is this an avr-libc bug? I haven't seen a bug report for it...

> You do know, don't you, that "AVR Toolchain" rather than "WinAVR" has
> a SERIOUS bug in its delay.h ?

Curious, is this an avr-libc bug? I haven't seen a bug report for it...
It's been me who introduced the original support for __builtin_avr_delay_cycles
(that's why I'm asking . The idea is that using this function, the compiler
knows the exact effort it costs to setup the delay.

So sorry, Cliff, don't blame the guys at Atmel about the bug, it's been me
who introduced it

Some sort of answer to that is here: http://www.avrfreaks.net/index.php?name ... mp;t=44588

User can define __DELAY_BACKWARD_COMPATIBLE__ to get a backward compatible delay
although this will be deprecated in future.

>It's been me who introduced the original support for __builtin_avr_delay_cycles.

If the avr-gcc toolchain has __builtin_avr_delay_cycles(unsigned long) support, maximal possible delay is 4294967.295 us/ F_CPU in MHz.

WinAVR-20100110

That does not have __builtin_avr_delay_cycles().

You know you've got it if the AVR-LibC that accompanies the compiler has this at the top of its delay.h:

That does not have __builtin_avr_delay_cycles().

You know you've got it if the AVR-LibC that accompanies the compiler has this at the top of its delay.h:

Let's clarify this: WinAVR 20100110 has the __builtin_avr_delay_cycles() function available. However, <util/delay.h> does not use this builtin for the 20100110 version of WinAVR.

Just for the record:

avr-gcc has built-in macros to query for availability of built-in functions:
6.54.4 AVR Built-in Functions
This applies to avr-gcc from FSF repo, I cannot say how other avr-gcc distribution allow to identify these features.

In the case of the AVR version, as I recall some of the AVR built-ins didn't create the corresponding define and hence didn't have any way of being detected by the preprocessor. And that was the problem.

The real solution would be to fix gcc at a higher level to always create the define when a built in function was created. That way, every version of gcc could automagically benefit from it rather than depending on each version of gcc to do it.

IMO the easiest for avr-libc is to query the "official" macros, and for each private port that adds built-ins by patch to add built-in defines following the same nomenclature.



NACK. Most things there are historical, one port might define a macro or not, an other port might define it to 0 or 1, a third port might define it to the built-in function's name.

Ports like rs6000 (aka. PowerPC) have ~1000 built-ins, some private ports even 50% more. I makes more sense to group the built-ins and supply one macro for a group, e.g. if built-ins just map to machine instructions that are only available on specific derivatives/HW extensions.

I was specifically referring to built in compiler functions that traditionally have __builtin prefixes.

The problem with leaving it up to developers to create a corresponding macro is that as we have seen it sometimes does not get done.
i.e. in the AVR version when __builtin_avr_delay_cyclcles() showed up there was no corresponding c preprocessor define. This made it impossible to have common code in a libc header that automatically adjusted itself depending on the compilers capabilities.

It works the other way round: If the macro is not there (__BUILTIN_AVR_DELAY_CYCLES) then the built-in function is not present. The converse is not necessarily true and you might miss some occasion where the built-in is actually there. But it's save.

Currently, if you have a __BUILTIN* macro define, you know the builtin function exists. However, if you don't have it, you know nothing because the built in function might or might not exist.

The problem is that a builtin function can exist and there is no way to detect its existence to allow a library to deal with different versions of the compiler.

To me that is a very real problem because it depends on the compiler developers to properly insert/create macros when creating new builtin functions.

And while it technically not a compiler bug, it does potentially make it very difficult if not impossible for library writers to write code that can automatically maintain backward compatibility yet take advantage of newer compiler capabilities.

That is why (IMHO) it is better to have the macros created automagically by the compiler.