Forum Menu




 


Log in Problems?
New User? Sign Up!
AVR Freaks Forum Index

Post new topic   Reply to topic
View previous topic Printable version Log in to check your private messages View next topic
Author Message
heinrichs.hj
PostPosted: Jun 25, 2005 - 04:03 PM
Wannabe


Joined: Jul 25, 2002
Posts: 68
Location: Paderborn, Germany

Hello All,

inspired by the delay routines in <avr/delay.h>, I have written a more general approach. I would like to contribute this to the community and get some feedback if it is useful.

The code is not heavily tested so far. I did some short testprograms and found it OK. I think the compiler option '-O s' is neccessary.

Best regards and awaiting some feedback,
Hans-Juergen
 
 View user's profile Send private message  
Reply with quote Back to top
dl8dtl
PostPosted: Jun 25, 2005 - 11:02 PM
Raving lunatic


Joined: Dec 20, 2002
Posts: 7367
Location: Dresden, Germany

Can you comment on what problem it is trying to solve exactly?

_________________
Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.
Please read the `General information...' article before.
 
 View user's profile Send private message Send e-mail Visit poster's website 
Reply with quote Back to top
heinrichs.hj
PostPosted: Jun 26, 2005 - 10:27 AM
Wannabe


Joined: Jul 25, 2002
Posts: 68
Location: Paderborn, Germany

Quote:
Can you comment on what problem it is trying to solve exactly?


(I know active delay loops are a waste of CPU power, but sometimes they are the moste easy way to generate delays)

The function _delay_cycles( any_char_int_long_float_double_type_constant ) will always generate an accurate number of cpu cycles. As a programmer you do not have to think about implementation with nops or byte counters or int counters or long counters any more.
The function covers delays from a single cycle up to more than 500 seconds (8MHz).

_delay_cycles() could be the the same solution for WinAVR as we have it in the IAR compiler with its intrinsic __delay_cycles( unsigned long int ).

Hans-Juergen
 
 View user's profile Send private message  
Reply with quote Back to top
dl8dtl
PostPosted: Jun 26, 2005 - 10:50 AM
Raving lunatic


Joined: Dec 20, 2002
Posts: 7367
Location: Dresden, Germany

I might have a look at it, OK. If you prefer, you could submit it to
the patch tracker of avr-libc so it won't be forgotten.

Anyway, programmers are usually not interested in delaying any number
of CPU cycles but any number of {micro,milli,}seconds. Incidentally,
I recently tried to implement something like that (similar to the
_delay_us in avr-libc) for the IAR compiler, but failed with the
issue. As the more simple implementation of such an algorithm (as
found in the avr-libc implementation of _delay_{us,ms}) rather need
some temp variables so they would best be implemented as an inlined
function call, it turns out you cannot do this with IAR's intrinsic
__delay_cycles function as it insists on getting a compile-time
constant parameter and it does not recognize the parameter to an
inline function call as being compile-time constant. Sigh.

I agree that extending the avr-libc implementation to uint32_t would
be a nice thing. I'd also prefer to offer the equivalent
_delay_us/ms/s abstraction for it then, as this is (from my
experience) what people have always been asking for.

_________________
Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.
Please read the `General information...' article before.
 
 View user's profile Send private message Send e-mail Visit poster's website 
Reply with quote Back to top
baxsie
PostPosted: Nov 07, 2005 - 12:44 AM
Newbie


Joined: Mar 23, 2003
Posts: 10


Hans-Juergen Heinrichs:

This header file ROCKS!

I used it to make sure that I met the hardware timing on a graphic LCD. That is a geuine concern on the 16MHz parts . . you can clock the chip before the timing is met on the data pins that were written in the last instruction.

I had tweaked the LCD interface routine with the IAR delay_cycles function, and replacing that function 1:1 with the function from this library worked fine, and the overall screen updates took the same amount of time.

I vote for this file being included in the default GCC / WinAVR distribution . . maybe changing the name so it matches the name in the IAR stuff, since that will help everyone's code be more portable.
 
 View user's profile Send private message  
Reply with quote Back to top
johannkok
PostPosted: Nov 28, 2005 - 01:08 PM
Wannabe


Joined: May 13, 2002
Posts: 52
Location: Pretoria, South Africa

I agree with Baxsie, this header file looks very nice. What I also like here is that I can now use my own #define CPU_FREQ constant which I put in a _conf.h file in the directory of every project.

I'm still inexperienced with inline ASM, though, so I'll just assume for now that you're asm code is actually working.
 
 View user's profile Send private message Send e-mail  
Reply with quote Back to top
tomasch
PostPosted: Jul 27, 2006 - 12:14 AM
Wannabe


Joined: Jun 23, 2003
Posts: 76


I found this header to be extremely useful - add my vote for inclusion in the "next version" of avrlib

T
 
 View user's profile Send private message  
Reply with quote Back to top
dl8dtl
PostPosted: Jul 27, 2006 - 07:49 AM
Raving lunatic


Joined: Dec 20, 2002
Posts: 7367
Location: Dresden, Germany

For that, please file a bug report to the avr-libc project.

_________________
Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.
Please read the `General information...' article before.
 
 View user's profile Send private message Send e-mail Visit poster's website 
Reply with quote Back to top
abcminiuser
PostPosted: Jul 27, 2006 - 08:05 AM
Moderator


Joined: Jan 23, 2004
Posts: 10204
Location: Melbourne, Australia

Looks quite brilliant to me! I too wondered at first what exactly it was trying to achieve, but I think I can see it now. Accurate delays up to 500s at 8MHz? Count (heh) me in!

(n+1)thing this to be included in the next AVRLibC instead of the current delay system (as this looks backwards compatible also).

- Dean Twisted Evil

_________________
Make Atmel Studio better with my free extensions. Open source and feedback welcome!
 
 View user's profile Send private message Send e-mail Visit poster's website 
Reply with quote Back to top
tomasch
PostPosted: Jul 27, 2006 - 01:10 PM
Wannabe


Joined: Jun 23, 2003
Posts: 76


"Bug" (Enhancement request really) filed under Bug# 17216

Good job Hans-Juergen (and of course Jrg Wunsch et al for original implementation)

T
 
 View user's profile Send private message  
Reply with quote Back to top
Sonos
PostPosted: Jul 28, 2006 - 10:55 AM
Resident


Joined: Jan 22, 2004
Posts: 689


baxsie wrote:
Hans-Juergen Heinrichs:
I used it to make sure that I met the hardware timing on a graphic LCD. That is a geuine concern on the 16MHz parts . . you can clock the chip before the timing is met on the data pins that were written in the last instruction.


I came across this problem using a m128 @14 mHz for the t6963 graphic controller software. I thought the problem was a need for longer delays, but after debugging w/ a logic analyzer, it was a logic error instead.

However, I think it is a great addition and hope the code is included. If not, I'll save it on my own cvs,
 
 View user's profile Send private message Visit poster's website 
Reply with quote Back to top
MakeeK
PostPosted: Jan 03, 2008 - 06:45 PM
Rookie


Joined: Dec 01, 2007
Posts: 45


What I'm doing wrong because this delay_x.h isn't very accurate.

I'm using now delay loop:
Code:

void Delay_ms(unsigned int t)

  {
   unsigned int i, aika;
   aika = 140;

   while(t--)
    for(i = 0; i < aika; i++)

       if(t==0) return;

  }


It seems to be +-0,1s/min accurate with following code:

Code:

#include <avr/io.h>
#include <avr/viive.h>

int main(void)
  {
   DDRC = 0xFF;

   while(1)
    {
     PORTC = 0x00;
     Delay_ms(500);

     PORTC = 0x01;
     Delay_ms(500);
    }
  }


with delay_x.h when calculated 60 led blinks, time was about 58,8 seconds. What is wrong?

I'm using Atmega8, winavr, optimization -O0 when using viive.h and -Os when using delay_x.h. Internal clock 4MHz.

_________________
I'm a Newbie! ... and it's not my fault!!
 
 View user's profile Send private message  
Reply with quote Back to top
Koshchi
PostPosted: Jan 03, 2008 - 10:14 PM
10k+ Postman


Joined: Nov 17, 2004
Posts: 14684
Location: Vancouver, BC

Quote:
What is wrong?

Your trying to use C to create accurate delays. C doesn't do that.

_________________
Regards,
Steve A.

The Board helps those that help themselves.
 
 View user's profile Send private message  
Reply with quote Back to top
heinrichs.hj
PostPosted: Jan 04, 2008 - 12:01 AM
Wannabe


Joined: Jul 25, 2002
Posts: 68
Location: Paderborn, Germany

Could you kindly provide your listing file (.lss) of the delay_x.h version for reference?

Best regards,
HJ
 
 View user's profile Send private message  
Reply with quote Back to top
MakeeK
PostPosted: Jan 04, 2008 - 08:56 AM
Rookie


Joined: Dec 01, 2007
Posts: 45


Listing file attached with code:
Code:

#include <avr/io.h>
#include <avr/delay_x.h>

int main(void)
  {
   DDRC = 0xFF;

   while(1)
    {
     PORTC = 0x00;
     _delay_ms(500);

     PORTC = 0x01;
     _delay_ms(500);
    }
  }

_________________
I'm a Newbie! ... and it's not my fault!!
 
 View user's profile Send private message  
Reply with quote Back to top
heinrichs.hj
PostPosted: Jan 04, 2008 - 09:19 PM
Wannabe


Joined: Jul 25, 2002
Posts: 68
Location: Paderborn, Germany

MakeeK,

the generated assembler code looks very much as expected.
Please check the real atmega8 clock frequency as the internal oscillator may be very inaccurate.

Best regards,
HJ
 
 View user's profile Send private message  
Reply with quote Back to top
MakeeK
PostPosted: Jan 04, 2008 - 09:22 PM
Rookie


Joined: Dec 01, 2007
Posts: 45


Could it be better always to use external oscillator? STK500 board has option for that I suppose..

edit: I tried now with external 4MHz crystal. Results are 4000 blinks in 4000 seconds. I think that is accurate enough Razz

_________________
I'm a Newbie! ... and it's not my fault!!
 
 View user's profile Send private message  
Reply with quote Back to top
darthvader
PostPosted: Jan 28, 2008 - 09:31 AM
Resident


Joined: Jul 18, 2005
Posts: 803


hi, I'm in deep love of this delay_x header, but now I started to work on AVR32 UC3B. So is there any technical problem to transplant this delay_x to AVR32?
 
 View user's profile Send private message  
Reply with quote Back to top
heinrichs.hj
PostPosted: Jan 28, 2008 - 08:06 PM
Wannabe


Joined: Jul 25, 2002
Posts: 68
Location: Paderborn, Germany

Porting to AV32 will not be technical problem (as long you are using GCC tool chain).
Nevertheless, AVR32 is a totaly different hardware architecture - each of the the inlined delay loops must be carefully implemented with AV32 opcodes.

----
HJ
 
 View user's profile Send private message  
Reply with quote Back to top
darthvader
PostPosted: Jan 28, 2008 - 08:30 PM
Resident


Joined: Jul 18, 2005
Posts: 803


ok, so it's doable:)

Is there anyone who wanna do this then?
 
 View user's profile Send private message  
Reply with quote Back to top
Display posts from previous:     
Jump to:  
All times are GMT + 1 Hour
Post new topic   Reply to topic
View previous topic Printable version Log in to check your private messages View next topic
Powered by PNphpBB2 © 2003-2006 The PNphpBB Group
Credits