samuell, it looks like your code is working fine. The problem is with printf. The printf in the library is based on the simple printf in PropGCC. It doesn't support the long long type. I modified the printf as follows, and got the output shown below.
printf("%d:\t%u\n", (int)count, (int)numbers[i]); // Imprime a contagem e o número
Insira o valor mínimo: 1
Insira o valor máximo: 30
A calcular números primos...
1: 2
2: 3
3: 5
4: 7
5: 11
6: 13
7: 17
8: 19
9: 23
10: 29
10 número(s) primo(s) encontrados.
pilot0315, I suggest that you use spin2gui instead of trying to run from the command prompt. There is a C sample program that you can use as the basis for your code.
You won't be able to run samuell's code in spin2gui because it depends on features of p2gcc. Unfortunately, p2gcc does not have a GUI.
Ive been testing a single cog version of the program (adapted from the version for Linux, that I had already translated to English). I was astonished when I found out that the P2 loaded with this version would calculate almost twice as fast as the P1 with all eight cogs clocked at 96MHz and working (technically, only seven of them are doing actual calculations).
Meanwhile, I've found out that printf() doesn't print correctly more than one variable. If you see the source code, you'll see that I've had to split the printing into two calls:
printf("%llu:\t", count); // Problem here!!!
printf("%llu\n", n); // printf() doesn't support two variables!
I'll check if this is the only problem that the full program has. The single cog version (source code attached) works perfectly.
As I mentioned earlier, p2gcc's printf doesn't handle long long variables correctly. It interprets the %llu format as just %lu. When a long long variable is used in the argument list it uses two longs on the stack. printf is only fetching one long from the stack, which happens to be the lower 32 bits of the long long variable. When it tries to print the second parameter in the argument list it is actually fetching the upper 32 bits of the first argument. That's why I changed my printf to only print 32-bit values.
Question does one always
have to run it from the command prompt?
I used to wonder if I should be trying to get to grips with Unix type shell environments. And, to be honest, I never got an answer until recently when working on the random number generator stuff. The answer is most definitely a resounding yes. And just to reinforce this some more, M$ have recently made public their own support for a Unix compatible shell that is intended for Linux scripts of various types to be used in.
I found out that the variables pertaining to the cog id cannot be of type char. Before that modification, some of the displayed results were invalid and the program would crash after a hundred and a few iterations.
Now the program works and uses all cogs. When calculating high numbers, it is possible to see how fast the P2 is compared to the P1. At least an order of magnitude faster. The architecture is so optimized, it is insane! Kudos to Chip, for designing this amazing MCU.
You can see the code inside the zip file attached.
As I mentioned earlier, p2gcc's printf doesn't handle long long variables correctly. It interprets the %llu format as just %lu. When a long long variable is used in the argument list it uses two longs on the stack. printf is only fetching one long from the stack, which happens to be the lower 32 bits of the long long variable. When it tries to print the second parameter in the argument list it is actually fetching the upper 32 bits of the first argument. That's why I changed my printf to only print 32-bit values.
Sorry Dave. I got distracted and didn't notice your answers. However, if I recall correctly, I tried to use the %d modifier, and I still had to split the printf(). Probably, the variable types will have to be modified to long or int.
However, I wonder if there will be full support for long long integers? This would be a requirement for me, since GCC as used in SimpleIDE supports them. The program, as is, doesn't accept large numbers (atol() is being used instead of atoll()). I didn't wanted to change the above variable types, not just yet, in the hopes that future support will be added. Will atoll() be implemented?
Also, is there any possibility of printf() supporting long long integers in the future?
Mind that Spin 2 GUI is a bit limited. As far as I could evaluate, it fully supports PASM and Spin, but only supports C in part (it has a less mature version of p2gcc in it). On the other hand, p2gcc provided via nix is more mature, although not quite as simple to use. If you feel confortable with Linux, this is a good option.
Mind that Spin 2 GUI is a bit limited. As far as I could evaluate, it fully supports PASM and Spin, but only supports C in part (it has a less mature version of p2gcc in it).
Actually spin2gui does not have p2gcc in it at all. The C compiler it uses is built in to fastspin, so it is very different from GCC. This has some advantages (it can directly compile Spin and BASIC objects, for example, and has a simpler inline assembly syntax) and some disadvantages (it doesn't support C++, or most of the GCC extensions to C).
Also, is there any possibility of printf() supporting long long integers in the future?
Yes, I can add support for long long. I'll look into when I get a chance. In the mean time you can use %d and %u by casting your long long variables to int. That's how I did it.
Mind that Spin 2 GUI is a bit limited. As far as I could evaluate, it fully supports PASM and Spin, but only supports C in part (it has a less mature version of p2gcc in it).
Actually spin2gui does not have p2gcc in it at all. The C compiler it uses is built in to fastspin, so it is very different from GCC. This has some advantages (it can directly compile Spin and BASIC objects, for example, and has a simpler inline assembly syntax) and some disadvantages (it doesn't support C++, or most of the GCC extensions to C).
Also, is there any possibility of printf() supporting long long integers in the future?
Yes, I can add support for long long. I'll look into when I get a chance. In the mean time you can use %d and %u by casting your long long variables to int. That's how I did it.
printf("%d:\t%u\n", (int)count, (int)numbers[i]);
Please let me know when you do. Thanks in advance.
I'm really sorry because I'm sure I've asked this same question at least once before but where can I download the latest sources for loadp2?
Edit: Never mind. I see there is a copy of loadp2 in the spin2gui repository. Now I just have to figure out how to get my Hello, World program working on the Mac.
I just wanted to know, when we load a program using p2gcc, what is the clock frequency that the P2 is set to. I've noticed that it is definitely using the crystal. Can it be 180MHz?
I just wanted to know, when we load a program using p2gcc, what is the clock frequency that the P2 is set to. I've noticed that it is definitely using the crystal. Can it be 180MHz?
Also, how to set to a different frequency?
p2gcc uses loadp2 to download the compiled code. Help emit from loadp2 is:
loadp2 - a loader for the propeller 2 - version 0.007, 2018-12-29
usage: loadp2
[ -p port ] serial port
[ -b baud ] baud rate (default is -1)
[ -f clkfreq ] clock frequency (default is 80000000)
[ -m clkmode ] clock mode in hex (default is ffffffff)
[ -s address ] starting address in hex (default is 0)
[ -t ] enter terminal mode after running the program
[ -T ] enter PST-compatible terminal mode
[ -v ] enable verbose mode
[ -? ] display a usage message and exit
[ -CHIP ] set load mode for CHIP
[ -FPGA ] set load mode for FPGA
[ -SINGLE ] set load mode for single stage
file file to load
So default loader clock rate is 80 MHz. To change it add a -f [clkfreq of choice]
Currently p2gcc runs at 80 MHz. You have to run loadp2 directly to select a higher frequency. To run a program at 180 MHz you would do something like this.
p2gcc hello.c
loadp2 -f 180000000 -b -1 -t a.out
The "-b -1" option tells loadp2 to adjust the user baud rate based on the clock frequency. At 180MHz the baud rate will be 180*115200/80 = 259200. This is a kludge to handle the fact that the serial driver is hardcoded for 80 MHz. Eventually, I'll have the loader set a clkfreq variable so that the baud rate can adjust for the clock frequency, and remain constant.
I just wanted to know, when we load a program using p2gcc, what is the clock frequency that the P2 is set to. I've noticed that it is definitely using the crystal. Can it be 180MHz?
Also, how to set to a different frequency?
p2gcc uses loadp2 to download the compiled code. Help emit from loadp2 is:
loadp2 - a loader for the propeller 2 - version 0.007, 2018-12-29
usage: loadp2
[ -p port ] serial port
[ -b baud ] baud rate (default is -1)
[ -f clkfreq ] clock frequency (default is 80000000)
[ -m clkmode ] clock mode in hex (default is ffffffff)
[ -s address ] starting address in hex (default is 0)
[ -t ] enter terminal mode after running the program
[ -T ] enter PST-compatible terminal mode
[ -v ] enable verbose mode
[ -? ] display a usage message and exit
[ -CHIP ] set load mode for CHIP
[ -FPGA ] set load mode for FPGA
[ -SINGLE ] set load mode for single stage
file file to load
So default loader clock rate is 80 MHz. To change it add a -f [clkfreq of choice]
Currently p2gcc runs at 80 MHz. You have to run loadp2 directly to select a higher frequency. To run a program at 180 MHz you would do something like this.
p2gcc hello.c
loadp2 -f 180000000 -b -1 -t a.out
The "-b -1" option tells loadp2 to adjust the user baud rate based on the clock frequency. At 180MHz the baud rate will be 180*115200/80 = 259200. This is a kludge to handle the fact that the serial driver is hardcoded for 80 MHz. Eventually, I'll have the loader set a clkfreq variable so that the baud rate can adjust for the clock frequency, and remain constant.
Thanks! If the clock frequency is set to 80MHz by default, that means the P2 architecture is already much more efficient than the former. I saw a tenfold increase in terms of speed. That is insane!
I'll have to try this at 240MHz. Is there any way to define the clock speed inside the code so that the baud rate stays correct. I'm using these two steps on terminal:
Setting the frequency to 80MHz, in that second line, the output will be correct. Setting it to 180MHz or 240MHz, will cause odd characters to be displayed.
Setting the frequency to 80MHz, in that second line, the output will be correct. Setting it to 180MHz or 240MHz, will cause odd characters to be displayed.
I verified that it is actually working as Dave explained. I ran it at 240mHz and a logic analyzer shows the serial output at 345600Kbaud (240*115200/80). If the terminal could display that it would be very cool; I'm having to view output in the LA and that is workable for the experimenting and learning I'm immersed in. I'll be eagerly awaiting Dave's de-kludged loader update.
Setting the frequency to 80MHz, in that second line, the output will be correct. Setting it to 180MHz or 240MHz, will cause odd characters to be displayed.
I verified that it is actually working as Dave explained. I ran it at 240mHz and a logic analyzer shows the serial output at 345600Kbaud (240*115200/80). If the terminal could display that it would be very cool; I'm having to view output in the LA and that is workable for the experimenting and learning I'm immersed in. I'll be eagerly awaiting Dave's de-kludged loader update.
Well, it seems that I've typed the last line incorrectly. It should be "-1" instead of "-l". You can omit the "-b -1" part.
Anyways, I now can go up to 160MHz, but no more than that. I've noticed that my program is unstable. It displays garbage numbers and rights itself after a few attempts, even at 80MHz. It was acting like that before the edit. If anyone could try that the new code, I would appreciate. The printf() statement was rectified as suggested by Dave. Please, see the attached zip file.
Dave, this is what I'm getting with the suggested arguments, just an FYI. I understand the garbage characters in the terminal but thought you'd like to know about the "Unsupported baudrate. Use cfsetispeed failed" message. Thanks for all you do!
Can you try 160MHz? That would produce a baud rate of 230400, which is a standard baud rate. You might also try 320MHz, which would produce a baud rate of 460800.
At the higher clock frequencies I also get garbage characters on startup, but the program works normally after I press enter. It takes a fraction of a second for loadp2's terminal emulator to start up, and the program must be reading garbage characters at the beginning. I added a waitcnt(80000000+CNT); at the beginning of the main routine, and it fixes the problem.
Anyways, I now can go up to 160MHz, but no more than that. I've noticed that my program is unstable. It displays garbage numbers and rights itself after a few attempts, even at 80MHz. It was acting like that before the edit.
samuell, what version of loadp2 are you using? You can see the version by typing loadp2 without any parameters. Older version of loadp2 did not configure the clock mode correctly above 200MHz. I believe I fixed that in version 0.008. The current version of loadp2 is 0.009.
EDIT: I tried your new code, and it does not produce the correct numbers. The old code worked correctly.
OK both 160MHz and 320MHz worked fine! I spent a little time looking at the source of loadp2 and can now clearly see the logic employed. Thanks again - the fog is starting to lift.
I did a diff of the new primos.c and the old one, and I found the problem. You declare the array stacks as "unsigned int stacks[7][44]". It appears that 44 is not large enough. In my old version I added a zero to make it stacks[7][440], and this works correctly. I'm sure that 440 ints is much more than needed, and some smaller value should work. I tried 100, and that works. 50 doesn't work. I would go with 100 to be safe.
You could analyze your stack usage by prefilling it with a known value, and then checking the stacks after you run the program. I'll give it a try and let you know what I find.
Setting the frequency to 80MHz, in that second line, the output will be correct. Setting it to 180MHz or 240MHz, will cause odd characters to be displayed.
I verified that it is actually working as Dave explained. I ran it at 240mHz and a logic analyzer shows the serial output at 345600Kbaud (240*115200/80). If the terminal could display that it would be very cool;.
Did you try asking Terminal for 342857 Baud ? Most USB-UARTS have a virtual baud clock of 12MHz (some are 24MHz), so that's (12M/35), the nearest number.
Comments
If not is it in Dave Heins load2? I need some help to run it in the command prompt please.
Thanks.
Martin
printf("%d:\t%u\n", (int)count, (int)numbers[i]); // Imprime a contagem e o númeroYou won't be able to run samuell's code in spin2gui because it depends on features of p2gcc. Unfortunately, p2gcc does not have a GUI.
Kind regards, Samuel Lourenço
Ive been testing a single cog version of the program (adapted from the version for Linux, that I had already translated to English). I was astonished when I found out that the P2 loaded with this version would calculate almost twice as fast as the P1 with all eight cogs clocked at 96MHz and working (technically, only seven of them are doing actual calculations).
Meanwhile, I've found out that printf() doesn't print correctly more than one variable. If you see the source code, you'll see that I've had to split the printing into two calls:
printf("%llu:\t", count); // Problem here!!! printf("%llu\n", n); // printf() doesn't support two variables!I'll check if this is the only problem that the full program has. The single cog version (source code attached) works perfectly.Kind regards, Samuel Lourenço
I used to wonder if I should be trying to get to grips with Unix type shell environments. And, to be honest, I never got an answer until recently when working on the random number generator stuff. The answer is most definitely a resounding yes. And just to reinforce this some more, M$ have recently made public their own support for a Unix compatible shell that is intended for Linux scripts of various types to be used in.
I found out that the variables pertaining to the cog id cannot be of type char. Before that modification, some of the displayed results were invalid and the program would crash after a hundred and a few iterations.
Now the program works and uses all cogs. When calculating high numbers, it is possible to see how fast the P2 is compared to the P1. At least an order of magnitude faster. The architecture is so optimized, it is insane! Kudos to Chip, for designing this amazing MCU.
You can see the code inside the zip file attached.
Kind regards, Samuel Lourenço
However, I wonder if there will be full support for long long integers? This would be a requirement for me, since GCC as used in SimpleIDE supports them. The program, as is, doesn't accept large numbers (atol() is being used instead of atoll()). I didn't wanted to change the above variable types, not just yet, in the hopes that future support will be added. Will atoll() be implemented?
Also, is there any possibility of printf() supporting long long integers in the future?
Kind regards, Samuel Lourenço
You can install a Ubuntu/Kubuntu VM and follow the instructions here, if you still wish to use p2gcc:
http://forums.parallax.com/discussion/169589/p2-tooling-installation-via-nix-for-anylinux-any-linux-distribution/
Mind that Spin 2 GUI is a bit limited. As far as I could evaluate, it fully supports PASM and Spin, but only supports C in part (it has a less mature version of p2gcc in it). On the other hand, p2gcc provided via nix is more mature, although not quite as simple to use. If you feel confortable with Linux, this is a good option.
Kind regards, Samuel Lourenço
Actually spin2gui does not have p2gcc in it at all. The C compiler it uses is built in to fastspin, so it is very different from GCC. This has some advantages (it can directly compile Spin and BASIC objects, for example, and has a simpler inline assembly syntax) and some disadvantages (it doesn't support C++, or most of the GCC extensions to C).
printf("%d:\t%u\n", (int)count, (int)numbers[i]);Kind regards, Samuel Lourenço
Edit: Never mind. I see there is a copy of loadp2 in the spin2gui repository. Now I just have to figure out how to get my Hello, World program working on the Mac.
I just wanted to know, when we load a program using p2gcc, what is the clock frequency that the P2 is set to. I've noticed that it is definitely using the crystal. Can it be 180MHz?
Also, how to set to a different frequency?
Kind regards, Samuel Lourenço
p2gcc uses loadp2 to download the compiled code. Help emit from loadp2 is:
loadp2 - a loader for the propeller 2 - version 0.007, 2018-12-29 usage: loadp2 [ -p port ] serial port [ -b baud ] baud rate (default is -1) [ -f clkfreq ] clock frequency (default is 80000000) [ -m clkmode ] clock mode in hex (default is ffffffff) [ -s address ] starting address in hex (default is 0) [ -t ] enter terminal mode after running the program [ -T ] enter PST-compatible terminal mode [ -v ] enable verbose mode [ -? ] display a usage message and exit [ -CHIP ] set load mode for CHIP [ -FPGA ] set load mode for FPGA [ -SINGLE ] set load mode for single stage file file to loadSo default loader clock rate is 80 MHz. To change it add a -f [clkfreq of choice]I'll have to try this at 240MHz. Is there any way to define the clock speed inside the code so that the baud rate stays correct. I'm using these two steps on terminal: Setting the frequency to 80MHz, in that second line, the output will be correct. Setting it to 180MHz or 240MHz, will cause odd characters to be displayed.
Kind regards, Samuel Lourenço
Anyways, I now can go up to 160MHz, but no more than that. I've noticed that my program is unstable. It displays garbage numbers and rights itself after a few attempts, even at 80MHz. It was acting like that before the edit. If anyone could try that the new code, I would appreciate. The printf() statement was rectified as suggested by Dave. Please, see the attached zip file.
Kind regards, Samuel Lourenço
At the higher clock frequencies I also get garbage characters on startup, but the program works normally after I press enter. It takes a fraction of a second for loadp2's terminal emulator to start up, and the program must be reading garbage characters at the beginning. I added a waitcnt(80000000+CNT); at the beginning of the main routine, and it fixes the problem.
EDIT: I tried your new code, and it does not produce the correct numbers. The old code worked correctly.
Mike R...
You could analyze your stack usage by prefilling it with a known value, and then checking the stacks after you run the program. I'll give it a try and let you know what I find.