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

Can't Wait for PropGCC on the P2?

12022242526

Comments

  • pilot0315 wrote: »
    SAMUEL,

    Which gui are you running this in?? I tried spin2gui but no math.h, library. Can you help?
    Hi pilot0315,

    I'm not using a GUI. I'm using p2gcc under Linux, which is more complete. You can create a Ubuntu/Kubuntu VM and follow the steps to install it via nix:
    http://forums.parallax.com/discussion/169589/p2-tooling-installation-via-nix-for-anylinux-any-linux-distribution/

    Then, just use the latest zip file containing my code, plug your P2 into the VM, and just run the script.

    Kind regards, Samuel Lourenço
  • @"Dave Hein"

    Do you know why the following sample code fail to execute on the P2 with p2gcc...? It compiles without warnings/errors.

    If I add an initialized character variable to your hello.c file, nothing gets printed out to the console after download, but if remove it it works fine. In comparison having uninitialized variables is okay.

    I came across this when trying to make the a.out file large for downloading tests by putting in a large character array and initializing it with {-1}. Nothing worked if I used initialized data, and I kept on shrinking it down until it was just a single byte and it still didn't work!
    Is this a known issue with memory allocation somewhere or some new bug perhaps?

    Roger.
    #include <stdio.h>
    #include <propeller.h>
    
    #define p2clkfreq (*(int *)0x14)
    
    char dummy1;  // works fine
    //char dummy2 = 'a'; // uncommenting this line fails
    
    void main(void)
    {
        int i;
    
        waitcnt(CNT+p2clkfreq);
        for (i = 1; i <= 10; i++)
        {
            waitcnt(CNT+p2clkfreq/2);
            printf("Hello World - %d\n", i);
        }
        printf("Goodbye\n");
    }
    
  • Dave HeinDave Hein Posts: 6,347
    edited 2019-02-06 20:25
    Roger, can you post your code for wait_drain? tcdrain requires a file descriptor, and I'm sure how to get that from a HANDLE.
  • Dave HeinDave Hein Posts: 6,347
    edited 2019-02-06 18:22
    Here's an open source startrek game that I found on the internet. I was curious whether p2gcc could compile and run it. I had to make a few minor changes, but I got it working. It took me a little longer to get it working than it should have. The game uses the least significant bits of the random number generator, which it turns out are not very random. I modified the value returned by the rand function by shifting it down by 5 bits. The program started working after I did that.

    The program uses the sqrt() function, so you have to include the math library. Use the following command:

    p2gcc -r -t startrek.c libm.a
  • jmgjmg Posts: 15,140
    edited 2019-02-06 18:42
    rogloh wrote: »
    By the way, if the application starts sending data right after boot without any delay, it will corrupt the P2 response checking code. I removed the sleep(1) from main in life.c and got this error now. I think only one byte should be requested from the serial port not 100 (looks like that value in the code was pasted from elsewhere where it reads in the version string). The garbage output below is from this change...
    When I changed it to read only one byte it fixes the problem.
            num = rx_timeout((uint8_t *)buffer, 1, 100);  // change to 100ms timeout  --- *** NEW
    

    Well spotted - Yes, that makes sense, P2 only sends one byte - '.' (ok) or '!' (error)

    Any wait_drain is going to pause until the SW buffers empty, but that does not include any HW buffers in the chain, which is why some timeout is still needed.
    The FT231X has 512 bytes, and it seems MAC HW may have additional HW buffers. Other Serial UARTS can have 1k or 4k buffers.
    Examples at 115200 (chosen as the likely slowest-common-denominator users might test with - is there any point supporting lower speeds ? )
    512*10/115200 = 0.044s
    1024*10/115200 = 0.088s
    4096*10/115200 = 0.355s

    So 100ms is ok for a total buffer of 1024, but probably light for a 4k buffer device, which higher performance users may be using. (FT2232H)

    You could adapt the timeout wait to Baud-speed, but actual timeout is a rare occurrence, and has no usual-use impact if set larger, as the expected byte comes back quickly.

    Ideally, code should report any timeout-exit to the user, as it means something is awry (as here).
  • Dave Hein: Latest loadp2 (version 0.012) displays a failure message when "-SINGLE" option is used on my macOS system with -b & -l baud rates set to 115200 (or any optioned baudrates). And, if the -t option is used, there's no terminal activity as the loader appears to just quit with the error display.

    Odd thing is that the program actually gets uploaded and runs (without terminal response, of course)
    $ loadp2
    loadp2 - a loader for the propeller 2 - version 0.012, 2019-02-03
    
    $ loadp2 -p /dev/cu.usbserial-P2EEI8V -b 115200 -l 115200 -t -SINGLE draw_char_to_LED_Matrix.binary
    draw_char_to_LED_Matrix.binary failed to load
    Error response was ""
    $
    

    "-CHIP" works!
    $ loadp -p /dev/cu.usbserial-P2EEI8V -b 115200 -l 115200 -t -CHIP draw_char_to_LED_Matrix.binary
    ( Entering terminal mode.  Press Ctrl-] to exit. )
    Starting...
    

    dgately
  • Dave HeinDave Hein Posts: 6,347
    edited 2019-02-06 20:21
    I added the checksum logic to the -SINGLE mode, and it appears that I'm not waiting long enough before requesting the status. Once I figure out how to convert a HANDLE to a file descriptor I will use the tcdrain function, and that problem should be resolved.
  • roglohrogloh Posts: 5,119
    edited 2019-02-06 20:57
    Dave Hein wrote: »
    Roger, can you post your code for wait_drain? tcdrain requires a file descriptor, and I'm sure how to get that from a HANDLE.

    From what I can tell your hSerial is a file descriptor (at least in osint_linux.c) so this code worked for me. You might want to tidy up with a specific failure type for your osint.h file if required for other platforms etc. I ignored the return value anyway in loadp2.c.
    int wait_drain()
    {
        return tcdrain(hSerial);
    }
    
  • jmgjmg Posts: 15,140
    Dave Hein wrote: »
    I added the checksum logic to the -SINGLE mode, and it appears that I'm not waiting long enough before requesting the status. Once I figure out how to convert a HANDLE to a file descriptor I will use the tcdrain function, and that problem should be resolved.

    As an interim, you could try this ?
    num = rx_timeout((uint8_t *)buffer, 1, 450); // 1Char echo, 450ms MAX wait

    That's rogloh's fix for a 1 char echo, and the 450ms is a maximum wait, large enough to allow users testing with FT2232H large HW buffers
    Some simple time captures could check how long that Tx-Empty then RX wait actually is ?
  • Here's my hacked up loadp2 code changes to osint_linux.c and loadp2.c as it stands for anyone who wants to play with it on Macs. It obviously needs further cleanup using correct osint.h declaration pathway before being ready for any integration within a release quality loadp2. Also it still contains a couple of compile type warnings etc as I've been experimenting with port auto-detection and I seem to have that working on the Mac though that will break the other platforms right now that searched for COM1/COM2/COM3 etc.

    Both SINGLE and CHIP modes now work for me with lots of baud rates tested below 2Mbps. If you use -SINGLE then also passing -b 33100 seems to work for the serial port baud rate with the RC oscillator speed of ~23MHz. This could vary on other platforms though. 33100 ~ 23/80 * 115200

    Cheers,
    Roger.
  • jmg wrote: »
    Any wait_drain is going to pause until the SW buffers empty, but that does not include any HW buffers in the chain, which is why some timeout is still needed.
    The FT231X has 512 bytes, and it seems MAC HW may have additional HW buffers. Other Serial UARTS can have 1k or 4k buffers.
    Examples at 115200 (chosen as the likely slowest-common-denominator users might test with - is there any point supporting lower speeds ? )
    512*10/115200 = 0.044s
    1024*10/115200 = 0.088s
    4096*10/115200 = 0.355s

    So 100ms is ok for a total buffer of 1024, but probably light for a 4k buffer device, which higher performance users may be using. (FT2232H)

    You could adapt the timeout wait to Baud-speed, but actual timeout is a rare occurrence, and has no usual-use impact if set larger, as the expected byte comes back quickly.

    Ideally, code should report any timeout-exit to the user, as it means something is awry (as here).

    Very good points. The HW buffer also introduces its own delay which should be accounted for if high reliability is desired across different serial ports.
  • Boy am I glad to be out of the loader business! Getting these things to work reliably on lots of different systems is a pain. Thanks for all of your work on this!!
  • Dave Hein wrote: »
    Here's an open source startrek game that I found on the internet. I was curious whether p2gcc could compile and run it. I had to make a few minor changes, but I got it working. It took me a little longer to get it working than it should have. The game uses the least significant bits of the random number generator, which it turns out are not very random. I modified the value returned by the rand function by shifting it down by 5 bits. The program started working after I did that.

    Which random number generator is being used here?
  • I'm using the GNU C routine, which has some known periodicities. At some point I'll add a library function that uses the P2 random number generator. However, there are times when a repeatable generator is useful for debugging purposes.
  • David Betz wrote: »
    Boy am I glad to be out of the loader business! Getting these things to work reliably on lots of different systems is a pain. Thanks for all of your work on this!!

    It is a pain, but the efforts now will hopefully pay off. As a developer myself I totally despise using flaky tools.

    Hopefully over time we can add in some way to download using wifi-serial bridges like the work you did for P1 with ESP8266. I think it might be a little simpler with the P2 than P1 with any luck.
  • I checked loadp2 version 0.013 into GitHub. I added the wait_drain function that calls tcdrain for Linux and the Mac, and just calls msleep(100) for Windows. I tested the Windows version, and it works fine down to 57600. At lower baud rates the read after the "?" times out.

    Roger, thanks for your help on this. I'll look at the code you posted, and incorporate some of those changes also once they have been tested out by others.
  • evanhevanh Posts: 15,091
    edited 2019-02-06 22:57
    Dave,
    The XORO32 instruction is also repeatable, ie: only iterates when called. It has a user state variable that can be seeded with srand(). It could directly backend rand(). Not that I'd know how.

  • evanh, I'll look into using XORO32. Thanks.
  • roglohrogloh Posts: 5,119
    edited 2019-02-07 01:06
    Dave Hein wrote: »
    I checked loadp2 version 0.013 into GitHub. I added the wait_drain function that calls tcdrain for Linux and the Mac, and just calls msleep(100) for Windows. I tested the Windows version, and it works fine down to 57600. At lower baud rates the read after the "?" times out.

    Roger, thanks for your help on this. I'll look at the code you posted, and incorporate some of those changes also once they have been tested out by others.

    No problem, sounds good Dave. With any luck there should be some type of Windows API that can emulate tcdrain(). FlushFileBuffers?

    If you get a chance I'd be keen to understand why the two variants of the trivial hello.c code example I mention above with this "dummy2" assigned static variable first commented out and then enabled both work and don't work respectively. I've added the two a.out files for both cases. "good.out" is with dummy2 commented out, and "bad.out" is with this line enabled. When I compared the p2dumps of each there are some address differences in the file but I'm not really sure where it goes bad. Perhaps this is a linker issue and the assigned dummy2 variable address is somehow conflicting with the recent clock/baud rate changes, though I don't see the P2 TX LED flash every half second on the board so it's more than baud rate. The bad version when loaded checksums fine in SINGLE mode so I know it is making it into the board. It's strange and I'm wondering if it is a bug or limitation of the p2gcc tools.

    Cheers,
    Roger.


  • There's a bug in one of the tools that doesn't like unaligned data. If you declare a char or short value it will cause the code to be unaligned. In theory the P2 should be able to handle it, but something in the linker or one of the other tools doesn't like it. I generally try to force 32-bit alignment, but 1-3 char variables or a short will cause it to be mis-aligned. The work-around is to declare dummy char's or short's so get it back into 32-bit alignment.
  • Will try that - thanks!
  • Dave,
    I have limited experience using the Windows command prompt. I tried to run your startrek program using the P2gcc006 and got errors. I put "startrek.c" into the p2gcc006 folder and ran p2gcc. I got the following:
    Microsoft Windows [Version 6.1.7601]
    Copyright (c) 2009 Microsoft Corporation.  All rights reserved.
    
    C:\Users\tandj>cd C:\Users\tandj\Documents\robot\P2ES\p2gcc006\p2gcc006
    
    C:\Users\tandj\Documents\robot\P2ES\p2gcc006\p2gcc006>p2gcc -r -t startrek.c libm.a
    's2pasm' is not recognized as an internal or external command,
    operable program or batch file.
    'p2asm' is not recognized as an internal or external command,
    operable program or batch file.
    invalid extension in libm.a
    
    C:\Users\tandj\Documents\robot\P2ES\p2gcc006\p2gcc006>
    
    Not sure what I have done wrong, and would appreciate your assistance.
    Thanks
    Tom
  • @twm47099 ,

    You need to compile p2gcc before you can use it. There is a build process that requires mingw system.

    I tried to compile it as well and got a bunch of errors about missing functions: __floatsidf, and others...

    Mike
  • Compiling p2gcc isn't hard, but if you don't have a compiler installed yet on your system, it will be much easier to download pre-built binaries. I host them here: http://david.zemon.name:8111/project.html?projectId=P2gcc&guest=1

    Note:
    My builds do lag Dave Hein's source code by a bit (anywhere from a couple hours to a day or two, depending on how quickly I notice his changes) because the CI server is building a fork of his code, not actually his code. If Dave likes the changes I made to the build system and merges my PR, I can go back to building his repo directly.
  • David,
    Thanks, I'll give it a try.
    Tom
  • Dave HeinDave Hein Posts: 6,347
    edited 2019-02-08 20:23
    twm47099, the p2gcc006 zipfile contains a bin directory with Windows executables in it. You need to add this bin directory to your path. On the command line you would type:

    set path=%path%;C:\Users\tandj\Documents\robot\P2ES\p2gcc006\p2gcc006\bin

    You need to do this every time you start the command prompt window. You could put this in a batch file, and run that each time you start a new window. Or you could add it to your registry, but I wouldn't suggest that if your not experienced in working with the registry.

    I haven't tested the Windows build lately, so I tried it just now and found that you can't specify a library. I have an updated p2gcc.bat in the attached zipfile that fixes that. I also found that the linker fails for the startrek program in Windows. I need to look into that. I have included the startrek.bin binary file that you can load by typing:

    loadp2 -t startrek.bin

    Finally, I included at setpath.bat file that you can use to set your path.

  • Dave Hein wrote: »
    I haven't tested the Windows build lately, so I tried it just now and found that you can't specify a library. I have an updated p2gcc.bat in the attached zipfile that fixes that.

    The "p2gcc" file that executes on Linux & macOS, needs the same change to allow "-L" & "-I" to specify Library & Includes locations...

    Thanks,
    dgately

  • The change I made to p2gcc.bat for Windows was to allow specifying files with a .a extension. So this allowed the following:

    p2gcc -r -t startrek.c libm.a

    Unfortunately, there is an issue with p2asm or p2link in the Windows build that causes a problem with linking the startrek object.

    The p2gcc bash script that is used with Linux, macOS & Cygwin already had the .a extension fix. I just forgot to put it in p2gcc.bat also.

    I have thought about adding the -L and -l (lower case L) options used by the linker, and the -D and -I (upper case i) options used by the compiler. It would also be useful to add the -f and -b options for the loader. I just haven't gotten around to it.
  • I added the -D, -L, -I (upper case i), -b and -f options to p2gcc and p2gcc.bat. The -D and -I options are passed to the compiler, and specify a compile-time symbol and an include directory. The -L option specifies a library directory to the linker. The -b and -f options specify the user baud rate and the clock frequency.
  • Would someone please tell me why I get this error. I am attempting to port over the simple ping demo from spin to spin2 and I get the following error:



    "C:/Users/mm/Desktop/spin2gui 1.3.5/spin2gui/spin2gui/bin/fastspin" -2 -l -O1 -L "./lib" "C:/Users/mm/Desktop/spin2works/ping test .spin2"
    Propeller Spin/PASM Compiler 'FastSpin' (c) 2011-2019 Total Spectrum Software Inc.
    Version 3.9.16 Compiled on: Jan 29 2019
    child killed: segmentation violation

    Thanks
Sign In or Register to comment.