Boards have only been in peoples hands for a few days, so the tools need to be updated. That's the short of it. I don't think there is much intent to put a lot of time into updating PNut though, based on one other question that I asked.
In the end there will need to be some kind of compiler declarations at the top for C and SPIN to set the speeds with the right hubset values. For example Peter's P2D2 boards use a different oscillator speed than the P2-ES, so there are already at least 2 sets of values needed to hit different speeds. Code outputting VGA needs special PLL settings.
Here's a new update to p2gcc. It contains many fixes made since May 20. It also supports loading to both the FPGA and the P2 silicon. Loading to the P2 silicon from Linux still does not work at this point. The source code is also available from GitHub at https://github.com/davehein/p2gcc .
Dave, thanks for the quick fix. I did however encounter a problem where s2pasm was being called with -g and -t arguments which appear invalid. I modified the p2gcc.bat file to remove those and things worked fine afterwards. The s2pasm source seems to confirm that -g and -t are invalid. The changes made were around line 164-165 in p2gcc.bat as below.
:runs2pasm
rem if %verbose% equ 1 echo %s2pasmstr% -g -t -p%P2GCC_LIBDIR%\prefix.spin2 %name%
rem %s2pasmstr% -g -t -p%P2GCC_LIBDIR%\prefix.spin2 %name%
if %verbose% equ 1 echo %s2pasmstr% -p%P2GCC_LIBDIR%\prefix.spin2 %name%
%s2pasmstr% -p%P2GCC_LIBDIR%\prefix.spin2 %name%
if %ERRORLEVEL% neq 0 goto :eof
exit /b
Thanks for finding that. I removed the -g and -t options from s2pasm back in June, and I changed p2gcc, but I neglected to change p2gcc.bat. I'll go ahead and check that fix into GitHub.
I'm trying to figure out why loadp2 doesn't work with the P2 Eval board with Linux. I found that if I comment out the line "chk("tcsetattr", tcsetattr(hSerial, TCSANOW, &sparm));" in osint_linux.c the program seems to run. At least the LEDs at the USB connector indicate that the program is sending characters. So this statement is doing something to the board -- maybe resetting it. Anybody have any ideas on how to work around this?
loadp2 works fine with the FPGA. There's just something about the P2 Eval board that's not working.
I don't want to send you on a wild goose chase , as I'm not familiar with the inner workings of the kernel drivers, but they look like similar symptoms.
FWIW, @ozpropdev 's python loader https://forums.parallax.com/discussion/168850/python-p2-loader/p1 seems to work for me, as well. His code appears to explicitly keep DTR low before the open() line (or explicitly tells the serial port driver to leave DTR alone? Not sure: sp.dtr = False) . This jives with what those in the above threads mention...
I don't get a "tcsetattr failed" message. It's just that commenting out the tcsetattr allows the program to run. I should point out that the problem happens with the 2 stage loader. I can type "loadp2 -t -SINGLE a.out", and the program runs. The -SINGLE option tells loadp2 to use a 1 stage loader. However, if I type "loadp2 -t -CHIP a.out", or "loadp2 -t a.out" which will automatically run in the CHIP mode the program fails. In this case loadp2 uses the 2 stage loader tailored for the P2 silicon.
It sounds like Peter's solution would work, but I would hate to have to modify the board and manually hit reset each time I load. I'm guessing the difference in the reset hardware between the FPGA and the P2 Eval board is causing the problem. Is there some way I can configure the P2 Eval board to reset the same way the FPGA does?
Both the CHIP and SINGLE modes seem to work for me (KUbuntu 18.10). Were there only certain binaries that didn't work for you using -CHIP? (Or am I misunderstanding - was it before the line in the loader source was removed that -CHIP didn't work?)
That's encouraging that it's working for you. Yes, before I removed the line in loadp2 the CHIP mode would not run. Removing the line allowed the CHIP mode to run. However, I need that line of code so that I can run the terminal emulator.
Ha! That explains why the P123 board always resets when I exit loadp2. It wasn't an issue for diagnostics where I always left the -t terminal running but the moment I press ESC the Prop2 resets.
It's the same issue but just shifted to the other phase of the DTR cycle.
Thanks Dave for the loadp2 updates. I made a few tweaks to get it working on Linux, as well as adding a -k flag for spin2gui. The code is a bit ugly, due to some flailing around (for example I don't think the code to immediately clear DTR after the tcsetattr actually works). The biggest change is that if the loader baud and user baud are the same we skip the second baud setting (which keeps DTR from toggling) and on exit we do a "hangup" by setting the baud rate to 0 (which again keeps DTR from resetting the board).
Thanks Eric. I tried your code on my Ubuntu system, and it didn't work. I copied the latest versions of loadp2.c and osint_linux.c that you have on your GitHub site. However, I may not have done something correctly when I compiled it with the rest of my code.
I did try the idea of forcing the loader_baud to be the same as the user_baud, and that change alone did allow the loader to work correctly. So I'll probably just incorporate that part of the change for now.
My result on macOS with the latest loadp2 code, 'almost' works... Testing with several "supported" baudrates, I get the following (the first example without a baudrate given):
It appears to be sending back data (I replaced "Hello World!" with "abcdefghijklmnopqrstuvwxyz" in my example), but at a baud that is undeterminable. Any ideas?
I just checked in the fix for Linux, and since MacOS uses the same code I'm hoping it will work there as well. Get the latest version of the loadp2_src directory from GitHub and try that. The fix forces the loader baud rate to be the same as the user baud rate. This prevents baud rate changes from occurring, which seems to make Linux happy. Hopefully it will work on the Mac also.
I just checked in the fix for Linux, and since MacOS uses the same code I'm hoping it will work there as well. Get the latest version of the loadp2_src directory from GitHub and try that. The fix forces the loader baud rate to be the same as the user baud rate. This prevents baud rate changes from occurring, which seems to make Linux happy. Hopefully it will work on the Mac also.
IT'S WORKING!!!
david@balrog:~/reusable/Documents/Programming/Propeller2/HelloP2GCC$ make run-hello
--- COMPILING hello.c ---
bash p2gcc -v -o hello.bin hello.c
propeller-elf-gcc -mcog -Os -m32bit-doubles -S hello.c
s2pasm -p/home/david/reusable/software/p2gcc/lib/prefix.spin2 hello
p2asm -c -o hello.spin2
p2link /home/david/reusable/software/p2gcc/lib/prefix.o -v -o hello.bin hello.o /home/david/reusable/software/p2gcc/lib/stdio.a /home/david/reusable/software/p2gcc/lib/stdlib.a /home/david/reusable/software/p2gcc/lib/string.a
Found offset of 12 for symbol ___files of type 04 at location b14
--- LOADING hello.bin ---
loadp2 -v -t -p /dev/ttyUSB0 -m 010c1f08 hello.bin
Setting user_baud to 115200
Set loader_baud to 115200
Loading hello.bin - 2548 bytes
hello.bin loaded
[ Entering terminal mode. Press ESC to exit. ]
Hello World - 1
Hello World - 2
Hello World - 3
Hello World - 4
Hello World - 5
Hello World - 6
Hello World - 7
Hello World - 8
Hello World - 9
Hello World - 10
Goodbye
I just checked in the fix for Linux, and since MacOS uses the same code I'm hoping it will work there as well. Get the latest version of the loadp2_src directory from GitHub and try that. The fix forces the loader baud rate to be the same as the user baud rate. This prevents baud rate changes from occurring, which seems to make Linux happy. Hopefully it will work on the Mac also.
IT'S WORKING!!!
david@balrog:~/reusable/Documents/Programming/Propeller2/HelloP2GCC$ make run-hello
--- COMPILING hello.c ---
bash p2gcc -v -o hello.bin hello.c
propeller-elf-gcc -mcog -Os -m32bit-doubles -S hello.c
s2pasm -p/home/david/reusable/software/p2gcc/lib/prefix.spin2 hello
p2asm -c -o hello.spin2
p2link /home/david/reusable/software/p2gcc/lib/prefix.o -v -o hello.bin hello.o /home/david/reusable/software/p2gcc/lib/stdio.a /home/david/reusable/software/p2gcc/lib/stdlib.a /home/david/reusable/software/p2gcc/lib/string.a
Found offset of 12 for symbol ___files of type 04 at location b14
--- LOADING hello.bin ---
loadp2 -v -t -p /dev/ttyUSB0 -m 010c1f08 hello.bin
Setting user_baud to 115200
Set loader_baud to 115200
Loading hello.bin - 2548 bytes
hello.bin loaded
[ Entering terminal mode. Press ESC to exit. ]
Hello World - 1
Hello World - 2
Hello World - 3
Hello World - 4
Hello World - 5
Hello World - 6
Hello World - 7
Hello World - 8
Hello World - 9
Hello World - 10
Goodbye
Now the fun can begin thanks!
Fabulous to hear that its working !
Having only discovered the Propeller recently, i do not have propellor-elf-gcc installed, but i
would like to try the example C programs that come with p2gcc. I did look on these forums
but could not find any post as to how to install it.
I have cloned Dave Hein's p2gcc githib repo, built it and hacked various bits.
I saw your thread "Building PropGCC with Docker", but was hoping to not have to do this currently.
I dont want to build the Compiler from source at this stage.
Is there any place to find just binaries (and library source) to install on ubuntu 18.04 64 bit. ?
I am familiar with linux sysadmin, so i do not need any handholding or extra detailed instructions
for linux newbies.
I am using the PropGCC that comes with SimpleIDE. Just install SimpleIDE, and add the executable directory to your PATH. On my Linux machine the PropGCC executables are in /opt/parallax/bin.
I am using the PropGCC that comes with SimpleIDE. Just install SimpleIDE, and add the executable directory to your PATH. On my Linux machine the PropGCC executables are in /opt/parallax/bin.
Thanks for your response.
There are no binary images for the linux version of SimpleIDE. ProgGCC has to be built from source.
I run Ubuntu 18.04 and have gcc 7.3 installed. PropGCC WONT compile with gcc 7.3
Maybe it would be quicker for me to run up an ancient version of Ubuntu on new machine.
Any idea what version of Ubuntu or gcc can compile PropGCC without errors ?
Dave can you type "cat /etc/lsb-release" on your Linux machine if its Ubuntu ?
If not any chance you can tell me what you use for linux, assuming that PropGCC
builds without errors.
If i install the same thing you are using i should be able to build it with minimal time.
I'm trying to port the PropGCC full printf routine, and I need ___umoddi3, ___udivdi3 and __CMPSWAPSI. Does anyone know where the source for those routines are located in the PropGCC source tree?
Comments
In the end there will need to be some kind of compiler declarations at the top for C and SPIN to set the speeds with the right hubset values. For example Peter's P2D2 boards use a different oscillator speed than the P2-ES, so there are already at least 2 sets of values needed to hit different speeds. Code outputting VGA needs special PLL settings.
loadp2 works fine with the FPGA. There's just something about the P2 Eval board that's not working.
I scoped with my LA when I posted that and indeed I could see solid communication from the PC.
I've found a few discussions about tcsetattr from the Arduino crowd:
https://github.com/pyserial/pyserial/issues/124
https://unix.stackexchange.com/questions/446088/how-to-prevent-dtr-on-open-for-cdc-acm
I don't want to send you on a wild goose chase
FWIW, @ozpropdev 's python loader https://forums.parallax.com/discussion/168850/python-p2-loader/p1 seems to work for me, as well. His code appears to explicitly keep DTR low before the open() line (or explicitly tells the serial port driver to leave DTR alone? Not sure: sp.dtr = False) . This jives with what those in the above threads mention...
Going by what Peter has found, I'm guessing the Prop2 is resetting during first part of download. So doesn't receive the whole program.
That lines up with https://unix.stackexchange.com/questions/446088/how-to-prevent-dtr-on-open-for-cdc-acm
If DTR changes on open port, and send starts too soon after, the P2 will be still reacting to the dtr change.
Maybe a modest delay after open, before send, is enough to allow any reset recovery ?
I don't get a "tcsetattr failed" message. It's just that commenting out the tcsetattr allows the program to run. I should point out that the problem happens with the 2 stage loader. I can type "loadp2 -t -SINGLE a.out", and the program runs. The -SINGLE option tells loadp2 to use a 1 stage loader. However, if I type "loadp2 -t -CHIP a.out", or "loadp2 -t a.out" which will automatically run in the CHIP mode the program fails. In this case loadp2 uses the 2 stage loader tailored for the P2 silicon.
It sounds like Peter's solution would work, but I would hate to have to modify the board and manually hit reset each time I load. I'm guessing the difference in the reset hardware between the FPGA and the P2 Eval board is causing the problem. Is there some way I can configure the P2 Eval board to reset the same way the FPGA does?
The problem seems to be that there is no transistor reset like on a propplug so it needs to be inverted?
Not sure how. look at his last posts
Mike
Both the CHIP and SINGLE modes seem to work for me (KUbuntu 18.10). Were there only certain binaries that didn't work for you using -CHIP? (Or am I misunderstanding - was it before the line in the loader source was removed that -CHIP didn't work?)
It's the same issue but just shifted to the other phase of the DTR cycle.
I did try the idea of forcing the loader_baud to be the same as the user_baud, and that change alone did allow the loader to work correctly. So I'll probably just incorporate that part of the change for now.
My result on macOS with the latest loadp2 code, 'almost' works... Testing with several "supported" baudrates, I get the following (the first example without a baudrate given):
$ loadp2 -p /dev/cu.usbserial-P2EEI8V -t hello.bin -SINGLE -m 010c1f08 Unsupported baudrate 2000000. Use 230400, 115200, 57600, 38400, 19200, or 9600 $ loadp2 -p /dev/cu.usbserial-P2EEI8V -t hello.bin -SINGLE -m 010c1f08 -b 38400 tcsetattr failed [ Entering terminal mode. Press ESC to exit. ] ?????????????????????????? ?????????????????????????? ?????????????????????????? ?????????????????????????? ?????????????????????????? ?????????????????????????? ?????????????????????????? $ loadp2 -p /dev/cu.usbserial-P2EEI8V -t hello.bin -SINGLE -m 010c1f08 -b 19200 tcsetattr failed [ Entering terminal mode. Press ESC to exit. ] 2??D?????:?>???Vt???W??ڵx?|:??U???7t???ո>???Vt???W??ڵx?| $ loadp2 -p /dev/cu.usbserial-P2EEI8V -t hello.bin -b 115200 -SINGLE tcsetattr failed [ Entering terminal mode. Press ESC to exit. ] ?|??|??|??|??|?<x???|??|p?|??|??|??<?<?|??|??|??|??|?<x???|??|p?|??|??|??<?<??|??|??|??|??|?<x???|??|p?|??|??|??<?<??|??|??|??|??|?<x???|??|p?|??|??|??<?<??|??|??|??|??|?<x???|??|p?|??|??|??<?<?|??|??|??|??|?<x???|??|p?|??|??|??<?<?|??|??|??|??|It appears to be sending back data (I replaced "Hello World!" with "abcdefghijklmnopqrstuvwxyz" in my example), but at a baud that is undeterminable. Any ideas?
dgately
IT'S WORKING!!!
Now the fun can begin
Fabulous to hear that its working !
Having only discovered the Propeller recently, i do not have propellor-elf-gcc installed, but i
would like to try the example C programs that come with p2gcc. I did look on these forums
but could not find any post as to how to install it.
I have cloned Dave Hein's p2gcc githib repo, built it and hacked various bits.
I saw your thread "Building PropGCC with Docker", but was hoping to not have to do this currently.
I dont want to build the Compiler from source at this stage.
Is there any place to find just binaries (and library source) to install on ubuntu 18.04 64 bit. ?
I am familiar with linux sysadmin, so i do not need any handholding or extra detailed instructions
for linux newbies.
Thanks in advance.
Thanks for your response.
There are no binary images for the linux version of SimpleIDE. ProgGCC has to be built from source.
I run Ubuntu 18.04 and have gcc 7.3 installed. PropGCC WONT compile with gcc 7.3
Maybe it would be quicker for me to run up an ancient version of Ubuntu on new machine.
Any idea what version of Ubuntu or gcc can compile PropGCC without errors ?
Dave can you type "cat /etc/lsb-release" on your Linux machine if its Ubuntu ?
If not any chance you can tell me what you use for linux, assuming that PropGCC
builds without errors.
If i install the same thing you are using i should be able to build it with minimal time.
Details in this thread: https://forums.parallax.com/discussion/169383/unofficial-parallax-continuous-integration-build-server
Thanks to you both.
Installed and working now.
___umoddi3 and ___udivdi3 are in libgcc/libgcc2.c, under the appropriate #ifdef sections