New Linux toolchain w. avr-libc-1.7.0

Go To Last Post
62 posts / 0 new

Pages

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bperrybap wrote:

I'll add this additional comment to the Savannah bug report - Which, so far, seems to be ignored.

It is not being ignored. It is just not being acted on yet.

Eric [avr-libc admin]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

EW wrote:
bperrybap wrote:

I'll add this additional comment to the Savannah bug report - Which, so far, seems to be ignored.

It is not being ignored. It is just not being acted on yet.

Eric [avr-libc admin]

I totally agree that at this point in time, it is not being ignored. Perhaps "ignored" was too strong of a comment.
It had the appearance of being ignored because it sat in the savannah buglist Q for about 2 weeks before being acknowledged in any way.

In the larger picture my main concern is for the original _delay_xx() issue (not the backward compatibility issue).
The main issue is that for anybody using the _delay_xx() functions, their code will break (or at least not function as expected) with the 1.7.0 release because the delay cycle calculation for the built in delay cycle routine is incorrect.

To me this seems like an issue that should be fixed fairly soon before the 1.7.0 release ends up being distributed around very much.

--- bill

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I did an installation following the instructions on the avr-libc site

http://avr-libc.nongnu.org/user-manual/install_tools.html#install_avr_gcc

Did not see any problems. Just did the patching manually.

I did not do anything with builtin.h included in Bingos package.

Wrote a little test program for _delay_*

Here it is

/*
 *   To test delay.
 *
 *
 *      Device: ATtiny45
 *    Compiler: avr-gcc 4.3.2
 *    Library : avr-libc 1.7.0
 */

#include 
#define F_CPU 1000000UL
#include 

int
main (void)
{
  DDRB = _BV(DDB1);

  for (;;)
    {
      PORTB ^= _BV(PB1);

      _delay_us(100);

    }
  return (0);
}

What I was expecting was a period of 200uS.
What I got was a period of 74uS.

The chip has default fuse settings.

Would someone be as good as to tell me what I should have done with builtin.h ?

Having done something with builtin.h how would I modify my test program ?

John

If all else fails, read the instructions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohnWalton wrote:

What I was expecting was a period of 200uS.
What I got was a period of 74uS.

John

Yep, exactly what I would have expected with this latest release.
Which is why I think this needs to be fixed fairly quickly.

The new code miscalculates the number of delay cycles for the __builtin_avr_delay_cycles() function.
The new code is using a calculation from the old code that is calculating the number of basic delay loops interations vs cycles. Each delay loop interation for _delay_us() is 3 cycles and each delay loop iteration for _delay_ms() is 4 cycles. So the number of cycles being requested for the 1.7.0 delay code is 3 times smaller/shorter than what is requested for microsecond delays and 4 times too short for millisecond delays.

As an ugly hack you could add this to your code:

#define  __HAS_DELAY_CYCLES 0

Just before your include of

However, depending on how this eventually gets fixed, this may not work in the future or create a warning in the future.

So using it at a command line option define to the compiler would be better.

All that said, this is still an ugly hack that simply reverts the delay code back to the pre 1.7.0 code which also has calculation rounding issues which is why I abandoned using it about a year ago and have been complaining about it ever since.

If you want to patch your file,
you can read my savannah bug report which proposes a fix.
It is an attached file to the original bug report and you can grab the ifdef code in the _delay_ms() and _delay_us() routines to fix your local copy.
https://savannah.nongnu.org/bugs/?30363

Or you could switch over to a fully backward compatible version of delay code that
- preserves the very same API
- adds some additional/new functions
- does not depend on any builtin delay cycles code
- sometimes generates better/smaller code than the new __builtin_avr_delay_cycles() code.
- does not have the rounding error issues of the pre 1.7.0 code
rounding error is worst at the short end and varies depending on CPU frequency and requested delay. As an example of the rounding error. At your CPU frequency of 1mhz, if you ask for a 1us, 2us, or 3us delay, you will get a 3us delay even though 1us and 2us are possible at the 1mhz CPU frequency.

More importantly the alternative mentioned above works today and is easy to use as it is a drop in replacement for

Here is the link to the project if you want to go this route (which is what I'd recommend until this delay stuff finally gets resolved).
https://www.avrfreaks.net/index.php?module=Freaks%20Academy&func=viewItem&item_id=665&item_type=project
To use it, simply include the delay_x.h header file instead of

--- bill

Last Edited: Wed. Jul 21, 2010 - 06:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bperrybap wrote:

I totally agree that at this point in time, it is not being ignored. Perhaps "ignored" was too strong of a comment.
It had the appearance of being ignored because it sat in the savannah buglist Q for about 2 weeks before being acknowledged in any way.

And my apologies on that. One of our main developers was away at that time (IIRC). I wanted to make sure that he saw it before we started discussing a solution for this. Also, I always have a lot on my plate so I'm not always as responsive as I would like to be. Please feel free to send me an email directly in the future to ping me on any subject matter.

bperrybap wrote:

To me this seems like an issue that should be fixed fairly soon before the 1.7.0 release ends up being distributed around very much.

Agreed, though that may end up adding a bit more delay in the release process (pun not intended, though admittedly funny).

I would categorize this as a regression, so we really need to get this fixed and do a 1.7.1 release.

But from here on out, the details of this issue needs to be discussed on the avr-libc-dev mailing list, where it's more appropriate.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohnWalton wrote:

      _delay_us(100);

What I was expecting was a period of 200uS.

John

I am a bit puzzled. Why should 200uS be expected when 100uS has been requested?

Going by the old code _delay_loop_1() receives 33 cycles as __count value, which should probably give 100 cycles of delay. (approximate calculations)

__tmp = ((1MHz) / 3e6) * 100uS
__tmp = 33 (appx)

  dec  , 1   // 1 clock cycle,  has 33 initially
  brne 1b         // 2 clock cycles if branch taken 

or is it because of different F_CPU value?

-- Anitha

Anitha

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The reason he expects a PERIOD of 200us is because it takes TWO iterations of the loop to produce a square wave:

+-----+     +
|     |     |
|     |     |
|     |     |
+     +-----+
  100   100

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
The reason he expects a PERIOD of 200us is because it takes TWO iterations of the loop to produce a square wave:

+-----+     +
|     |     |
|     |     |
|     |     |
+     +-----+
  100   100

Thanks Clawson. I was thinking along the same lines when I re-read the 'period' part of it.

Anitha

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bperrybap wrote:
I'm assuming that this 1.7.0 code has the new "improved" _delay_xx() routines in which no longer work properly?
(Code incorrectly calls __builtin_delay_cycles() with incorrect argument)

Ouch, I just run into the same issue and it took me some while to find the problem.

EDIT: So where can I find the script to build the recommended, working toolchain for use with a XMega128A1? Or should I just copy over the 2 old delay*.h files?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

salixer wrote:

EDIT: So where can I find the script to build the recommended, working toolchain for use with a XMega128A1? Or should I just copy over the 2 old delay*.h files?

You have build the latest toolchain , and the latest avr-libc
AFAIK the problem lies within avr-libc , and you will have to wait for a new release.

Quote:
If you want to patch your file,
you can read my savannah bug report which proposes a fix.
It is an attached file to the original bug report and you can grab the ifdef code in the _delay_ms() and _delay_us() routines to fix your local copy.

Perry has submitted this fix (as described in the above quote)
https://savannah.nongnu.org/bugs...

Else you can use this delay header , witch should be quite nice perry's notes below on this header file.

Quote:
Or you could switch over to a fully backward compatible version of delay code that
- preserves the very same API
- adds some additional/new functions
- does not depend on any builtin delay cycles code
- sometimes generates better/smaller code than the new __builtin_avr_delay_cycles() code.
- does not have the rounding error issues of the pre 1.7.0 code
rounding error is worst at the short end and varies depending on CPU frequency and requested delay. As an example of the rounding error. At your CPU frequency of 1mhz, if you ask for a 1us, 2us, or 3us delay, you will get a 3us delay even though 1us and 2us are possible at the 1mhz CPU frequency.

More importantly the alternative mentioned above works today and is easy to use as it is a drop in replacement for

Here is the link to the project if you want to go this route (which is what I'd recommend until this delay stuff finally gets resolved).
https://www.avrfreaks.net/index.p...
To use it, simply include the delay_x.h header file instead of

https://www.avrfreaks.net/index.p...

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

See topmost post , or below
https://www.avrfreaks.net/index.p...
For fixing the delay bug in avr-libc-1.7.0

/Bingo

Pages