| Author |
Message |
|
|
 Posted: Jun 25, 2005 - 04:03 PM |
|
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 |
|
|
| |
|
|
|
|
|
|
Posted: Jun 25, 2005 - 11:02 PM |
|
Joined: Dec 20, 2002
Posts: 7277
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.
|
| |
|
|
|
|
|
|
Posted: Jun 26, 2005 - 10:27 AM |
|
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 |
|
|
| |
|
|
|
|
|
|
Posted: Jun 26, 2005 - 10:50 AM |
|
Joined: Dec 20, 2002
Posts: 7277
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.
|
| |
|
|
|
|
|
|
Posted: Nov 07, 2005 - 12:44 AM |
|
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. |
|
|
| |
|
|
|
|
|
|
Posted: Nov 28, 2005 - 01:08 PM |
|
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. |
|
|
| |
|
|
|
|
|
|
Posted: Jul 27, 2006 - 12:14 AM |
|
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 |
|
|
| |
|
|
|
|
|
|
Posted: Jul 27, 2006 - 07:49 AM |
|
Joined: Dec 20, 2002
Posts: 7277
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.
|
| |
|
|
|
|
|
|
Posted: Jul 27, 2006 - 08:05 AM |
|
Joined: Jan 23, 2004
Posts: 9826
Location: Trondheim, Norway
|
|
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  |
_________________
Atmel Studio 6.1 is now released, grab it here.
Report AS6/ASF bugs here.
|
| |
|
|
|
|
|
|
Posted: Jul 27, 2006 - 01:10 PM |
|
Joined: Jun 23, 2003
Posts: 76
|
|
"Bug" (Enhancement request really) filed under Bug# 17216
Good job Hans-Juergen (and of course Jörg Wunsch et al for original implementation)
T |
|
|
| |
|
|
|
|
|
|
Posted: Jul 28, 2006 - 10:55 AM |
|
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, |
|
|
| |
|
|
|
|
|
|
Posted: Jan 03, 2008 - 06:45 PM |
|
Joined: Dec 01, 2007
Posts: 43
|
|
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!!
|
| |
|
|
|
|
|
|
Posted: Jan 03, 2008 - 10:14 PM |
|
Joined: Nov 17, 2004
Posts: 13840
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.
|
| |
|
|
|
|
|
|
Posted: Jan 04, 2008 - 12:01 AM |
|
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 |
|
|
| |
|
|
|
|
|
|
Posted: Jan 04, 2008 - 08:56 AM |
|
Joined: Dec 01, 2007
Posts: 43
|
|
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!!
|
| |
|
|
|
|
|
|
Posted: Jan 04, 2008 - 09:19 PM |
|
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 |
|
|
| |
|
|
|
|
|
|
Posted: Jan 04, 2008 - 09:22 PM |
|
Joined: Dec 01, 2007
Posts: 43
|
|
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  |
_________________
I'm a Newbie! ... and it's not my fault!!
|
| |
|
|
|
|
|
|
Posted: Jan 28, 2008 - 09:31 AM |
|
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? |
|
|
| |
|
|
|
|
|
|
Posted: Jan 28, 2008 - 08:06 PM |
|
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 |
|
|
| |
|
|
|
|
|
|
Posted: Jan 28, 2008 - 08:30 PM |
|
Joined: Jul 18, 2005
Posts: 803
|
|
ok, so it's doable:)
Is there anyone who wanna do this then? |
|
|
| |
|
|
|
|
|
FAQ
Search
Register
Log in to check your private messages
Log in
Maximize
RSS
