Can't Wait for PropGCC on the P2?

1171820222326

Comments

  • Dave Hein wrote: »
    rogloh, can you try running loadp2 without any parameters and look at what it prints out. It should show version 0.010 and a default loader baud rate of 921600. Is that what you see?

    Can you try running the following commands to see which ones work, and which ones don't.

    loadp2 a.out
    loadp2 -t a.out
    loadp2 -t -l 921600 a.out
    loadp2 -t -l 921600 a.out -SINGLE
    loadp2 -t -l 921600 a.out -CHIP
    loadp2 -t a.out -SINGLE
    loadp2 -t a.out -CHIP

    No problem Dave... firstly the latest version of loadp2 seems to be 0.011.
    RLs-MacBook-Pro:p2gcc roger$ loadp2
    loadp2 - a loader for the propeller 2 - version 0.011, 2019-01-29
    usage: loadp2
             [ -p port ]               serial port
             [ -b baud ]               user baud rate (default is 115200)
             [ -l baud ]               loader baud rate (default is 921600)
             [ -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
             [ -k ]                    wait for user input before exit
             [ -? ]                    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
             [ -PATCH ]                patch in clock frequency and serial parms
             file                      file to load
    

    Here's the output for the remaining commands... I assume it is meant to auto-detect the P2, but it doesn't work unless I manually specify the USB port it uses.
    RLs-MacBook-Pro:p2gcc roger$ loadp2 -t a.out
    Could not find a P2
    RLs-MacBook-Pro:p2gcc roger$ loadp2 -t -l 921600 a.out
    Could not find a P2
    RLs-MacBook-Pro:p2gcc roger$ loadp2 -t -l 921600 a.out -SINGLE
    Could not find a P2
    RLs-MacBook-Pro:p2gcc roger$ loadp2 -t -l 921600 a.out -CHIP
    Could not find a P2
    RLs-MacBook-Pro:p2gcc roger$ loadp2 -t a.out -SINGLE
    Could not find a P2
    RLs-MacBook-Pro:p2gcc roger$ loadp2 -t a.out -CHIP
    Could not find a P2
    

    When I specify the USB port I get these errors... it doesn't like the default higher baud rate.
    RLs-MacBook-Pro:p2gcc roger$ loadp2 -t a.out -p /dev/cu.usbserial-P23HPBP6 
    Unsupported baudrate 921600. Use 230400, 115200, 57600, 38400, 19200, or 9600
    RLs-MacBook-Pro:p2gcc roger$ loadp2 -t -l 921600 a.out -p /dev/cu.usbserial-P23HPBP6
    Unsupported baudrate 921600. Use 230400, 115200, 57600, 38400, 19200, or 9600
    RLs-MacBook-Pro:p2gcc roger$ loadp2 -t -l 921600 a.out -SINGLE -p /dev/cu.usbserial-P23HPBP6 
    Unsupported baudrate 921600. Use 230400, 115200, 57600, 38400, 19200, or 9600
    RLs-MacBook-Pro:p2gcc roger$ loadp2 -t -l 921600 a.out -CHIP -p /dev/cu.usbserial-P23HPBP6 
    Unsupported baudrate 921600. Use 230400, 115200, 57600, 38400, 19200, or 9600
    RLs-MacBook-Pro:p2gcc roger$ loadp2 -t a.out -SINGLE -p /dev/cu.usbserial-P23HPBP6 
    Unsupported baudrate 921600. Use 230400, 115200, 57600, 38400, 19200, or 9600
    RLs-MacBook-Pro:p2gcc roger$ loadp2 -t a.out -CHIP -p /dev/cu.usbserial-P23HPBP6 
    Unsupported baudrate 921600. Use 230400, 115200, 57600, 38400, 19200, or 9600
    


    When I both override the baud rate to 115200 AND specify the USB port I get this output... and all three variants downloaded the application to the P2 board and ran it.
    RLs-MacBook-Pro:p2gcc roger$ loadp2 -t -l 115200 a.out -p /dev/cu.usbserial-P23HPBP6 
    ( Entering terminal mode.  Press Ctrl-] to exit. )
    RLs-MacBook-Pro:p2gcc roger$ loadp2 -t -l 115200 a.out -SINGLE -p /dev/cu.usbserial-P23HPBP6 
    ( Entering terminal mode.  Press Ctrl-] to exit. )
    RLs-MacBook-Pro:p2gcc roger$ loadp2 -t -l 115200 a.out -CHIP -p /dev/cu.usbserial-P23HPBP6 
    ( Entering terminal mode.  Press Ctrl-] to exit. )
    

    Hope this helps!
    Cheers,
    Roger.
  • Roger, that helps a lot. I looked back at some of the previous posts in this thread, and David Betz said that 921600 works with proploader. Mark_T said that 230400 is the highest that he got to work with p2gcc. Can you try "-l 230400" to see if that works for you? Please also try "-l 230400 -b 230400".
    Thanks.
  • Dave Hein wrote: »
    I don't have a Mac, so I can't do a Mac build. I have a Linux system, but I've never posted binaries for Linux. Once in a while I do post Windows binaries along with the source in this thread, but that doesn't happen very often. The best place to get binaries is from David Zemon's site.
    How does David Zemon do the Mac builds? Does he use a cross compiler? If so, I'd be interested in knowing where to get it.

  • roglohrogloh Posts: 1,279
    edited 2019-02-03 - 05:02:09
    Dave Hein wrote: »
    Roger, that helps a lot. I looked back at some of the previous posts in this thread, and David Betz said that 921600 works with proploader. Mark_T said that 230400 is the highest that he got to work with p2gcc. Can you try "-l 230400" to see if that works for you? Please also try "-l 230400 -b 230400".
    Thanks.

    Will try that soon, but right now have been hacking with your osint_linux.c file and managed to get a 2000000 baud download working on the MAC and it works with Ahle's SIDCOG code. For higher baud rates above 230400 you need to bypass the cfsetspeed call and do IOCTL directly instead according to some online information I found. The basic problem is that MACOS X has not defined any higher speeds than 230400 bps in its termios.h file (in OS X 10.10.5 anyway), so regular terminal control API code won't let the higher baud rates work, but it will change the baud rate if you do the IOCTL. Limitation is that the termio stuff then gets out of sync and won't report the raw driver baud rate correctly.

    Here's some snippets of what I am trying...

    ....
    #include <limits.h>
    #include <signal.h>
    
    #ifdef MACOSX
    #include <IOKit/serial/ioss.h>
    #endif
    
    #include "osint.h"
    
    ....
    
    int serial_baud(unsigned long baud)
    {
        struct termios sparm;
        int tbaud = 0;
    
    #ifdef MACOSX
        speed_t speed = 0;
    #endif
    static unsigned long last_baud = -1;
    
    ....
    
            case 19200:
                tbaud = B19200;
                break;
            case 9600:
                tbaud = B9600;
                break;
            default:
    #ifdef MACOSX
                speed = baud;
                tbaud = baud;
                if (ioctl(hSerial, IOSSIOSPEED, &speed) == 0) // if IOCTL succeeds continue
                    break;
    #endif
                printf("Unsupported baudrate %lu. Use ", baud);
    #ifdef B921600
                printf("921600, ");
    #endif
    
    ....
    
        /* get the current options */
        chk("tcgetattr", tcgetattr(hSerial, &sparm));
        
        /* set raw input */
    #ifdef MACOSX
        printf("speed = %d\n", (int)speed);
        if (speed == 0) // only if baud was not directly set using IOCTL
            chk("cfsetspeed", cfsetspeed(&sparm, tbaud));
    #else
        chk("cfsetispeed", cfsetispeed(&sparm, tbaud));
        chk("cfsetospeed", cfsetospeed(&sparm, tbaud));
    #endif
    

    I still get some warnings printed for accessing tcsetattr which I'm trying to clean up... not sure why if I skip that cfsetspeed ... ?
    roger$ ./loadp2 -l 2000000 -p /dev/cu.usbserial-P23HPBP6 -t ~/Downloads/SIDcogP2_v1/a.out -CHIP
    speed = 2000000
    tcsetattr failed status = 22
    tcsetattr failed status = 22
    speed = 0
    ( Entering terminal mode.  Press Ctrl-] to exit. )
    
    
  • roglohrogloh Posts: 1,279
    edited 2019-02-03 - 07:57:36
    Also just tried "-l 230400" and "-l 230400 -b 230400" and it works. I was using my modified variant but the code I put in skips my changes if I select a supported baud rate in the original case statement, so it should still be valid for your original code too.

    UPDATE: I was only testing the download with a non-interactive program. Since then I have found that actual serial data being printed in programs using stdio get messed up if the baud rate is not set to -b 115200. Still investigating that to see if it relates to my own changes...
  • David Betz wrote: »
    Dave Hein wrote: »
    I don't have a Mac, so I can't do a Mac build. I have a Linux system, but I've never posted binaries for Linux. Once in a while I do post Windows binaries along with the source in this thread, but that doesn't happen very often. The best place to get binaries is from David Zemon's site.
    How does David Zemon do the Mac builds? Does he use a cross compiler? If so, I'd be interested in knowing where to get it.

    He uses an old machine sitting in @dgately's house running a second TeamCity slave :smile:
    David
    PropWare: C++ HAL (Hardware Abstraction Layer) for PropGCC; Robust build system using CMake; Integrated Simple Library, libpropeller, and libPropelleruino (Arduino port); Instructions for Eclipse and JetBrain's CLion; Example projects; Doxygen documentation
    CI Server: https://ci.zemon.name?guest=1
  • @Dave Hein, I can eliminate these tcsetattr errors by just moving the serial baud rate code to be called after putting the terminal device into raw mode etc when the port is first opened, and skipping out of the baud rate update code if the IOCTL method was called. Whether or not this creates any detrimental side effects I am not sure...but I will keep playing with it as is. I've attached the osint_linux.c file so you can diff it to see my entire changes to date. I'm not saying this is the proper way to do it, but I found it worked on my system so perhaps it's something useful.

    It would be nice to get the auto P2 port detection working. That seems to be broken on the Mac platform.
  • roglohrogloh Posts: 1,279
    edited 2019-02-03 - 06:54:41
    Dammit. Noticing weird behaviour with the terminal and p2gcc sample applications using STDIO with my modified p2load. When I choose a supported lower baud rate the test application like fibo.c seems to print out okay, but it will otherwise freeze up on the first printed line if I use a special higher baud rate like 1000000 etc even though the download works. Think it might be related to switching back into terminal modes after using that ioctl, not sure yet...
  • Roger, thanks for looking into this. I'll have to look at the P1 loader programs to see how they handle higher baud rates. The P1 loaders also have a way of automatically finding the P1 serial port. I believe they look at the entries in the /dev directory.
  • rogloh wrote: »
    Also just tried "-l 230400" and "-l 230400 -b 230400" and it works. I was using my modified variant but the code I put in skips my changes if I select a supported baud rate in the original case statement, so it should still be valid for your original code too.

    UPDATE: I was only testing the download with a non-interactive program. Since then I have found that actual serial data being printed in programs using stdio get messed up if the baud rate is not set to -b 115200. Still investigating that to see if it relates to my own changes...
    Has loadp2 changed recently? This worked fine for me several weeks ago when I tried:
    loadp2 -b 115200 -l 921600 $1.binary -t -v -p /dev/cu.usbserial-P2EEQXU -CHIP
    
    I'm running Mac OS X 10.14.1 on an ancient Mac mini.
  • I've made a few changes to loadp2 during the past few weeks, but the only thing specific to the Mac is that I changed the default loader rate from 2000000 to 921600. In theory you should be able to run the same command, but without specifying "-l 921500". I'm not sure why this doesn't work on some Macs.
  • RaymanRayman Posts: 9,716
    edited 2019-02-03 - 16:28:40
    I just tried the latest loadp2 binary from Zemon's website with the command David Betz's command line and it seems to work.

    Well, there might be some issue. Loading up the VGA_640_x_480_8bpp example, the bottom six or so lines of the image is messed up. Like it didn't fully load...

    I tried it again, this time without the "-t" and it worked. But, that isn't really proof of anything...
    Prop Info and Apps: http://www.rayslogic.com/
  • RaymanRayman Posts: 9,716
    edited 2019-02-03 - 18:41:56
    With the native Mac version, seems I don't need the -CHIP.

    For some reason, I get an error message: "Unsupported baud rate. Use tcsetattr failed".
    But, it works anyway.

    Seems I do need the "-l baud" though.
    Otherwise, it hangs like the PC version does under Wine with large files...
    Gives me an extra "tcsetattr failed" message.
    Prop Info and Apps: http://www.rayslogic.com/
  • RaymanRayman Posts: 9,716
    edited 2019-02-03 - 18:47:38
    Anyway, after added the location of loadp2 to my path, all I need to do to load is:
    loadp2 -l 921600 VGA_640_x_480_8bpp.binary -p /dev/cu.usbserial-P2EEJWO
    

    Nice thing about this way is that if I forget the -l baud part, I can terminate the window and recover the serial port without having to reboot...

    I'll just ignore that "Unsupported baud rate. Use tcsetattr failed." message.
    Prop Info and Apps: http://www.rayslogic.com/
  • The binary on David Zemon's site was built on January 28, which is the day before I made the default loader rate 921600 for the Mac. This means that without specifying the -l option you were loading at 2000000. That might explain the flakiness.
  • @Dave Hein , one simple question I have is: does the serial console rate (-b option) need to be set to 115200 (or left at its default) for the interactive test programs to work properly at the default clock speed when no special P2 clock parameters are given? If so that could probably explain at least some of what I am seeing. I was seeing data character corruption when this rate is halved or doubled etc, which looked somewhat like the wrong baud rate, though I really need to measure it on the logic analyzer / scope to see what it is really sending into the PC.
    E.g.
    With loadstr="loadp2 -l 2000000 -b 115200 -CHIP"
    RLs-MacBook-Pro:p2gcc roger$ p2gcc hello.c -r -t -p /dev/cu.usbserial-P23HPBP6
    ioctl succeeded
    Setting baudrate to 115200
    ( Entering terminal mode.  Press Ctrl-] to exit. )
    Hello World - 1
    Hello World - 2
    Hello World - 3
    Hello World - 4
    Hello World - 5
    Hello World - 6
    Hello World - 7
    

    With loadstr="loadp2 -l 2000000 -b 57600 -CHIP"
    RLs-MacBook-Pro:p2gcc roger$ p2gcc hello.c -r -t -p /dev/cu.usbserial-P23HPBP6
    ioctl succeeded
    Setting baudrate to 57600
    ( Entering terminal mode.  Press Ctrl-] to exit. )
    ?Ƈ?ń?D?Ƈ?ń?E?Ƈ?ń?E?Ƈ?ń?D?Ƈ?ń?D?Ƈ?ń?E?RLs-MacBook-Pro:p2gcc roger$
    
  • Really? You got 2000000 working on the Mac? I wasn't able to use anything higher than 921600. I think the Mac just passes the numeric baud rate to the driver and accepts whatever the driver accepts. Maybe I have an older FTDI driver installed on my machine.
  • David Betz wrote: »
    Really? You got 2000000 working on the Mac? I wasn't able to use anything higher than 921600. I think the Mac just passes the numeric baud rate to the driver and accepts whatever the driver accepts. Maybe I have an older FTDI driver installed on my machine.
    Yes really. I just needed to mod the osint_linux.c file that opens serial ports and sets baud rates using an IOCTL call for the higher baud rates, it's attached above. Still playing with it to see how stable it is.
  • rogloh wrote: »
    @Dave Hein , one simple question I have is: does the serial console rate (-b option) need to be set to 115200 (or left at its default) for the interactive test programs to work properly at the default clock speed when no special P2 clock parameters are given? If so that could probably explain at least some of what I am seeing. I was seeing data character corruption when this rate is halved or doubled etc, which looked somewhat like the wrong baud rate, though I really need to measure it on the logic analyzer / scope to see what it is really sending into the PC.
    The serial drivers in the p2gcc C library normally run at 115200. With loadp2 it is possible to change the clock frequency and baud rate by using the -PATCH option. -PATCH will cause loadp2 to copy the frequency and baud rate parameters at location starting at $400.

    I'm currently in the process of changing the system parm location from $400 to $14 so that it will be consistent with spin2gui. Once I do that I will make -PATCH the default mode, and add a -nopatch option to disable it.


  • rogloh wrote: »
    David Betz wrote: »
    Really? You got 2000000 working on the Mac? I wasn't able to use anything higher than 921600. I think the Mac just passes the numeric baud rate to the driver and accepts whatever the driver accepts. Maybe I have an older FTDI driver installed on my machine.
    Yes really. I just needed to mod the osint_linux.c file that opens serial ports and sets baud rates using an IOCTL call for the higher baud rates, it's attached above. Still playing with it to see how stable it is.
    Ugh. So ioctl works but cfsetspeed doesn't?

  • spin2gui question.
    What is the baud rate for the serial terminal. I suddenly have problems seeing the terminal.
    “Light thinks it travels faster than anything but it is wrong. No matter how fast light travels, it finds the darkness has always got there first, and is waiting for it.”
    “You only live twice:
    Once when you are born
    And once when you look death in the face”
  • rogloh wrote: »
    David Betz wrote: »
    Really? You got 2000000 working on the Mac? I wasn't able to use anything higher than 921600. I think the Mac just passes the numeric baud rate to the driver and accepts whatever the driver accepts. Maybe I have an older FTDI driver installed on my machine.
    Yes really. I just needed to mod the osint_linux.c file that opens serial ports and sets baud rates using an IOCTL call for the higher baud rates, it's attached above. Still playing with it to see how stable it is.
    I looked at your code and your early return if the ioctl succeeds skips over the following code. Will that cause any problems?
        /* set the options */
        chk("tcflush", tcflush(hSerial, TCIFLUSH));
        chk("tcsetattr", tcsetattr(hSerial, TCSANOW, &sparm));
    

  • pilot0315 wrote: »
    spin2gui question.
    What is the baud rate for the serial terminal. I suddenly have problems seeing the terminal.
    You should ask that question on the fastspin thread. That combination of clock frequency and baud rate works fine on p2gcc. Maybe it's a limitation of the object your using. Are you using a Mac? There are issues with running loadp2 at 2000000 on a Mac.
  • David Betz wrote: »

    Ugh. So ioctl works but cfsetspeed doesn't?

    Yes, for any baud rates higher than 230400.
    David Betz wrote: »
    [
    I looked at your code and your early return if the ioctl succeeds skips over the following code. Will that cause any problems?
        /* set the options */
        chk("tcflush", tcflush(hSerial, TCIFLUSH));
        chk("tcsetattr", tcsetattr(hSerial, TCSANOW, &sparm));
    

    My stuff is experimental so right now it's just a hack. I am still playing around to see if there are problems. I've seen some strange things during interactive P2 app startup, but lately it seems more stable. So I am wondering if the flushes are happening at the right time/place etc during baud rate changes if the app has started outputting to the terminal like reading some partially buffered data at the wrong baud rate etc. I need to study the entire sequence further when I have more time.

    Another recent change I put in does the IOCTL and that flush then returns immediately without touching tcsetattr and tcgetattr etc. I found that last extra tcsetattr() caused an error (which is ignored) when you try to write back the just read terminal settings (from tcgetattr()) over the top of whatever the IOCTL did even if I skip setting the higher baud rate with cfsetspeed(). Not sure why. To remedy I just use this simpler form now..
    case 9600:
                tbaud = B9600;
                break;
            default:
    #ifdef MACOSX
                speed = baud;
                if (ioctl(hSerial, IOSSIOSPEED, &speed) == 0) // if IOCTL succeeds continue
                {   
                    chk("tcflush", tcflush(hSerial, TCIFLUSH));
                    return 1;
                }
    #endif
                printf("Unsupported baudrate %lu. Use ", baud);
                tbaud = baud;
    
  • Dave Hein wrote: »
    The serial drivers in the p2gcc C library normally run at 115200. With loadp2 it is possible to change the clock frequency and baud rate by using the -PATCH option. -PATCH will cause loadp2 to copy the frequency and baud rate parameters at location starting at $400.

    I'm currently in the process of changing the system parm location from $400 to $14 so that it will be consistent with spin2gui. Once I do that I will make -PATCH the default mode, and add a -nopatch option to disable it.

    Thanks for this information Dave.
  • pilot0315 wrote: »
    spin2gui question.
    What is the baud rate for the serial terminal. I suddenly have problems seeing the terminal.

    The terminal speed changed from 200000 to 230400

    Mike
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • Using windows 7. All was working but all of sudden issues. Ran a program that simply printed then I got gobbydegook as if the baud rate was wrong. Pnut no problem.
    “Light thinks it travels faster than anything but it is wrong. No matter how fast light travels, it finds the darkness has always got there first, and is waiting for it.”
    “You only live twice:
    Once when you are born
    And once when you look death in the face”
  • this is an example
    659 x 342 - 31K
    “Light thinks it travels faster than anything but it is wrong. No matter how fast light travels, it finds the darkness has always got there first, and is waiting for it.”
    “You only live twice:
    Once when you are born
    And once when you look death in the face”
  • pilot0315, have you posted this on the fastspin thread? Are you using a Mac?
  • I've attached a zipfile with the latest p2gcc source and Windows binaries. The following changes have been made since the last update.

    - Many bug fixes
    - Added 32-bit floating point support
    - Added the ability to start new C cogs using cogstart
    - Added the ability to change the clock frequency and maintain a constant baud rate

    The current version numbers for each utility are:
    0.005 p2gcc
    0.012 loadp2
    0.008 p2asm
    0.003 p2dump
    0.003 p2dumpobj
    0.005 p2link
    0.006 s2pasm
Sign In or Register to comment.