Shop OBEX P1 Docs P2 Docs Learn Events
Can't Wait for PropGCC on the P2? - Page 11 — Parallax Forums

Can't Wait for PropGCC on the P2?

18911131426

Comments

  • 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.
  • Dave HeinDave Hein Posts: 6,347
    edited 2018-12-30 11:23
    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.
  • Dave HeinDave Hein Posts: 6,347
    edited 2018-12-30 20:54
    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.
  • evanhevanh Posts: 15,126
    You might want to double check there Dave. DavidZ has indicated that downloading appears to happen each time - https://forums.parallax.com/discussion/comment/1459375/#Comment_1459375 And there's no sign of any "tcsetattr failed" messages in his posts.
  • evanh wrote: »
    You might want to double check there Dave. DavidZ has indicated that downloading appears to happen each time - https://forums.parallax.com/discussion/comment/1459375/#Comment_1459375 And there's no sign of any "tcsetattr failed" messages in his posts.

    I scoped with my LA when I posted that and indeed I could see solid communication from the PC.
  • evanhevanh Posts: 15,126
    edited 2018-12-30 21:59
    And looks like PeterJ has found out a detail - https://forums.parallax.com/discussion/comment/1459702/#Comment_1459702
    ... so I disconnected the cap from the DTR and simply hit the reset button just before I download new code. Works perfectly!
  • With that line removed, any image I've thrown at it seems to run fine (Fozzie on a pin, Cordic Crickets, etc), with or without terminal mode (-t).
    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 :smile:, 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...
  • evanhevanh Posts: 15,126
    DavidZemon wrote: »
    I scoped with my LA when I posted that and indeed I could see solid communication from the PC.

    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.

  • jmgjmg Posts: 15,140
    evanh wrote: »
    DavidZemon wrote: »
    I scoped with my LA when I posted that and indeed I could see solid communication from the PC.

    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 ?
  • evanh wrote: »
    You might want to double check there Dave. DavidZ has indicated that downloading appears to happen each time - https://forums.parallax.com/discussion/comment/1459375/#Comment_1459375 And there's no sign of any "tcsetattr failed" messages in his posts.

    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?
  • @Tubular did this with some FTDI config utility to invert RTS on his EVAL.

    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

  • @"Dave Hein" ,

    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.
  • evanhevanh Posts: 15,126
    Here's the two circuits. Yep, the older one has the inverting transistor while the newer one doesn't.
    1589 x 819 - 30K
    1678 x 916 - 41K
  • evanhevanh Posts: 15,126
    edited 2018-12-31 01:11
    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.
  • Dave,

    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
  • 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.
  • Dave Hein wrote: »
    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 :D thanks!
  • DavidZemon wrote: »
    Dave Hein wrote: »
    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 :D 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.

    Thanks in advance.
  • 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.
  • Dave Hein wrote: »
    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.
  • Dave HeinDave Hein Posts: 6,347
    edited 2019-01-01 14:05
    On this page -- https://www.parallax.com/downloads/propeller-p8x32a-software -- the fourth item is SimpleIDE for Linux. I believe that's the one I installed on my Ubuntu system.
  • Dave Hein and DavidZemon.

    Thanks to you both.
    Installed and working now.
  • 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?
  • CMPSWAPSI is in libgcc/config/propeller/crt0_lmm.s (and the other crt0 startup files).

    ___umoddi3 and ___udivdi3 are in libgcc/libgcc2.c, under the appropriate #ifdef sections
Sign In or Register to comment.