AVR-Chat

Hi there,
Looking at the delay functions, I see that:	void _delay_us 
          (
          double 
           __us )has a maximal possible delay is 768 us / F_CPU in MHz.
But:If the avr-gcc toolchain has __builtin_avr_delay_cycles(unsigned long) 
support, maximal possible delay is 4294967.295 us/ F_CPU in MHz.
How do I know if the avr-gcc toolchain has __builtin_avr_delay_cycles(unsigned long) support?
Thanks,
Cat

 		 	   		  

[Non-text portions of this message have been removed]

On Jul 4, 2011, at 2:55 PM, Cat C wrote:

> Hi there,
> Looking at the delay functions, I see that:	void _delay_us 
>          (
>          double 
>           __us )has a maximal possible delay is 768 us / F_CPU in MHz.
> But:If the avr-gcc toolchain has __builtin_avr_delay_cycles(unsigned long) 
> support, maximal possible delay is 4294967.295 us/ F_CPU in MHz.
> How do I know if the avr-gcc toolchain has __builtin_avr_delay_cycles(unsigned long) support?
> Thanks,
> Cat


"Use the source (sic) Luke".

Consult the avr-libc sources. I don't remember how much is shipped with WinAVR, or how much is shipped with AVR Studio 5.0. It doesn't really matter else I would go look because even if you go looking at the original source you need to build a test case and select "generate a disassembly listing" and have a look at exactly what code was generated. Else the original library sources you are looking at may not be the ones used for your CPU.

Burning CPU cycles in empty loops is usually a very amateurish and inaccurate means to an end.

--
David Kelly N4HHE, dkelly@HiWAAY.net
========================================================================
Whom computers would destroy, they must first drive mad.

Thanks David,
You'd think there should be a way to tell, if it's mentioned in the documentation like that...
Regarding empty loops... we're not all as professional as you are :-)
Cat

> To: AVR-Chat@yahoogroups.com
> From: dkelly@hiwaay.net
> Date: Mon, 4 Jul 2011 17:05:09 -0500
> Subject: Re: [AVR-Chat] Delay functions and "__builtin_avr_delay_cycles".
> 
> 
> On Jul 4, 2011, at 2:55 PM, Cat C wrote:
> 
> > Hi there,
> > Looking at the delay functions, I see that:	void _delay_us 
> >          (
> >          double 
> >           __us )has a maximal possible delay is 768 us / F_CPU in MHz.
> > But:If the avr-gcc toolchain has __builtin_avr_delay_cycles(unsigned long) 
> > support, maximal possible delay is 4294967.295 us/ F_CPU in MHz.
> > How do I know if the avr-gcc toolchain has __builtin_avr_delay_cycles(unsigned long) support?
> > Thanks,
> > Cat
> 
> 
> "Use the source (sic) Luke".
> 
> Consult the avr-libc sources. I don't remember how much is shipped with WinAVR, or how much is shipped with AVR Studio 5.0. It doesn't really matter else I would go look because even if you go looking at the original source you need to build a test case and select "generate a disassembly listing" and have a look at exactly what code was generated. Else the original library sources you are looking at may not be the ones used for your CPU.
> 
> Burning CPU cycles in empty loops is usually a very amateurish and inaccurate means to an end.
> 
> --
> David Kelly N4HHE, dkelly@HiWAAY.net
> ========================================================================
> Whom computers would destroy, they must first drive mad.
> 

 		 	   		  

[Non-text portions of this message have been removed]

Hi Cat,

On Mon, Jul 4, 2011 at 12:55 PM, Cat C <catalin_cluj@hotmail.com> wrote:
>
> Hi there,
> Looking at the delay functions, I see that:     void _delay_us
>          (
>          double
>           __us )has a maximal possible delay is 768 us / F_CPU in MHz.
> But:If the avr-gcc toolchain has __builtin_avr_delay_cycles(unsigned long)
> support, maximal possible delay is 4294967.295 us/ F_CPU in MHz.
> How do I know if the avr-gcc toolchain has __builtin_avr_delay_cycles(unsigned long) support?

I think that as long as you don't disable it on the command line, then
the builtin support will be there. You can disable builtin functions
using -fno-builtin  or disable particular builtin functions using
-fno-builtin-function (replace function with the name of the
function).

-- 
Dave Hylands
Shuswap, BC, Canada
http://www.davehylands.com

I agree with David ... don't use "built-in delay codes" ... roll your own if absolutely required.

Software timing loops are not a good idea but sometimes the only way to make something work. It is easy to get in to trouble ... been there done that. I use them but very carefully when there is no other way.

Suggest you write an assembly language routine - not C - to do your own timing method. Use it within your C program so that it will always stays the same. This way you will have consistent timing. If the code that the compiler generates changes due to an compiler upgrade or whatever your C timing routine is in trouble and no longer doing what you think it is. Just try and find that problem.

Be sure interrupts are disabled during software timing efforts as interrupts cause your timing routine to generate much longer times than called for. I know ... not always possible but one must be careful.

And at times, a string of NOPs or a routine with NOPs can work for small delays.

Jim

  ----- Original Message ----- 
  From: Cat C 
  To: avr-chat@yahoogroups.com 
  Sent: Monday, July 04, 2011 4:20 PM
  Subject: RE: [AVR-Chat] Delay functions and "__builtin_avr_delay_cycles".


    

  Thanks David,
  You'd think there should be a way to tell, if it's mentioned in the documentation like that...
  Regarding empty loops... we're not all as professional as you are :-)
  Cat

  > To: AVR-Chat@yahoogroups.com
  > From: dkelly@hiwaay.net
  > Date: Mon, 4 Jul 2011 17:05:09 -0500
  > Subject: Re: [AVR-Chat] Delay functions and "__builtin_avr_delay_cycles".
  > 
  > 
  > On Jul 4, 2011, at 2:55 PM, Cat C wrote:
  > 
  > > Hi there,
  > > Looking at the delay functions, I see that: void _delay_us 
  > > (
  > > double 
  > > __us )has a maximal possible delay is 768 us / F_CPU in MHz.
  > > But:If the avr-gcc toolchain has __builtin_avr_delay_cycles(unsigned long) 
  > > support, maximal possible delay is 4294967.295 us/ F_CPU in MHz.
  > > How do I know if the avr-gcc toolchain has __builtin_avr_delay_cycles(unsigned long) support?
  > > Thanks,
  > > Cat
  > 
  > 
  > "Use the source (sic) Luke".
  > 
  > Consult the avr-libc sources. I don't remember how much is shipped with WinAVR, or how much is shipped with AVR Studio 5.0. It doesn't really matter else I would go look because even if you go looking at the original source you need to build a test case and select "generate a disassembly listing" and have a look at exactly what code was generated. Else the original library sources you are looking at may not be the ones used for your CPU.
  > 
  > Burning CPU cycles in empty loops is usually a very amateurish and inaccurate means to an end.
  > 
  > --
  > David Kelly N4HHE, dkelly@HiWAAY.net
  > ========================================================================
  > Whom computers would destroy, they must first drive mad.
  > 



  [Non-text portions of this message have been removed]



  

[Non-text portions of this message have been removed]

On Jul 4, 2011, at 7:36 PM, Jim Hatley wrote:

> I agree with David ... don't use "built-in delay codes" ... roll your own if absolutely required.
> 
> Software timing loops are not a good idea but sometimes the only way to make something work. It is easy to get in to trouble ... been there done that. I use them but very carefully when there is no other way.

Yes, as I said it is *usually* amateurish and/or inaccurate. I don't fault avr-libc for having calibrated delay loops. Have used them in my own code temporarily, but never shipped code. Can be handy for creating a high CPU load condition to see how other parts of one's code runs. Also handy for altering the order events are processed when one suspects some things are happening at the same time and not being handled correctly.

The calibrated delay loops in the library also serve as examples that one may expand on for other purposes.

One key thing to learn to be a good embedded programmer is to not trust any canned libraries, or even the built-in intrinsics of the compiler. Its this lack of trust which forms the basis for many's dislike/distrust of C++.

"Distrust" doesn't mean "don't use". It means "verify." I always include a disassembly listing in my avr-gcc builds. Spend a fair bit of time looking at the generated code before deciding it is acceptable or not. Often make changes in the C so as to simplify the generated assembly.


Come to think of it, "Never say never because never is never true." I did ship code once with calibrated delay loops. Used a PIC16C505 which doesn't have interrupts or timers. Or UART. And I needed to send an asynchronous serial bit stream. That one little chip replaced an entire PC from someone else's design.

--
David Kelly N4HHE, dkelly@HiWAAY.net
========================================================================
Whom computers would destroy, they must first drive mad.

Thank you all for input,There is sooth in what you all say and I tend to agree.
However, where does it stop?If it takes longer to write something because I don't trust any libraries I waste time writing my own.
If I trust them, I may need to spend time fixing IF they break (and I know that's likely at some point).
I've done just NOP loops sometimes but it's not as nice as being able to specify number of microseconds directly.
I'm using my timers for other things and I don't want to add ifs when triggered either in or outside ISRs.
I found that the compiler does support "__builtin_avr_delay_cycles" but the 20100110 delay.h doesn't use it; there is a new delay.h that uses it here:
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=100131&postdays=0&postorder=asc&sid=ea59a79d21c3eae4542bb467153721df
I think some faith can work sometime :-)
Thanks again,
Cat 		 	   		  

[Non-text portions of this message have been removed]

>
> Thank you all for input,There is sooth in what you all say and I tend to
> agree.
> However, where does it stop?If it takes longer to write something because
> I don't trust any libraries I waste time writing my own.
> If I trust them, I may need to spend time fixing IF they break (and I know
> that's likely at some point).
> I've done just NOP loops sometimes but it's not as nice as being able to
> specify number of microseconds directly.
> I'm using my timers for other things and I don't want to add ifs when
> triggered either in or outside ISRs.
> I found that the compiler does support "__builtin_avr_delay_cycles" but
> the 20100110 delay.h doesn't use it; there is a new delay.h that uses it
> here:
> http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=100131&postdays=0&postorder=asc&sid=ea59a79d21c3eae4542bb467153721df
> I think some faith can work sometime :-)
> Thanks again,
> Cat
>
> [Non-text portions of this message have been removed]
>
>

Hello, Cat -

What you say is quite important, and it is something that I have struggled
over, finally yielding to the Great Dice Thrower In The Sky. Any time you
use a library function, you really OUGHT to check it. But, if you do, and
find it lacking, what do you do? And, what happens when ANY function in
the library breaks in the future? Even standard, use-it -all- the-time
ones like itoa() can break at some unpredictable time in the future.

You have to trust that the library maintainers will, in fact, look out for
you and me and all the other users. I subscribe the the avrlibc developers
list, or what ever it is called. Those folks go through a lot of agony,
trying to figure out how to fix problems while keeping bad things from
happening to our projects. But, I also know that they are human, and will
occasionally make a poor choice (aka "screw up").

The same is true for all of the other support tools, like MFILE, avrdude
(I hate that name - ! - ), and such. They can break at any time and leave
us in the lurch. But, you know what, commercial tools can have that happen
also (but we pay big dollars for them to try to minimize the odds).
However, that is true for ALL the software we use. You pay your money, you
roll the dice, and you get what you get!

Jim Wagner
Oregon Research Electronics

Well said Jim,
I wish I had the resources (time/people) to check everything or write my own.I don't.
Cat

> 
> Hello, Cat -
> 
> What you say is quite important, and it is something that I have struggled
> over, finally yielding to the Great Dice Thrower In The Sky. Any time you
...> However, that is true for ALL the software we use. You pay your money, you
> roll the dice, and you get what you get!
> 
> Jim Wagner
> Oregon Research Electronics

 		 	   		  

[Non-text portions of this message have been removed]

And just in case any "library maintainers" read this,
Thank you for all your work; life would be much harder without you :-)
Cat


> You have to trust that the library maintainers will, in fact, look out for
> you and me and all the other users. ...
 		 	   		  

[Non-text portions of this message have been removed]

It is usually a good idea to following some sort of programming template as well, i tend (not always) to follow the MISRA C programming guidelines as to structure and technique, it enforces good programming techniques amd just as importantly design methodology and documentation. It is difficult to read and follow at first but you get used to it. Loops can get stuck and there should always be a "supervisor" module to help the software out if it does i.e a watchdog timer, often used and often abused but if used in the correct manner can save lock up and headaches.
 
regards


--- On Tue, 5/7/11, Cat C <catalin_cluj@hotmail.com> wrote:

From: Cat C <catalin_cluj@hotmail.com>
Subject: RE: [AVR-Chat] Delay functions and "__builtin_avr_delay_cycles".
To: avr-chat@yahoogroups.com
Date: Tuesday, 5 July, 2011, 16:35


  




Thank you all for input,There is sooth in what you all say and I tend to agree.
However, where does it stop?If it takes longer to write something because I don't trust any libraries I waste time writing my own.
If I trust them, I may need to spend time fixing IF they break (and I know that's likely at some point).
I've done just NOP loops sometimes but it's not as nice as being able to specify number of microseconds directly.
I'm using my timers for other things and I don't want to add ifs when triggered either in or outside ISRs.
I found that the compiler does support "__builtin_avr_delay_cycles" but the 20100110 delay.h doesn't use it; there is a new delay.h that uses it here:
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=100131&postdays=0&postorder=asc&sid=ea59a79d21c3eae4542bb467153721df
I think some faith can work sometime :-)
Thanks again,
Cat 

[Non-text portions of this message have been removed]








[Non-text portions of this message have been removed]

On Tue, Jul 05, 2011 at 09:35:19AM -0600, Cat C wrote:
> 
> Thank you all for input,There is sooth in what you all say and I tend
> to agree. However, where does it stop?If it takes longer to write
> something because I don't trust any libraries I waste time writing my
> own.

Didn't say that. Said it was your responsibility to review the code and
suggested leaving the "generate disassembly" option enabled to serve
that purpose.

> If I trust them, I may need to spend time fixing IF they break (and I
> know that's likely at some point).

More likely the problem is that they do not produce the time intervals
expected. Another problem is the potential to use unexpected resources.

> I've done just NOP loops sometimes but it's not as nice as being able
> to specify number of microseconds directly.

Yes, but unless you review the code you don't really know its producing
microseconds. You may specify in microseconds but the resolution is
milliseconds. You may specify a big number that fits in the function
prototype only to find a smaller number is all that is used.

> I'm using my timers for other things and I don't want to add ifs when
> triggered either in or outside ISRs.

Its not that bad. Most projects should have something like a 10 ms timer
running all the time that you can multiplex that one timer into multiple
timers very easily. Especially when events don't have to happen exactly
at a specified time but you only need to know if enough time has
elapsed.

In your interrupt service routine do something like this:

	if( timer_waiting_for_Christmas )
		timer_waiting_for_Christmas--;

You can add many of those at almost no execution time cost. If you want
to know when a second has elapsed just put 100 in there and when it
reaches zero you know a second has passed. For the AVR if the timer
variable is larger than 8 bits then you need to block interrupts when
setting or reading. And in all cases the variable needs to be volatile.

If you really have to do something simple when the software timer
expires then:

	if( timer_waiting_for_Christmas )
		if( --timer_waiting_for_Christmas == 0 )
			something_simple;

-- 
David Kelly N4HHE, dkelly@HiWAAY.net
========================================================================
Whom computers would destroy, they must first drive mad.

I've never seen a Watchdog Timer prevent a lock up, they do let you recover from one :)

--- On Tue, 7/5/11, STEVEN HOLDER <s.holder123@btinternet.com> wrote:
> ... Loops can get stuck and there should
> always be a "supervisor" module to help the software out if
> it does i.e a watchdog timer, often used and often abused
> but if used in the correct manner can save lock up and
> headaches.

Also on NOPs for timing, there are times to use them, such as isochronous code (i.e. if you are making an embedded system where you have to GUARANTEE that, whatever path through your code is taken, it takes the same number of CPU cycles) - That's rare usually, last time I used it was a while ago, on an Avionics Safety System. It's frankly a lot more work than just using a timer to execute your code, when you need it though, you NEED it, the pay and work ethics / environment made it worth it, at least :)

Also - when you can, use your computer to test your software i.e. make a list of all your assumptions, and create a way to TEST that using software, some way you can instrument i.e. have a timer loop generate a series of periods (square wave is good here) that you can monitor with an OScope, to show you that your timer routine does in fact work as you expect; Fairly simple to do and can save tearing out huge handfuls of hair. If I have spare pins on a uC I tend to have those pins do things to show me what's going on, so I can probe them during debugging, things like "this pin toggles when this timer routine is entered" or the like; You can XOR the pin state, something so you see activity there that is meaningful to YOU, if not to anyone else. Documenting that is a good idea, for WHEN you have to add another kitchen sink to that project a year later :)

  Mark