From what I can tell, that is a problem in the setup/creation of the KIPR library. What is happening is that your program is compiling okay. However, when the linker goes to find thread_destroy and thread_wait, those functions do not exist in the library. The linker is able to find thread_create and thread_start. The source code for these functions (thread_destroy and thread_wait) does exist in the kiss libraries on github but, for some reason, did not get compiled into the object library.
Andrew, are you compiling from a flash drive or from KISS-IDE? The mention of "x86-64" makes me wonder....
-Jeremy Rand
Senior Programmer, Team SNARC (2012-2013), Norman Advanced (2010-2011), Norman HS (2008-2009), Norman North (2005-2007), Whittier MS (2003-2004)
2012-2013 VP of Tech, 2011 President, Botball YAC (2009-2013)
Mentor, Alcott and Whittier MS
Try compiling from a flash drive and see if you get the same errors.
-Jeremy Rand
Senior Programmer, Team SNARC (2012-2013), Norman Advanced (2010-2011), Norman HS (2008-2009), Norman North (2005-2007), Whittier MS (2003-2004)
2012-2013 VP of Tech, 2011 President, Botball YAC (2009-2013)
Mentor, Alcott and Whittier MS
The x86-64 implies that the library stubs used to compile the source under KISS are not consistent with those on the Link. This used to happen on the CBC, etc as well.
One temporary fix that worked in the past would be to add this conditional code to the program:
Note: may need to change the functions to match their prototypes
"LINUX" may need to be changed to an identifier that is on the link - in the past LINUX worked
What this does is to allow these functions to be included in a KISS build and take care of the linker errors. When the code it transferred to a Link, the compiler should ignore these lines.
I went back and checked were this workaround was used and I found that "LINUX" should have been "linux" (all lowercase). This will matter only when you compile it on the Link.
No, as long as the position_function doesn't return until the servo has moved, you should be okay.
What kind of compile errors are you getting?
Eugene Myers
Cedarhouse Robotics
http://imgur.com/wVP5ZoV
-amehta (Andrew Mehta)
From what I can tell, that is a problem in the setup/creation of the KIPR library. What is happening is that your program is compiling okay. However, when the linker goes to find thread_destroy and thread_wait, those functions do not exist in the library. The linker is able to find thread_create and thread_start. The source code for these functions (thread_destroy and thread_wait) does exist in the kiss libraries on github but, for some reason, did not get compiled into the object library.
So, KIPR needs to fix this.
Eugene Myers
Cedarhouse Robotics
Andrew, are you compiling from a flash drive or from KISS-IDE? The mention of "x86-64" makes me wonder....
-Jeremy Rand
Senior Programmer, Team SNARC (2012-2013), Norman Advanced (2010-2011), Norman HS (2008-2009), Norman North (2005-2007), Whittier MS (2003-2004)
2012-2013 VP of Tech, 2011 President, Botball YAC (2009-2013)
Mentor, Alcott and Whittier MS
So if KIPR needs to fix this, what do you suggest I do in the mean time to parallel process?
And Jeremy, I'm compiling on KISS IDE
-amehta (Andrew Mehta)
Try compiling from a flash drive and see if you get the same errors.
-Jeremy Rand
Senior Programmer, Team SNARC (2012-2013), Norman Advanced (2010-2011), Norman HS (2008-2009), Norman North (2005-2007), Whittier MS (2003-2004)
2012-2013 VP of Tech, 2011 President, Botball YAC (2009-2013)
Mentor, Alcott and Whittier MS
The x86-64 implies that the library stubs used to compile the source under KISS are not consistent with those on the Link. This used to happen on the CBC, etc as well.
One temporary fix that worked in the past would be to add this conditional code to the program:
#ifndef LINUX
void thread_destory(thread t) {}
void thread_wait(thread t) {}
#endif
Note: may need to change the functions to match their prototypes
"LINUX" may need to be changed to an identifier that is on the link - in the past LINUX worked
What this does is to allow these functions to be included in a KISS build and take care of the linker errors. When the code it transferred to a Link, the compiler should ignore these lines.
I don't have a way to test this at this time...
Eugene Myers
Cedarhouse Robotics
I'll try both of those and let you know, thanks
-amehta (Andrew Mehta)
The flashdrive solution didn't work, but the other solution compiled. I'll let you know if it works when I get back in town
-amehta (Andrew Mehta)
I went back and checked were this workaround was used and I found that "LINUX" should have been "linux" (all lowercase). This will matter only when you compile it on the Link.
Eugene Myers
Cedarhouse Robotics