I can't find propeller1.h in my install of SimpleIDE/PropGCC. I'll just replace the reference to getcnt() with CNT, and that will solve the problem in sdspi.h.
I can't find propeller1.h in my install of SimpleIDE/PropGCC. I'll just replace the reference to getcnt() with CNT, and that will solve the problem in sdspi.h.
propeller1.h is part of the more recent build of PropGCC that SimpleIDE does not use. When I say "recent" I mean one that is several years old at least. It's the version that supports P2-hot which is why there is a propeller1.h and a propeller2.h.
I have updated p2gcc, and attached the latest zip file here. I moved the file I/O routines to the stdio library. I also modified p2link and loadp2 so that a binary executable could be linked to a starting address other than zero. I then created a new sample program called shell.c that starts at address 0x8000 in hub RAM. This program can load binary files from an SD card and execute them. There's a script file named build_all that will build all of the sample programs. The binary files can then be copied to an SD card, which can be used by the shell program. The shell program is built and loaded by running the load_shell script file.
I now include the fft_bench program. It runs in 54 msec with the P2 set at 60 MHz.
I added support for spinsim to the p2gcc script file. A program can be build and run using the simulator by specifying the -s option. As an example, the hello program is run under spinsim by typing "p2gcc -s hello.c". spinsim is not included in the zipfile, and must be built separately.
p2gcc now requires that the bin directory be added to the PATH environment variable. Alternatively, the contents of the bin directory could be copied to an existing directory that is already included in the PATH. p2gcc also requires that the environment variable P2GCC_LIBDIR be specified and set to point to the p2gcc lib directory.
Another change I made was to enable the -c option in p2asm that makes the assembler case sensitive. This is required so that C variables such as temp and Temp can be distinguished from each other. PASM symbols, such as IF_C_OR_NZ are still handled without case sensitivity.
I renamed s2p to s2pasm. It turns out that there is already a Linux utility named s2p.
I renamed the dump utility to p2dump. I also added a disassembler option to p2dump. The disassembler can produce a spin2 file from a binary file that can be re-assembled back to a matching binary file. I've tested it with most of the sample programs that Chip includes with his FPGA updates.
You have been busy! I should give p2asm whirl. The PNut route gets a bit monotonous having to click back and forth between windows. Not to mention the recurring PNut jam-ups when I accidentally have two programs vying for the one comport due to PNut insisting on it's download after compile.
The attached file contains the latest version of p2gcc, which has been updated to support the v32b FPGA image. The source is also available on GitHub at https://github.com/davehein/p2gcc .
The attached file contains the latest version of p2gcc, which has been updated to support the v32b FPGA image. The source is also available on GitHub at https://github.com/davehein/p2gcc .
Dave, does this mean we have a passable C compiler for the Prop2, or one that can be made into a final compiler? Please forgive my ignorance on this subject. Thanks for taking interest in this!
Thanks. I added that comment about macOS to the readme.txt file, and checked it into GitHub.
Thanks, but I spoke a little too soon!
First, loadp2 needs a little help! You'll need to "#define MACOSX" in building loadp2 for a Mac to find a P2 on a PropPlug (a small serial open issue). A new build_macosx file that does the define before it execs compiles osint_linux.c, would fix this!
There's code in osint_linux.c that needs the MACOSX define. Here's an example:
/* open the port */
#ifdef MACOSX
hSerial = open(port, O_RDWR | O_NOCTTY | O_NONBLOCK);
#else
hSerial = open(port, O_RDWR | O_NOCTTY | O_NDELAY | O_NONBLOCK);
#endif
Once the above is fixed, p2gcc seems to compile a binary, loadp2 appears to upload it to the FPGA (DE0-Nano), but it's not getting expected results on the FPGA. I'm running a simple blink.c type program, that should blink an LED on pins P0 or P1. Could be my code...
#include <propeller.h>
unsigned int _clkfreq = 60000000;
int main(void)
{
DIRB |= (3);
while (1) {
OUTB |= (1 << 1); // turn on pin #1?
waitcnt(((CLKFREQ / 50) + CNT));
OUTB &= (0 << 1); // turn off pin #1?
waitcnt(((CLKFREQ / 50) + CNT));
}
}
With the limit in cogs on the DE0-Nano, I'm not sure if any of the examples should work (dry.c, prime.c, etc...), as they do not return any text when run with "-t"...
Single-character non-buffered serial I/O is a little tricky on the Mac. Output should work fine, but it may be hanging on the input. I found a solution for spinsim, but I'm not sure I ported that to loadp2. I'll look into it when I have a chance.
The attached file contains the latest version of p2gcc, which has been updated to support the v32b FPGA image. The source is also available on GitHub at https://github.com/davehein/p2gcc .
Dave, does this mean we have a passable C compiler for the Prop2, or one that can be made into a final compiler? Please forgive my ignorance on this subject. Thanks for taking interest in this!
I think p2gcc is a passable C compiler for the P2. However, it is not intended to be the final compiler for the P2. I'm hoping Parallax and people that are more experienced with GCC get involved at some point, and a compiler such as PropGCC can be developed for the P2. I think components of p2gcc can be used, but we need a team of people that understand GUIs, ELF files and other details to really make it work for everyone.
The attached file contains the latest version of p2gcc, which has been updated to support the v32b FPGA image. The source is also available on GitHub at https://github.com/davehein/p2gcc .
Dave, does this mean we have a passable C compiler for the Prop2, or one that can be made into a final compiler? Please forgive my ignorance on this subject. Thanks for taking interest in this!
I think p2gcc is a passable C compiler for the P2. However, it is not intended to be the final compiler for the P2. I'm hoping Parallax and people that are more experienced with GCC get involved at some point, and a compiler such as PropGCC can be developed for the P2. I think components of p2gcc can be used, but we need a team of people that understand GUIs, ELF files and other details to really make it work for everyone.
As I understand it, p2gcc depends on PropGCC for P1 to compile the C/C++ code. Given that, I'm not sure p2gcc is a viable alternative unless some effort gets put into PropGCC for P1. It isn't really possible to just let PropGCC for P1 run on autopilot. David Zemon's build server currently cannot build PropGCC because of issues that have crept in with later versions of the tools used to build it. The sources have to be continually updated for the more modern tools and the code should be updated to the later releases of the GCC and binutils sources as well. As far as I can tell, even PropGCC for P1 is currently broken so any tool like p2gcc that sits on top of it is also broken.
dgately, I think the problem you're having is due to a change I made in the stack setting in lib/prefix.spin2. I changed it from 32K to 104K when I was doing some tests with a VGA driver. Try changing "hub_ram_size = 104 *1024" to "hub_ram_size = 30 *1024". The DE0-Nano only has 32K of RAM, so a stack at 104K won't work. I think we need to use 30K instead of 32K because of the way the last 2K of ram is handled now.
You will also need to assemble prefix.spin2 to build a new object file. From the lib directory run "p2asm -o prefix.spin2".
dgately, I think the problem you're having is due to a change I made in the stack setting in lib/prefix.spin2. I changed it from 32K to 104K when I was doing some tests with a VGA driver. Try changing "hub_ram_size = 104 *1024" to "hub_ram_size = 30 *1024". The DE0-Nano only has 32K of RAM, so a stack at 104K won't work. I think we need to use 30K instead of 32K because of the way the last 2K of ram is handled now.
You will also need to assemble prefix.spin2 to build a new object file. From the lib directory run "p2asm -o prefix.spin2".
Thanks! Yes, set the hub ram size to 30*1024, re-assembled prefix.spin2 and "most" of the test samples respond. One thing to note is that p2gcc cannot find P2's with its current method on macOS. macOS does not use the Linux-type, iterative port naming, so p2gcc will never find a port that looks like "cu.usbserial-AE00BG4H", on macOS. So, I use loadp2 with "-p /dev/cu.usbserial-AE00BG4H..." after creating an output file from p2gcc, to load binaries to the P2.
Also, I'm getting text responses in a terminal for many of the samples, but 0 (zero) values from dry.c, prime.c, etc...
Not able to blink an LED yet, with the code from my post above. Not also able to get the blin.c sample to blink an LED either. Timing issue?
Could you try building "p2gcc -v test7.c test8.c", and then run the binary a.out. Please post the output from both the build and from running the executable. There may be a problem in the linker.
Could you try building "p2gcc -v test7.c test8.c", and then run the binary a.out. Please post the output from both the build and from running the executable. There may be a problem in the linker.
$p2gcc -v test7.c test8.c
propeller-elf-gcc -mcog -Os -m32bit-doubles -S test7.c
s2pasm -g -p/opt/parallax/lib/prefix.spin2 test7
p2asm -c -o test7.spin2
propeller-elf-gcc -mcog -Os -m32bit-doubles -S test8.c
s2pasm -g -p/opt/parallax/lib/prefix.spin2 test8
p2asm -c -o test8.spin2
p2link /opt/parallax/lib/prefix.o -v test7.o test8.o /opt/parallax/lib/stdio.a /opt/parallax/lib/stdlib.a /opt/parallax/lib/string.a
Found offset of 52 for symbol ___files of type R at location 5dc
Found offset of 52 for symbol ___files of type R at location 840
Found offset of 12 for symbol ___files of type W at location 1004
WARNING: Global variable ___files initialized in another object
Setting value of _heapaddrlast at location 5ce4 to 5f28
Setting value of _heapaddr at location 5ce8 to 5f28
$ls -latr
-rw-r--r-- 1 myUser staff 1281 Apr 24 20:23 test7.o
-rw-r--r-- 1 myUser staff 1964 Apr 24 20:23 test8.o
drwxr-xr-x 47 myUser staff 1504 Apr 24 20:23 .
-rw-r--r-- 1 myUser staff 24360 Apr 24 20:23 a.out
$p2load -p /dev/cu.usbserial-AE00BU4H -b 115200 -t -v /Users/myUser/source/p2gcc/a.out
Loading /Users/myUser/source/p2gcc/a.out - 24360 bytes
/Users/myUser/source/p2gcc/a.out loaded
[ Entering terminal mode. Press ESC to exit. ]
value1 = 0, &value1 = 0
value2 = 0, &value2 = 0
value3 = 0, &value3 = 0
__files = 0
&__files[1] = 0
sizeof(FILE) = 0
value1 = 0, &value1 = 0
value2 = 0, &value2 = 0
value3 = 0, &value3 = 0
value4 = 0, &value4 = 0
value5 = 0, &value5 = 0
__files = 0
&__files[1] = 0
BTW: I move copies of the lib & bin directories to /opt/parallax/lib & /opt/parallax/bin/ since those are my system's known paths to propeller binaries & libs.
David Zemon's build server currently cannot build PropGCC because of issues that have crept in with later versions of the tools used to build it. The sources have to be continually updated for the more modern tools and the code should be updated to the later releases of the GCC and binutils sources as well. As far as I can tell, even PropGCC for P1 is currently broken so any tool like p2gcc that sits on top of it is also broken.
As far as I can tell from the error, the build server just needs makeinfo installed, should not be a big problem. I'm compiling propgcc myself on an updated ubuntu server and I don't see any problem with it. Maybe I can help if you have issues.
David Zemon's build server currently cannot build PropGCC because of issues that have crept in with later versions of the tools used to build it. The sources have to be continually updated for the more modern tools and the code should be updated to the later releases of the GCC and binutils sources as well. As far as I can tell, even PropGCC for P1 is currently broken so any tool like p2gcc that sits on top of it is also broken.
As far as I can tell from the error, the build server just needs makeinfo installed, should not be a big problem. I'm compiling propgcc myself on an updated ubuntu server and I don't see any problem with it. Maybe I can help if you have issues.
This particular problem may be fairly easy to fix but it just points out that you can't just assume that something that was once working will continue working forever without some attention.
This particular problem may be fairly easy to fix but it just points out that you can't just assume that something that was once working will continue working forever without some attention.
Have you sent a note to David Zemon reporting the problem ?
Could you try building "p2gcc -v test7.c test8.c", and then run the binary a.out. Please post the output from both the build and from running the executable. There may be a problem in the linker.
$p2gcc -v test7.c test8.c
propeller-elf-gcc -mcog -Os -m32bit-doubles -S test7.c
s2pasm -g -p/opt/parallax/lib/prefix.spin2 test7
p2asm -c -o test7.spin2
propeller-elf-gcc -mcog -Os -m32bit-doubles -S test8.c
s2pasm -g -p/opt/parallax/lib/prefix.spin2 test8
p2asm -c -o test8.spin2
p2link /opt/parallax/lib/prefix.o -v test7.o test8.o /opt/parallax/lib/stdio.a /opt/parallax/lib/stdlib.a /opt/parallax/lib/string.a
Found offset of 52 for symbol ___files of type R at location 5dc
Found offset of 52 for symbol ___files of type R at location 840
Found offset of 12 for symbol ___files of type W at location 1004
WARNING: Global variable ___files initialized in another object
Setting value of _heapaddrlast at location 5ce4 to 5f28
Setting value of _heapaddr at location 5ce8 to 5f28
$ls -latr
-rw-r--r-- 1 myUser staff 1281 Apr 24 20:23 test7.o
-rw-r--r-- 1 myUser staff 1964 Apr 24 20:23 test8.o
drwxr-xr-x 47 myUser staff 1504 Apr 24 20:23 .
-rw-r--r-- 1 myUser staff 24360 Apr 24 20:23 a.out
$p2load -p /dev/cu.usbserial-AE00BU4H -b 115200 -t -v /Users/myUser/source/p2gcc/a.out
Loading /Users/myUser/source/p2gcc/a.out - 24360 bytes
/Users/myUser/source/p2gcc/a.out loaded
[ Entering terminal mode. Press ESC to exit. ]
value1 = 0, &value1 = 0
value2 = 0, &value2 = 0
value3 = 0, &value3 = 0
__files = 0
&__files[1] = 0
sizeof(FILE) = 0
value1 = 0, &value1 = 0
value2 = 0, &value2 = 0
value3 = 0, &value3 = 0
value4 = 0, &value4 = 0
value5 = 0, &value5 = 0
__files = 0
&__files[1] = 0
BTW: I move copies of the lib & bin directories to /opt/parallax/lib & /opt/parallax/bin/ since those are my system's known paths to propeller binaries & libs.
dgately
The linker prints match the ones I get. The binary file size matches as well. Can you post your a.out file so I can compare it to mine. You may have to put it in a zip file so that the forum software will allow you to attach it.
This particular problem may be fairly easy to fix but it just points out that you can't just assume that something that was once working will continue working forever without some attention.
Have you sent a note to David Zemon reporting the problem ?
Yes, he's aware
He's working on a Docker solution so that this doesn't happen again. The current problem is because I migrated servers and apparently forgot to install the old texinfo package.
dgately, I've attached a zipfile with the binary files for all the test programs with the stack at 30K. Can you try running some of these to see if they work for you.
Could you try building "p2gcc -v test7.c test8.c", and then run the binary a.out. Please post the output from both the build and from running the executable. There may be a problem in the linker.
The linker prints match the ones I get. The binary file size matches as well. Can you post your a.out file so I can compare it to mine. You may have to put it in a zip file so that the forum software will allow you to attach it.
dgately, I've attached a zipfile with the binary files for all the test programs with the stack at 30K. Can you try running some of these to see if they work for you.
I ran your a.out under spinsim, and it produces the same output as the test7.bin that I posted in the zipfile. I did a binary compare of a.out and test7.bin, and they are different. However, the differences are insignificant, and I suspect it's because we may be using different versions of propeller-elf-gcc. I ran p2dump on both files and did a diff. The results are as follows:
So there must be some problem with loadp2 loading your FPGA board. I'll look into it some more.
Yes, probably! I use:
$ propeller-elf-gcc --version
propeller-elf-gcc (propellergcc-alpha_v1_9_0_) 4.6.1
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Here's a dry.c build where I specify keeping all intermediate files (which I zipped-up and have attached):
$ p2gcc -v -k dry.c -o dry.myout
propeller-elf-gcc -mcog -Os -m32bit-doubles -S dry.c
s2pasm -g -p/opt/parallax/lib/prefix.spin2 dry
p2asm -c -o dry.spin2
p2link /opt/parallax/lib/prefix.o -v dry.o -o dry.myout /opt/parallax/lib/stdio.a /opt/parallax/lib/stdlib.a /opt/parallax/lib/string.a
Found offset of 12 for symbol ___files of type W at location 46e4
Setting value of _heapaddrlast at location 4abc to 4b80
Setting value of _heapaddr at location 4ac0 to 4b80
$ ls -al | grep dry
-rw-r--r-- 1 altergator staff 16704 Apr 25 10:11 dry.bin
-rwxr-xr-x 1 altergator staff 37387 Apr 23 17:26 dry.c
-rw-r--r-- 1 altergator staff 46795 Apr 25 10:11 dry.lst
-rw-r--r-- 1 altergator staff 19328 Apr 25 10:11 dry.myout
-rw-r--r-- 1 altergator staff 21919 Apr 25 10:11 dry.o
-rw-r--r-- 1 altergator staff 17113 Apr 25 10:11 dry.s
-rw-r--r-- 1 altergator staff 21215 Apr 25 10:11 dry.spin2
Hopefully, something might help in finding an issue. Are you testing with a DE0-Nano or BeMicro-A2? All I have are these single cog FPGAs, so could that be problematic for these test examples?
My version for propeller-elf-gcc is (propellergcc_v1_0_0_2408) 4.6.1, so it is different from yours. I ran both your dry binary file and mine, and the outputs are identical except for the cycle times. Here's a diff of the outputs.
Because some of the instructions are in a different order they will hit the hub at different times. This causes the different cycle times.
I'm using the DE2-115, but I verified in spinsim that only cog 0 is used. So it should work on a single cog FPGA. I'm wondering if the 2 Mbaud rate is causing problems in loadp2. Maybe you could try a lower baud rate by changing the define for LOADER_BAUD in p2load.c to a lower value.
dgately, please try running the two test programs that are in the attached zipfile. test1.c is a minimal program that just prints "Hello". test2.c checks an array of 5000 ints to see if there is any data corruption.
Comments
I now include the fft_bench program. It runs in 54 msec with the P2 set at 60 MHz.
I added support for spinsim to the p2gcc script file. A program can be build and run using the simulator by specifying the -s option. As an example, the hello program is run under spinsim by typing "p2gcc -s hello.c". spinsim is not included in the zipfile, and must be built separately.
p2gcc now requires that the bin directory be added to the PATH environment variable. Alternatively, the contents of the bin directory could be copied to an existing directory that is already included in the PATH. p2gcc also requires that the environment variable P2GCC_LIBDIR be specified and set to point to the p2gcc lib directory.
Another change I made was to enable the -c option in p2asm that makes the assembler case sensitive. This is required so that C variables such as temp and Temp can be distinguished from each other. PASM symbols, such as IF_C_OR_NZ are still handled without case sensitivity.
I renamed s2p to s2pasm. It turns out that there is already a Linux utility named s2p.
I renamed the dump utility to p2dump. I also added a disassembler option to p2dump. The disassembler can produce a spin2 file from a binary file that can be re-assembled back to a matching binary file. I've tested it with most of the sample programs that Chip includes with his FPGA updates.
dgately
Dave, does this mean we have a passable C compiler for the Prop2, or one that can be made into a final compiler? Please forgive my ignorance on this subject. Thanks for taking interest in this!
First, loadp2 needs a little help! You'll need to "#define MACOSX" in building loadp2 for a Mac to find a P2 on a PropPlug (a small serial open issue). A new build_macosx file that does the define before it execs compiles osint_linux.c, would fix this!
There's code in osint_linux.c that needs the MACOSX define. Here's an example:
Once the above is fixed, p2gcc seems to compile a binary, loadp2 appears to upload it to the FPGA (DE0-Nano), but it's not getting expected results on the FPGA. I'm running a simple blink.c type program, that should blink an LED on pins P0 or P1. Could be my code...
With the limit in cogs on the DE0-Nano, I'm not sure if any of the examples should work (dry.c, prime.c, etc...), as they do not return any text when run with "-t"...
dgately
You will also need to assemble prefix.spin2 to build a new object file. From the lib directory run "p2asm -o prefix.spin2".
Thanks! Yes, set the hub ram size to 30*1024, re-assembled prefix.spin2 and "most" of the test samples respond. One thing to note is that p2gcc cannot find P2's with its current method on macOS. macOS does not use the Linux-type, iterative port naming, so p2gcc will never find a port that looks like "cu.usbserial-AE00BG4H", on macOS. So, I use loadp2 with "-p /dev/cu.usbserial-AE00BG4H..." after creating an output file from p2gcc, to load binaries to the P2.
Also, I'm getting text responses in a terminal for many of the samples, but 0 (zero) values from dry.c, prime.c, etc...
Not able to blink an LED yet, with the code from my post above. Not also able to get the blin.c sample to blink an LED either. Timing issue?
Could all be something I'm missing, of course!
dgately
BTW: I move copies of the lib & bin directories to /opt/parallax/lib & /opt/parallax/bin/ since those are my system's known paths to propeller binaries & libs.
dgately
As far as I can tell from the error, the build server just needs makeinfo installed, should not be a big problem. I'm compiling propgcc myself on an updated ubuntu server and I don't see any problem with it. Maybe I can help if you have issues.
Have you sent a note to David Zemon reporting the problem ?
Yes, he's aware
He's working on a Docker solution so that this doesn't happen again. The current problem is because I migrated servers and apparently forgot to install the old texinfo package.
The a.out is attached as a zip!
dgately
Results attached
dgately
So there must be some problem with loadp2 loading your FPGA board. I'll look into it some more.
Yes, probably! I use: Here's a dry.c build where I specify keeping all intermediate files (which I zipped-up and have attached):
Hopefully, something might help in finding an issue. Are you testing with a DE0-Nano or BeMicro-A2? All I have are these single cog FPGAs, so could that be problematic for these test examples?
dgately
I'm using the DE2-115, but I verified in spinsim that only cog 0 is used. So it should work on a single cog FPGA. I'm wondering if the 2 Mbaud rate is causing problems in loadp2. Maybe you could try a lower baud rate by changing the define for LOADER_BAUD in p2load.c to a lower value.