Solved: Where is delay_ms()?

Go To Last Post
19 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've tried including delay.h, using ASF Wizard, but the function delay_ms() just won't show up in blue as a used function. How can I get it? I need it for LCD initialization.

Last Edited: Sat. Jan 2, 2016 - 01:28 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

try: __delay_ms()   two leading underscores.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

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

Did it, but now I have:

Error    2    __builtin_avr_delay_cycles expects a compile time integer constant    c:\program files\atmel\atmel toolchain\avr8 gcc\native\3.4.1061\avr8-gnu-toolchain\avr\include\util\delay.h    163    28    GccBoardProject1

Here's what I have at the beginning of the Code1.h file

#ifndef CODE1_H_
#define CODE1_H_
#define F_CPU 32768000UL

#include <sysclk.h>
#include <util/delay.h>
#include <asf.h> 

The main file has 

#include "Code1.h"

Googling AVRFreaks errors didn't give me the exact same problem that I have.

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

Fixed that, but now my XMEGA is stuck on

	__builtin_avr_delay_cycles(__ticks_dc);

in delay.h. I'm testing it with Embedded Debugger.

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

What does 'stuck' mean? If it's an error in the build output, >>show<< it.
If you mean the error you show in your previous post, it seems self-explanatory. You cannot use a variable delay. The argument you pass must be a constant known at compile time. _delay_ms() merely computes the proper number of cpu cycles and calls __builtin_avr_delay_cycles().

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Wed. Dec 30, 2015 - 12:54 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Foxcat385 wrote:

Fixed that, but now my XMEGA is stuck on

	__builtin_avr_delay_cycles(__ticks_dc);

in delay.h. I'm testing it with Embedded Debugger.

Tell us more about that. Are you trying to step over, step into, or did you free-run and issued a break from your debugging host?

 

Could you show a screenshot of the "stuck" situation?

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

It will take me a while to re-plug everything back together. It's also late here.

 

I clicked the green play button. Then, I saw nothing happening. No screen on LCD, nothing. Then, I pressed pause and realized that the CPU is stuck on that line of code. Then, I started debugging with break first and stepped over things. It then got always stuck on the line that I quoted when it would get to the _delay_ms();.

 

Stuck means that I would press play and then pause and then play and then pause and sometimes F10, but it's still there on that line of code.

Last Edited: Wed. Dec 30, 2015 - 11:37 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Single-stepping through _delay_ms() will be tedious, since it will involve thousands or millions of steps to take. What happens if you place a breakpoint on some code after the call to _delay_ms() and free-run?

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

It doesn't get to that code. It just runs and runs and runs...

 

...IN A CIRCLE

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

Time to see some code, methinks..

 

Best thing would be a small but complete project zipped up so that we can test it ourselves.

 

I'm not an XMEGA man, so I will test in Studio Simulator and/or on an some ATmega with ATMELICE.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

Foxcat385 wrote:

It doesn't get to that code. It just runs and runs and runs...

 

...IN A CIRCLE


Real AVR or simulator? The latter behaves like a 50kHz CPU so delays intended to take a second at 8MHz would take 160 times longer, you would need a LOT of patience!

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

I used a REAL Xmega Xplained A1U Pro with Embedded Debugger that's on it.

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

Foxcat385 wrote:
I've tried including delay.h, using ASF Wizard, but the function delay_ms() just won't show up in blue as a used function. How can I get it? I need it for LCD initialization.

Took me about an hour to find it last night. Import the delay routines module

if (PORT->Group[0].IN.reg & PORT_PA18) {
	delay_s(5000);
}

 

"When all else fails, read the directions"

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

It doesn't show me the "cycle". Now I have one of the most stupidest (hyperlative 'cuz grammar isn't enough to describe my anger) errors in the world:

implicit declaration of function '_delay_ms' [-Werror=implicit-function-declaration]

 

While the intellisense tells me that that function DOES exist!

However, the intellisense says that it needs a double number. I don't know how to convert those numbers into double. Do I really have to make a new variable every single time??? Or write (double) in 

_delay_ms((double)500);

? Is there a shorter way?

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

Update: I used delay_ms this time, but it's getting stuck again. In case I wasn't clear, I'm using a real Xmega A1U Xplained Pro. Now it's on a different line. See screenshot.

 

Note: I stole borrowed some code from a site for initializing this display just to see if it works.

Attachment(s): 

Last Edited: Sat. Jan 2, 2016 - 12:56 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Fixed it! I had to remove my own stupid F_CPU definition because ASF has already defined it

#ifndef F_CPU
#       define F_CPU sysclk_get_cpu_hz()
#endif

And then I screwed it up with my own F_CPU definition. Silly me.

The solution is to use delay_ms with ASF's delay routines and NOT define F_CPU because ASF already defines it for you.

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

Foxcat385 wrote:
It doesn't show me the "cycle". 

Possibly because PhillyNJ is working on SAMD, but you are using XMega ?

ASF really isn't that consistent across different platforms.

 

frown

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But anyways, I've fixed the problem. Now I'm trying to get my display to work which is in another thread.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
#ifndef F_CPU
#       define F_CPU sysclk_get_cpu_hz()
#endif

The things that use F_CPU will really want it to be a simple compile-time constant.

(The fact that ASF likes to use a programmatically determined value every time it want F_CPU is one of the things I really DISLIKE about it!)