I took the following actions with root rights.
1. I deleted the /opt/parallax and /opt/parallax-win32 folders.
2. I deleted the build and build-win32 folder.
3. I did the "hg diff" and "hg revert --all" commands
4. Created /opt/parallax/
5. chmod 777 /opt/parallax/
6. PATH=${PATH}:/opt/parallax/bin and export PATH=/opt/parallax/bin:${PATH}
7. make -clean
8. make
9. make CROSS=win32
The linux variant was build without errors.
For the windows variant i got:" undefined reference to `_usleep'".
The other error seem to be solved.
Do i have to do chmod 777 /opt/parallax-win32/ aswell? Or do i need to add /opt/parallax-win32/ to the $PATH variable?
Making progress.
Yes, make /opt/parallax-win32 writable - sorry I skipped that. I don't recall adding /opt/parallax/win32/bin to my PATH.
I'll retest cross-builds on linux to see if I can reproduce the usleep problem. I can also post a link to the resulting package.
I just can't post a new package everytime there is a minor library file change.
I don't know what to tell you about the usleep issue. I build on Linux Mint i686 with the mingw cross-compiler package and have no problems. There are two other developers that build it also. You may be seeing something that we take for granted. Unfortunately I don't have time to chase the problem.
EDIT: The user change didn't matter, still got the usleep error.
Can you give us the context? What's it trying to build when it gets the undefined _usleep reference? Is this an error in building gcc, or some of the binutils, or another PC based tool? Or is it a problem building the Propeller libraries or other code to run on the propeller? Does it tell you what file is referencing _usleep?
What version of mingw32 are you using? I have a declaration for usleep in <unistd.h> (on my system that's in /usr/i586-mingw32msvc/include/unistd.h). I'm cross-compiling on Ubuntu 12.04, with the default mingw32 package. "i586-mingw32msvc-gcc -v" identifies itself as:
At this point I'm thoroughly mystified. Grasping at straws, but is the "mingw32-runtime" package installed on your system? It should be, but perhaps for some reason it isn't?
usleep is provided by mingw32, so the problem is somewhere in there, not (AFAIK) in propgcc.
But the code below still produces 0. I altered the stack of the ms timer so it uses EXTRA_STACK_LONGS.
Line 17 of mstimer.c changed to: static unsigned int stack[ EXTRA_STACK_LONGS + 40 + 25]; // Stack vars for other cog
The librarie test code also produces 0.
mstimer test code:
#include "simpletools.h" #include "mstimer.h"
int main(){
low(26);
low(27);
print("Starting\n");
high(26);
mstime_start();
for (int i = 0; i < 1000; i++)
{
print("%d ", i);
}
print("\n");
int ticks = mstime_get();
mstime_stop();
print("Total time= %d\n", ticks);
high(27);
return 0;
}
Comments
Yes, make /opt/parallax-win32 writable - sorry I skipped that. I don't recall adding /opt/parallax/win32/bin to my PATH.
I'll retest cross-builds on linux to see if I can reproduce the usleep problem. I can also post a link to the resulting package.
I just can't post a new package everytime there is a minor library file change.
A Propeller GCC default branch i686 32-bit windows package is now available here:
https://drive.google.com/file/d/0BzcfH7bdVTbtNkRRbmE5TUVtTnM/edit?usp=sharing
A Propeller GCC default branch i686 32-bit linux package is available here:
https://drive.google.com/file/d/0BzcfH7bdVTbtTGZVSHp1VVpwWHc/edit?usp=sharing
I didn't have any trouble with usleep. Mega-sleep tends to elude me though.
I am now going to change the Simple Libraries so that they use the EXTRA_STACK_LONGS variable.
EDIT: The user change didn't matter, still got the usleep error.
Are you able to use the package I posted?
Is there a fast way to build the simple libaries with specific settings?
I didn't dothe following steps, because i didn't understand how to do it.
Can you give us the context? What's it trying to build when it gets the undefined _usleep reference? Is this an error in building gcc, or some of the binutils, or another PC based tool? Or is it a problem building the Propeller libraries or other code to run on the propeller? Does it tell you what file is referencing _usleep?
It looks like the error occurs when the loader is getting build.
On line 91 i did got
and you got
After that i got an error while yours continues.
Your propgcc source path is slightly different, but that shouldn't be the problem.
What are the operating systems that the others are building on?
Linux. Not sure of the distribution(s) though.
What distribution are you using?
I would guess that your mingw32 may be older (and hasn't had usleep added to it yet).
Eric
Debian, the iso name is "debian-7.4.0-amd64-i386-netinst.iso".
The propgcc guide uses debian-6.0.2.1-i386-netinst, but i don't think that can be the problem.
i586-mingw32msvc-gcc -v outputs:
It looks like i got the same version, so that shouldn't be the problem.
usleep is provided by mingw32, so the problem is somewhere in there, not (AFAIK) in propgcc.
Works fine on Mint16 and Ubuntu13 ... there are others to try of course. Not sure what the minimum version is.
Is there a trick to compile it the whole simple libraries with specific settings?
#include "simpletools.h" using namespace std; unsigned int stack[EXTRA_STACK_LONGS + 25]; void cog(void* par); int main(){ low(26); low(27); print("Starting\n"); high(26); cogstart(&cog, NULL, stack, sizeof stack); print("Done"); return 0; } void cog(void* par) { while(1) { high(27); pause(500); low(27); pause(500); } }But the code below still produces 0. I altered the stack of the ms timer so it uses EXTRA_STACK_LONGS.
Line 17 of mstimer.c changed to: static unsigned int stack[ EXTRA_STACK_LONGS + 40 + 25]; // Stack vars for other cog
The librarie test code also produces 0.
mstimer test code:
#include "simpletools.h" #include "mstimer.h" int main(){ low(26); low(27); print("Starting\n"); high(26); mstime_start(); for (int i = 0; i < 1000; i++) { print("%d ", i); } print("\n"); int ticks = mstime_get(); mstime_stop(); print("Total time= %d\n", ticks); high(27); return 0; }Did anyone test the Abdrive library with XMMC?
When i use for example "drive_speed(64,64)" the wheels stutter.
The calibration went without stuttering. This is the result of the interpolation table.
This might mean that the encoder function is running too slow.