Shop OBEX P1 Docs P2 Docs Learn Events
flexspin compiler for P2: Assembly, Spin, BASIC, and C in one compiler - Page 18 — Parallax Forums

flexspin compiler for P2: Assembly, Spin, BASIC, and C in one compiler

11516182021115

Comments

  • There was a missing compatibility define in <propeller.h> (we changed some things in propeller2.h, which had knock-on effects in the compatibility code). It should be fixed now in the current github.
  • David BetzDavid Betz Posts: 14,511
    edited 2019-08-08 12:37
    ersmith wrote: »
    There was a missing compatibility define in <propeller.h> (we changed some things in propeller2.h, which had knock-on effects in the compatibility code). It should be fixed now in the current github.
    Now I get this:
    /Users/dbetz/work/ebasic3/fastspin_stuff.c(15) error: unknown identifier _waitcnt used in function call
    
    I added a #define _PROP1_COMPATIBLE to this file before including propeller.h.

  • David Betz wrote: »
    ersmith wrote: »
    There was a missing compatibility define in <propeller.h> (we changed some things in propeller2.h, which had knock-on effects in the compatibility code). It should be fixed now in the current github.
    Now I get this:
    /Users/dbetz/work/ebasic3/fastspin_stuff.c(15) error: unknown identifier _waitcnt used in function call
    
    I added a #define _PROP1_COMPATIBLE to this file before including propeller.h.

    I don't see that. Maybe try without the _PROP1_COMPATIBLE? Or you could just change the definition of sleep to:
    void sleep(int secs) { _waitx(clockfreq*secs); }
    
    using the new _waitx macro.
  • ersmith wrote: »
    David Betz wrote: »
    ersmith wrote: »
    There was a missing compatibility define in <propeller.h> (we changed some things in propeller2.h, which had knock-on effects in the compatibility code). It should be fixed now in the current github.
    Now I get this:
    /Users/dbetz/work/ebasic3/fastspin_stuff.c(15) error: unknown identifier _waitcnt used in function call
    
    I added a #define _PROP1_COMPATIBLE to this file before including propeller.h.

    I don't see that. Maybe try without the _PROP1_COMPATIBLE? Or you could just change the definition of sleep to:
    void sleep(int secs) { _waitx(clockfreq*secs); }
    
    using the new _waitx macro.
    Okay, I'll make that change. I didn't commit the code that had the #define _PROP1_COMPATIBLE line in it. That's why you didn't see it. In any case, I should be moving away from using P1 stuff so I'll take your suggestion.
  • I actually had to change the definition of sleep to this because clockfreq also came out undefined but now it builds minus some warnings that I need to fix in my own code. I'll try to see if it runs tonight. Thanks for your help!
    void sleep(int secs)
    {
        _waitx(_clockfreq() * secs);
    }
    
  • David Betz wrote: »
    Okay, I'll make that change. I didn't commit the code that had the #define _PROP1_COMPATIBLE line in it. That's why you didn't see it. In any case, I should be moving away from using P1 stuff so I'll take your suggestion.

    I just realized the error was probably because you had to rebuild fastspin (which has the _waitcnt definition baked in). The change I made wasn't just to the header file, I also added _waitcnt (which is mandated by propeller2.h but had been missing).

  • ersmith wrote: »
    David Betz wrote: »
    Okay, I'll make that change. I didn't commit the code that had the #define _PROP1_COMPATIBLE line in it. That's why you didn't see it. In any case, I should be moving away from using P1 stuff so I'll take your suggestion.

    I just realized the error was probably because you had to rebuild fastspin (which has the _waitcnt definition baked in). The change I made wasn't just to the header file, I also added _waitcnt (which is mandated by propeller2.h but had been missing).
    That might be. At first I just installed the new include directory. On a later attempt I updated fastspin as well. In any case, I have it working now and have pushed my changes to GitHub. Thanks for your help!
  • Cluso99Cluso99 Posts: 18,066
    I've been caught with getct before :(
  • David BetzDavid Betz Posts: 14,511
    edited 2019-08-09 01:48
    I successfully compiled ebasic3 but when I tried loading it I got this error and loadp2 hung:
    Davids-Mac-mini:ebasic3 dbetz$ loadp2 -p /dev/tty.usbserial-P2EEQXU -b 115200 -l 115200 ebasic -t
    not an ELF file
    
    I'm using loadp2 from Eric's GitHub repository.
  • Has anyone had any luck compiling fastspin C programs and running them on a Mac? I did this quite a while ago but I can't get it working anymore. I can build the program but loadp2 won't load and run it. I have issues with loadp2 finding the P2 port and also with complaints about the default baud rates.
  • evanhevanh Posts: 15,091
    edited 2019-08-09 03:29
    "not an ELF file" is just informational. The file is then treated as a pure propeller binary image.

    Try adding the -v option. It might reveal something.

    I use -SINGLE option but I think it's the default anyway.

  • Cluso99Cluso99 Posts: 18,066
    eric,
    Noticed a bug in fastspin listing. If at the end of the file there is a label but no code, the listing ends without displaying those additional lines. I guess a comment such as the MIT license would also not be included in the listing.
                  add       x, #1                   '10
    
                  ret
    hub_test_end
    '                            
    
  • evanh wrote: »
    "not an ELF file" is just informational. The file is then treated as a pure propeller binary image.

    Try adding the -v option. It might reveal something.

    I use -SINGLE option but I think it's the default anyway.
    I wondered about whether that might just be informational. I see one of the LEDs flashing so maybe the download is actually happening but the program isn't running correctly.

  • Hi Eric
    I'm trying to extract debug data from fastspin .lst files and hit a problem.
    In some situations the label is shown in the wrong address.
    e.g.
    004c4 031 030000FF
    004c8 032 D4EC07F6    | copyx		mov	pa,##_copy0		'start video buffer update
    
    In the above example "copyx" should be on the previous line, the AUGS line.

    The issue also appears in relation to "file" directives.
    3c024     10FE67FC
    3c028     FF0300F6
    3c02c     F80500F6
    .
    .
    .
    3cab8     00000000
    3cabc     00000000
    3cac0     00000000    | debug		file	"P2Debug_pasm2_9_8.blob"
    
    Here the label "debug" is at the end of the data not the beginning.
  • David BetzDavid Betz Posts: 14,511
    edited 2019-08-09 11:41
    Can someone post a simple C program that is known to work on the P2-Eval board? I tried a simple "Hello, world" program and that didn't display anything either. Should printf print to the serial port? Is 115200 the correct baud rate?

    This is the program that I tried:
    #include <stdio.h>
    
    void main(void)
    {
        printf("Hello, world!\n");
        for (;;)
            ;
    }
    
    I built and ran it like this:
    fastspin -o test -2 test.c
    loadp2 -t -b 115200 -p $PORT test
    
  • Cluso99Cluso99 Posts: 18,066
    edited 2019-08-09 12:04
    My fastspin download defaulted its terminal to 230,400 baud so that could be a problem.

    BTW Love the fact that it leaves the terminal up after the compile/download/run :)
  • Cluso99 wrote: »
    My fastspin download defaulted its terminal to 230,400 baud so that could be a problem.

    BTW Love the fact that it leaves the terminal up after the compile/download/run :)
    Good thought but I tried "-b 230400" and I still didn't see any output. I also added a delay.
    #include <stdio.h>
    #include <propeller.h>
    
    void sleep(int secs)
    {
        _waitx(_clockfreq() * secs);
    }
    
    void main(void)
    {
        sleep(1);
        printf("Hello, world!\n");
        for (;;)
            ;
    }
    

  • David BetzDavid Betz Posts: 14,511
    edited 2019-08-09 12:21
    Well, I realized what one of my problems was. I was using /dev/tty.usbserial-P2EEQXU instead of /dev/cu.usbserial-P2EEQXU. That seems to have made the download succeed but I get garbage characters printed. What is the default serial baud rate for fastspin programs? I tried 115200 and 230400 and neither seemed to work.

    Edit: Never mind. If I use both "-b 230400" and "-l 230400" everything seems to work with both my test program and ebasic3. Now I just have to figure out how to get loadp2 to use higher baud rates on the Mac.
  • evanh wrote: »
    "not an ELF file" is just informational. The file is then treated as a pure propeller binary image.
    Whoops, yes, that's some debug code that I forgot to take out. Sorry about that, it's fixed in github now.

    David, as you've figured out the default baud rate for P2 is 230400 and default clock speed is 160000000. Those default settings are still relatively new, it used to be that you had to explicitly set the clock for P2, and it's possible there are some edge cases where the explicit setting is still required.

    If you can find out how to set higher clock speeds on the Mac I'd be delighted to put that into my version of loadp2.
  • Cluso99 wrote: »
    eric,
    Noticed a bug in fastspin listing. If at the end of the file there is a label but no code, the listing ends without displaying those additional lines. I guess a comment such as the MIT license would also not be included in the listing.
                  add       x, #1                   '10
    
                  ret
    hub_test_end
    '                            
    

    Hmmm, interesting. Thanks for the bug report, I'll look into it.
  • ozpropdev wrote: »
    I'm trying to extract debug data from fastspin .lst files and hit a problem.
    In some situations the label is shown in the wrong address.
    Hmmm, that's an interesting problem. I guess it's because I'm displaying the source code at the end of the hex output instead of the beginning of it. I'm not sure if I can switch that around or not, but I'll look into it.

    We could also provide a switch to explicitly dump labels (and any other debug information we can think of) into a file for the debugger. What format would be convenient for that?

  • ersmith wrote: »
    If you can find out how to set higher clock speeds on the Mac I'd be delighted to put that into my version of loadp2.
    I assume you mean higher baud rates. I'll try to figure this out. Proploader certainly is able to use higher baud rates so I'll check to see how the code differs.
  • Cluso99Cluso99 Posts: 18,066
    ersmith wrote: »
    ozpropdev wrote: »
    I'm trying to extract debug data from fastspin .lst files and hit a problem.
    In some situations the label is shown in the wrong address.
    Hmmm, that's an interesting problem. I guess it's because I'm displaying the source code at the end of the hex output instead of the beginning of it. I'm not sure if I can switch that around or not, but I'll look into it.

    We could also provide a switch to explicitly dump labels (and any other debug information we can think of) into a file for the debugger. What format would be convenient for that?
    Are you thinking like an xref listing?

    An xref lists at the end of the standard asm list, each label in alpha order with the address and line number where declared, followed by the line numbers where the label is referenced.

    It was very important way back when editors were quite primitive. These days, with fast computers and excellent searches, listings aren’t used anywhere near as often.
  • Cluso99 wrote: »
    ersmith wrote: »
    ozpropdev wrote: »
    I'm trying to extract debug data from fastspin .lst files and hit a problem.
    In some situations the label is shown in the wrong address.
    Hmmm, that's an interesting problem. I guess it's because I'm displaying the source code at the end of the hex output instead of the beginning of it. I'm not sure if I can switch that around or not, but I'll look into it.

    We could also provide a switch to explicitly dump labels (and any other debug information we can think of) into a file for the debugger. What format would be convenient for that?
    Are you thinking like an xref listing?

    An xref lists at the end of the standard asm list, each label in alpha order with the address and line number where declared, followed by the line numbers where the label is referenced.

    No, I was thinking more of just a list of labels and their hub and COG addresses, in some form that would be easier to parse than a .lst file, something like:
      entry = $000000 $000
      label2 = $000008 $002
      huba = $0000400
    
  • Cluso99Cluso99 Posts: 18,066
    ersmith wrote: »
    Cluso99 wrote: »
    ersmith wrote: »
    ozpropdev wrote: »
    I'm trying to extract debug data from fastspin .lst files and hit a problem.
    In some situations the label is shown in the wrong address.
    Hmmm, that's an interesting problem. I guess it's because I'm displaying the source code at the end of the hex output instead of the beginning of it. I'm not sure if I can switch that around or not, but I'll look into it.

    We could also provide a switch to explicitly dump labels (and any other debug information we can think of) into a file for the debugger. What format would be convenient for that?
    Are you thinking like an xref listing?

    An xref lists at the end of the standard asm list, each label in alpha order with the address and line number where declared, followed by the line numbers where the label is referenced.

    No, I was thinking more of just a list of labels and their hub and COG addresses, in some form that would be easier to parse than a .lst file, something like:
      entry = $000000 $000
      label2 = $000008 $002
      huba = $0000400
    

    That would be easier although we can search the listing.

    In the good (or bad) old days we only had the option to print to the line printer, or surpress the listing. No spooling.
  • jmgjmg Posts: 15,140
    David Betz wrote: »
    evanh wrote: »
    "not an ELF file" is just informational. The file is then treated as a pure propeller binary image.

    Try adding the -v option. It might reveal something.

    I use -SINGLE option but I think it's the default anyway.
    I wondered about whether that might just be informational. I see one of the LEDs flashing so maybe the download is actually happening but the program isn't running correctly.
    If it is informational, it should be a 'note', or smarter would be to say what file type it was actually using (/assuming), rather than what it is not....
    David Betz wrote: »
    I see one of the LEDs flashing so maybe the download is actually happening but the program isn't running correctly.
    I would expect any download program to say how many bytes it had downloaded, as a useful report back to the user.
  • jmgjmg Posts: 15,140
    David Betz wrote: »
    Well, I realized what one of my problems was. I was using /dev/tty.usbserial-P2EEQXU instead of /dev/cu.usbserial-P2EEQXU. That seems to have made the download succeed but I get garbage characters printed. What is the default serial baud rate for fastspin programs? I tried 115200 and 230400 and neither seemed to work.

    Edit: Never mind. If I use both "-b 230400" and "-l 230400" everything seems to work with both my test program and ebasic3. Now I just have to figure out how to get loadp2 to use higher baud rates on the Mac.

    Can you post the command line that finally worked ok ?
  • David BetzDavid Betz Posts: 14,511
    edited 2019-08-09 20:26
    I'm not at home right now but I believe it was this:
    loadp2 -t -b 230400 -l 230400 -p /dev/cu.usbserial-P2EEQXU test
    
  • jmgjmg Posts: 15,140
    ersmith wrote: »
    ozpropdev wrote: »
    I'm trying to extract debug data from fastspin .lst files and hit a problem.
    In some situations the label is shown in the wrong address.
    Hmmm, that's an interesting problem. I guess it's because I'm displaying the source code at the end of the hex output instead of the beginning of it. I'm not sure if I can switch that around or not, but I'll look into it.

    We could also provide a switch to explicitly dump labels (and any other debug information we can think of) into a file for the debugger. What format would be convenient for that?

    Do you mean a separate debug file from the MAP file ?
    I'm used to seeing 3+ files generated in other MCus
    - The listing file : better tools include the source lines interspersed with the generated ASM lines
    - The MAP file : Shows ALL vars, their memory segments, address, and name. Better tools here preserve case, and include a VAR Type tag, for watch.
    This is column aligned, and can be large but modern editors do not really care.
    - The debug file : can be binary, or ASCII. SDCC has quite a good ascii format debug file, that includes type tags. Better debug tools offer an endian choice.
    - The HEX or BIN code file. Nothing but bytes.
    In SiLabs Debug case, they read the OMF file, and download the binary info interspersed in there, and extract the Name.Type info for WATCH use.
    I'm in two minds about that - I can see using one file is easier to specify & avoids creep, and it seems to work fine, but a minus is the file you send is not the HEX file you might use in production.
    (I've never seen a difference, so maybe I worry too much ;) )
  • jmgjmg Posts: 15,140
    ersmith wrote: »
    If you can find out how to set higher clock speeds on the Mac I'd be delighted to put that into my version of loadp2.

    I presume you mean Baud settings ?

    DB: If I use both "-b 230400" and "-l 230400" everything seems to work
    On that topic, I hope loadp2 has no issues with this "-b 3" and "-l 3" ?
    To avoid driver issues, on the UB3 bridge, I've done a dual-baud plane design. Numbers under 366 are used as a 24MHz/N specifier, to allow any fast HW baud, that avoids driver-imposed ceilings.
Sign In or Register to comment.