Compiling Grbl #43

Closed
TheExtraPiece opened this Issue Dec 4, 2011 · 9 comments

Comments

Projects
None yet
4 participants
@TheExtraPiece

I'm trying to compile grbl (using avr-gcc 4.5.3 and avr-libc 1.7.1) but when I try to make the files from the repositories, I always get this error. It happens on every version of grbl.

avr-gcc -Wall -Os -DF_CPU=16000000 -mmcu=atmega328p -I. -ffunction-sections -c motion_control.c -o motion_control.o
In file included from motion_control.c:26:0:
/usr/lib/gcc/avr/4.5.3/../../../avr/include/util/delay.h: In function ‘mc_dwell’:
/usr/lib/gcc/avr/4.5.3/../../../avr/include/util/delay.h:153:28: error: __builtin_avr_delay_cycles expects an integer constant.
make: *** [motion_control.o] Error 1

Any suggestions?

@identy

This comment has been minimized.

Show comment
Hide comment
@identy

identy Dec 7, 2011

edit included file motion_control.c

void mc_dwell(uint32_t milliseconds)
{
st_synchronize();
delay_ms(milliseconds);
}

/* function for long delay */
void delay_ms(uint32_t ms) {
while ( ms )
{
_delay_ms(1);
ms--;
}
}

I Think, probe :-/

identy commented Dec 7, 2011

edit included file motion_control.c

void mc_dwell(uint32_t milliseconds)
{
st_synchronize();
delay_ms(milliseconds);
}

/* function for long delay */
void delay_ms(uint32_t ms) {
while ( ms )
{
_delay_ms(1);
ms--;
}
}

I Think, probe :-/

@chamnit

This comment has been minimized.

Show comment
Hide comment
@chamnit

chamnit Dec 8, 2011

Member

Take a look at my grbl fork. I've effectively picked up the torch, as Simen has been busy with other things. A lot of lingering bugs have been fixed and improvements have been made to v0.7, which is now master status.

FYI, a new v0.8 version with run-time commands (decelerating feedhold, resume, reset, jogging(TBD)) will be released later tonight. This is an alpha release.

Member

chamnit commented Dec 8, 2011

Take a look at my grbl fork. I've effectively picked up the torch, as Simen has been busy with other things. A lot of lingering bugs have been fixed and improvements have been made to v0.7, which is now master status.

FYI, a new v0.8 version with run-time commands (decelerating feedhold, resume, reset, jogging(TBD)) will be released later tonight. This is an alpha release.

@TheExtraPiece

This comment has been minimized.

Show comment
Hide comment
@TheExtraPiece

TheExtraPiece Dec 8, 2011

I just checked out your fork, but it seems to have the same problem. I looked into it a bit more, and it seems that it is due to a change in avr-libc. As of v1.7.1 it is not possible to use variables with the delay functions. Apparently you weren't supposed to do this with previous versions anyways, but now it is being enforced due to a change in how delays are implemented.
You're probably using an older version of the library, so you don't get this error. It's really quite trivial to fix, I just added a couple of inline functions to nuts_bolts to mimic the old functionality of _delay_ms() and _delay_us(). The function that Identy suggested above does the trick, and it seems to be what most people are using.

I just checked out your fork, but it seems to have the same problem. I looked into it a bit more, and it seems that it is due to a change in avr-libc. As of v1.7.1 it is not possible to use variables with the delay functions. Apparently you weren't supposed to do this with previous versions anyways, but now it is being enforced due to a change in how delays are implemented.
You're probably using an older version of the library, so you don't get this error. It's really quite trivial to fix, I just added a couple of inline functions to nuts_bolts to mimic the old functionality of _delay_ms() and _delay_us(). The function that Identy suggested above does the trick, and it seems to be what most people are using.

@identy

This comment has been minimized.

Show comment
Hide comment

identy commented Dec 10, 2011

:)

@chamnit

This comment has been minimized.

Show comment
Hide comment
@chamnit

chamnit Dec 10, 2011

Member

Good to know! I haven't run into this problem, as I pretty much exclusively use the avrdude compiler that comes the Arduino software. It sounds like it still supports the variable in the delay. I'll try to work a fix in when I get some time.

Member

chamnit commented Dec 10, 2011

Good to know! I haven't run into this problem, as I pretty much exclusively use the avrdude compiler that comes the Arduino software. It sounds like it still supports the variable in the delay. I'll try to work a fix in when I get some time.

@chamnit chamnit closed this Jan 28, 2012

@jes1510

This comment has been minimized.

Show comment
Hide comment
@jes1510

jes1510 Feb 4, 2012

I am having the exact same problem with the latest versions in Master and Edge.

avr-gcc -Wall -Os -DF_CPU=16000000 -mmcu=atmega328p -I. -ffunction-sections -c motion_control.c -o motion_control.o
avr-gcc -Wall -Os -DF_CPU=16000000 -mmcu=atmega328p -I. -ffunction-sections -c limits.c -o limits.o
In file included from limits.c:21:0:
/usr/lib/gcc/avr/4.5.3/../../../avr/include/util/delay.h: In function ‘homing_cycle’:
/usr/lib/gcc/avr/4.5.3/../../../avr/include/util/delay.h:230:28: error: __builtin_avr_delay_cycles expects an integer constant.
/usr/lib/gcc/avr/4.5.3/../../../avr/include/util/delay.h:230:28: error: __builtin_avr_delay_cycles expects an integer constant.
make: *** [limits.o] Error 1

jes1510 commented Feb 4, 2012

I am having the exact same problem with the latest versions in Master and Edge.

avr-gcc -Wall -Os -DF_CPU=16000000 -mmcu=atmega328p -I. -ffunction-sections -c motion_control.c -o motion_control.o
avr-gcc -Wall -Os -DF_CPU=16000000 -mmcu=atmega328p -I. -ffunction-sections -c limits.c -o limits.o
In file included from limits.c:21:0:
/usr/lib/gcc/avr/4.5.3/../../../avr/include/util/delay.h: In function ‘homing_cycle’:
/usr/lib/gcc/avr/4.5.3/../../../avr/include/util/delay.h:230:28: error: __builtin_avr_delay_cycles expects an integer constant.
/usr/lib/gcc/avr/4.5.3/../../../avr/include/util/delay.h:230:28: error: __builtin_avr_delay_cycles expects an integer constant.
make: *** [limits.o] Error 1

@chamnit

This comment has been minimized.

Show comment
Hide comment
@chamnit

chamnit Feb 4, 2012

Member

Thanks! Looks like I missed the _delay_us() calls when I had fixed it for the _delay_ms(). I'll issue a fix for this later today. If you want to fix it immediately, look in nut_bolts.c and repeat the same procedure as did with _delay_ms().

Member

chamnit commented Feb 4, 2012

Thanks! Looks like I missed the _delay_us() calls when I had fixed it for the _delay_ms(). I'll issue a fix for this later today. If you want to fix it immediately, look in nut_bolts.c and repeat the same procedure as did with _delay_ms().

@jes1510

This comment has been minimized.

Show comment
Hide comment
@jes1510

jes1510 Feb 9, 2012

Thanks that fixed it. For completeness I changed it to this in limits.c:
delay_us(settings.pulse_microseconds);
STEPPING_PORT ^= out_bits & STEP_MASK;
delay_us(step_delay);

and I added this function to nuts_bolts.h:
void delay_us(uint16_t us)
{
while (us--) { _delay_us(1);}
}

jes1510 commented Feb 9, 2012

Thanks that fixed it. For completeness I changed it to this in limits.c:
delay_us(settings.pulse_microseconds);
STEPPING_PORT ^= out_bits & STEP_MASK;
delay_us(step_delay);

and I added this function to nuts_bolts.h:
void delay_us(uint16_t us)
{
while (us--) { _delay_us(1);}
}

@chamnit

This comment has been minimized.

Show comment
Hide comment
@chamnit

chamnit Feb 9, 2012

Member

Good to hear. Sorry that I didn't post the fix when I stated. I've been sidetracked with other things. When I finally get this next edge push out, I'll make sure to update the master branch with this fix.

Member

chamnit commented Feb 9, 2012

Good to hear. Sorry that I didn't post the fix when I stated. I've been sidetracked with other things. When I finally get this next edge push out, I'll make sure to update the master branch with this fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment