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

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

1100101103105106122

Comments

  • @Wuerfel_21 : -std=gnu11 shouldn't be necessary; it is definitely my intention that flexspin should be able to build with any C99 conforming compiler, although so far I've only tried clang and gcc.

  • @ersmith said:
    @Wuerfel_21 : -std=gnu11 shouldn't be necessary; it is definitely my intention that flexspin should be able to build with any C99 conforming compiler, although so far I've only tried clang and gcc.

    Then set -std=c99 (truth be told, I have no idea what the difference between gnu99 and c99 modes even is)

  • @ersmith

    Trying to download:FlexProp 5.9.20
    from github. I do not see a download link. Github is a pain. Can you help.
    Thank you in advance.
    Martin

  • Or if you click on the link in my signature https://github.com/totalspectrum/flexprop/releases you'll see a page describing the various releases available. At the end of the 5.9.20 description there's a section called "Assets" with 3 files listed. The first one, flexprop-5.9.20.zip, is the one you want; the other two are compressed versions of the source code.

  • I just downloaded and installed 5.9.20, thanks Eric. However I must be getting too old for this stuff, I cannot remember how to start flexprop from the linux command line.
    Jim

  • @RS_Jim said:
    I just downloaded and installed 5.9.20, thanks Eric. However I must be getting too old for this stuff, I cannot remember how to start flexprop from the linux command line.
    Jim

    There's no pre-built linux binary in the .zip file, unfortunately you'll have to build it yourself. The instructions are in the README. Starting it from the linux command line is just:

    cd ~/flexprop  # or wherever you installed
    ./flexprop
    
  • @ersmith

    When I click on assets all I get are circles. Does not matter which version.

  • @pilot0315 said:
    @ersmith

    When I click on assets all I get are circles. Does not matter which version.

    Sounds like a browser issue. I can see all of it on Firefox, Edge and IOS.

  • pilot0315pilot0315 Posts: 913
    edited 2022-12-02 21:27

    @JRoark Thanks for the link. I was using waterfox. And as usual had to run the compatibility trouble shooter because of windows 10
    @ersmith

  • Thanks Eric. I could not remember the ./flexprop. I guess it is time for a sticky note!
    Jim

  • ManAtWorkManAtWork Posts: 2,176
    edited 2022-12-09 17:19

    I have problems setting up the clock and baud rate on my custom P2 board. I have a 50MHz clock source connected to XI. This Spin program works perfectly

    CON
      _xtlfreq = 50_000_000         ' master clock vom Ethernet-Controller
      _clkfreq = 200_000_000
    
      pinLedG    = 2  ' green LED (front panel)
      pinLedR    = 3  ' red LED (front panel)
    
    PUB main () 
      pinh (pinLedG)
      debug ("Test OK")
      repeat
    

    I tried the same in C. sys/p2_clock.h doesn't know 50MHz but I've fixed that by providing the hardwired PLL setup on my own.

    #define modePll 0b1_000000_0000000011_1111_01_11 // 200 = 50 * 4
    #define _XTALFREQ   50_000_000
    #define _CLOCKFREQ 200_000_000
    
    #define P2_TARGET_MHZ 200
    #define _XOSC 1
    //#include <sys/p2_clock.h>
    #define _BAUD     230400    // serial debug port
    
    #include <propeller2.h>
    #include <stdio.h>
    
    #define pinLedG 2 // front LED green
    #define pinLedR 3 // front LED red
    
    int main (void)
    {
      _clkset (modePll, _CLOCKFREQ);
      _setbaud(_BAUD);
      _pinh (pinLedG);
      printf ("Test OK");
      while (1) {};
    }
    

    Unfortunatelly, this doesn't work at all. The LED does not light up and no output appears in the terminal window. Any idea what I did wrong?

    Nearly the same code but with

    #define modePll 0b1_000000_0000000111_1111_10_11 // 200 = 25 * 8
    #define _XTALFREQ   25_000_000
    #define _CLOCKFREQ 200_000_000
    

    works on the KISS board with a 25MHz crystal. I thought loadP2 doesn't like the 50MHz clock and overspeeds but why does it work with the Spin2 program and not with C? I use VSC and FlexC to compile and LoadP2 to download for both.

  • AribaAriba Posts: 2,690

    Have you tried:

    enum{  _xtlfreq = 50_000_000,
           _clkfreq = 200_000_000
    };
    

    This should be the same as with Spin2.

    Andy

  • evanhevanh Posts: 15,967
    edited 2022-12-09 21:17

    The ideal setting is:

    enum{  _xinfreq = 50_000_000,
           _clkfreq = 200_000_000
    };
    

    This removes the XI/XO loading caps.

    PS: Here's my boiler plate at top of every C program:

    enum {
        // _xinfreq = 20_000_000,
        _xtlfreq = 20_000_000,
        _clkfreq = 100_000_000,
        DOWNLOAD_BAUD = 230_400,
        DEBUG_BAUD = DOWNLOAD_BAUD,
    
    };
    
  • Thanks @Ariba and @evanh, now it works! :) But I still wonder why it doesn't with my previous clock setting. According to the docs both methods should be valid. And both methods actually work at 20 or 25MHz but at 50MHz the _setclk() or p2_clock.h doesn't. Strange

  • evanhevanh Posts: 15,967

    The printf() is too soon for PLL to have adjusted. Recommended pause is something like 10 ms. The LED might be some other reason like inverted drive.

  • IMHO, _setclk() should internally handle the right sequence and delays to switch the clock source properly. So the clock should be stable immediately after returning from _setclk(). On the other hand _setbaud() of course does not work immediately if there are still some characters in the send buffer. If the baud rate is misadjusted there should be at least some garbled characters visible. And the LED must work at any clock frequency.

    I have to check the generated assembler code to find out the difference. I guess that the enum{} method uses Chip's magic code to calculate the optimum PLL settings. The direct _setclk() method might have a bug where it first switches to what it thinks the old PLL ratio was, waits for the 10ms delay and then switches to the new settings. This would cause an intermediate clock frequency of 400MHz to be set which crashes the P2. Just speculations....

  • evanhevanh Posts: 15,967
    edited 2022-12-10 15:22

    For sure _setclk() does do the correct sequence for reliable frequency change.

    And yep, I guess it must be stable before returning. A quick test of your code adjusted to suit an Eval Board shows I get the message cleanly printed. So not sure why you've got an issue with setclk().

    #include <stdio.h>
    
    
    #define modePll 0b1_000000_0000000011_1111_10_11 // 200 = 50 * 4
    #define _CLOCKFREQ 80_000_000
    #define _BAUD     230400    // serial debug port
    
    
    int main (void)
    {
      _clkset (modePll, _CLOCKFREQ);
      _setbaud(_BAUD);
      printf ("Test OK\n");
      while (1) {};
    }
    
  • evanhevanh Posts: 15,967

    Oh, what you could try is presetting the compile-time startup and then adjusting with _clkset() ...

    #include <stdio.h>
    
    
    #define modePll 0b1_000000_0000000011_1111_01_11 // 200 = 50 * 4
    #define _CLOCKFREQ 200_000_000
    #define _BAUD     230400    // serial debug port
    
    
    enum{  _xinfreq = 50_000_000,
           _clkfreq = 20_000_000
    };
    
    
    int main (void)
    {
      printf (" Test starting ... \n");
      _waitms(100);
      _clkset (modePll, _CLOCKFREQ);
      _setbaud(_BAUD);
      printf ("Test OK\n");
      while (1) {};
    }
    
  • evanhevanh Posts: 15,967
    edited 2022-12-10 15:35

    Assuming that works, that'll offer reasonable confirmation of a compile-time/loader/defaults limitation.

  • @ersmith I've just found a minor bug related to 64 bit integer types:

    uint64_t velSum;
    int idleCntP;
    ...
    bool IsMoving ()
    {
      return velSum || idleCntP;
    }
    

    causes an "internal error: dereference of large object". While

    bool IsMoving ()
    {
      return (velSum != 0) || idleCntP;
    }
    

    compiles without problems. I thought both versions should be semantically identical. It would also be good if the "internal error" would at least give some hint where the error occured. It takes quite some time to find the cause by shotgun debugging if the source code is rather long.

  • ManAtWorkManAtWork Posts: 2,176
    edited 2022-12-10 18:12

    Today is one of those days I'm out of luck. I spend more time debugging the compiler than my own code (which should have lots of bugs on it's own so I don't run out of work).

    The following simple program should print "Text=Hello World len=11"

    enum {
        _xinfreq = 50_000_000,
        _clkfreq = 200_000_000,
        DOWNLOAD_BAUD = 230_400,
        DEBUG_BAUD = DOWNLOAD_BAUD,
    };
    
    #include <propeller2.h>
    #include <stdio.h>
    #include <string.h>
    
    struct __using("net_protocol.spin2") net;
    
    char* Text = "Hello World";
    
    int main (void)
    {
      printf ("Text=%s len=%d\n", Text, strlen(Text));
    }
    

    but instead it prints "Text= len=0". :( However, if I comment out the line struct __using(... it works as it should. I'm not calling or using any contents of net_protocol.spin2. I think the combination of C and Spin2 somehow messes up the allocation of memory, again.

    (PS: please replace _xinfreq = 50_000_000 with _xtlfreq = 20_000_000 if you run it on a standard EVAL board)

  • OK, I've also spotted the reason why the _clkset() in the main function does not work in my case. The enum clock setting method compiles to this asssembler code which looks reasonable and works:

    00000                 | con
    00000                 |     _clkfreq = 200000000
    00000                 |     _clkmode = 16778231 = %1_000000_0000000011_1111_01_11
    00000                 | dat
    00000 000 00 00 00 00 |     nop
    00004 001 01 EC 63 FD |     cogid   pa
    00008 002 02 00 00 FF 
    0000c 003 04 EC E7 FC |     coginit pa,##$404
    00010                 |     orgh    $10
    00010     00 00 00 00 |     long    0   'reserved
    00014     00 00 00 00 |     long    0 ' clock frequency: will default to 200000000
    00018     00 00 00 00 |     long    0 ' clock mode: will default to $10003f7
    0001c     00 00 00 00 
          ...             
    003f8     00 00 00 00 
    003fc     00 00 00 00 |     orgh    $400
    00400     00 94 05 06 |  _ret_  mov result1, #0
    00404 000             |     org 0
    00404 000             | entry
    00404 000 00 F0 0F F2 |     cmp ptra, #0 wz
    00408 001 0C 02 90 5D |  if_ne  jmp #spininit
    0040c 002 C9 F0 03 F6 |     mov ptra, ptr_stackspace_
    00410 003 14 EC 0F FB |     rdlong  pa, #20 wz
    00414 004 EC 01 90 5D |  if_ne  jmp #skip_clock_set_
    00418 005 00 00 64 FD |     hubset  #0
    0041c 006 01 80 80 FF 
    00420 007 00 E8 67 FD |     hubset  ##16778228 ' SS=00 RCFAST
    00424 008 86 01 80 FF 
    00428 009 1F 80 66 FD |     waitx   ##200000   ' wait 10ms
    0042c 00a 01 80 00 FF 
    00430 00b F7 ED 07 F6 |     mov pa, ##16778231 ' SS=11 PLL
    00434 00c 00 EC 63 FD |     hubset  pa
    00438 00d 18 EC 67 FC |     wrlong  pa, #24
    0043c 00e E1 F5 85 FF 
    00440 00f 14 00 6C FC |     wrlong  ##200000000, #20
    00444 010 BC 01 90 FD |     jmp #skip_clock_set_
    00448 011 00 00 00 00 
          ...             
    005fc 07e 00 00 00 00 
    00600 07f 00 00 00 00 |     orgf    128
    00604 080             | skip_clock_set_
    00604 080 34 07 A0 FD |     call    #_main
    00608 081             | cogexit
    

    However, if I DO NOT set the enum values the compiler still generates code to set the clock BEFORE my main function gets called.

    00010                 |     orgh    $10
    00010     00 00 00 00 |     long    0   'reserved
    00014     00 00 00 00 |     long    0 ' clock frequency: will default to 160000000
    00018     00 00 00 00 |     long    0 ' clock mode: will default to $10007fb
    0001c     00 00 00 00 
          ...             
    003f8     00 00 00 00 
    003fc     00 00 00 00 |     orgh    $400
    00400     00 94 05 06 |  _ret_  mov result1, #0
    00404 000             |     org 0
    00404 000             | entry
    00404 000 00 F0 0F F2 |     cmp ptra, #0 wz
    00408 001 0C 02 90 5D |  if_ne  jmp #spininit
    0040c 002 C9 F0 03 F6 |     mov ptra, ptr_stackspace_
    00410 003 14 EC 0F FB |     rdlong  pa, #20 wz
    00414 004 EC 01 90 5D |  if_ne  jmp #skip_clock_set_
    00418 005 00 00 64 FD |     hubset  #0
    0041c 006 03 80 80 FF 
    00420 007 00 F0 67 FD |     hubset  ##16779256
    00424 008 86 01 80 FF 
    00428 009 1F 80 66 FD |     waitx   ##200000
    0042c 00a 03 80 00 FF 
    00430 00b FB ED 07 F6 |     mov pa, ##16779259 = %1_000000_0000000111_1111_10_11
    00434 00c 00 EC 63 FD |     hubset  pa
    00438 00d 18 EC 67 FC |     wrlong  pa, #24
    0043c 00e B4 C4 84 FF 
    00440 00f 14 00 6C FC |     wrlong  ##160000000, #20
    00444 010 BC 01 90 FD |     jmp #skip_clock_set_
    00448 011 00 00 00 00 
          ...             
    005fc 07e 00 00 00 00 
    00600 07f 00 00 00 00 |     orgf    128
    00604 080             | skip_clock_set_
    00604 080 34 07 A0 FD |     call    #_main
    00608 081             | cogexit
    

    This is no problem if the defaults are just slightly off the reality such as 20 vs. 25MHz at the KISS board. But in this case a PLL factor of x8 means that the clock is actually set to 50*8=400MHz! This leads to a crash. So the advice is "do always use the enum method to set the clock if your XIN is way above 20MHz".

  • evanhevanh Posts: 15,967
    edited 2022-12-10 22:35

    @ManAtWork said:
    This is no problem if the defaults are just slightly off the reality such as 20 vs. 25MHz at the KISS board. But in this case a PLL factor of x8 means that the clock is actually set to 50*8=400MHz! This leads to a crash. So the advice is "do always use the enum method to set the clock if your XIN is way above 20MHz".

    Yeah, figures. Compilers, as opposed to assemblers, want to have a known sysclock frequency. Without it specified the compilers will all assume a 20 MHz crystal is attached to XI/XO pins.

  • evanhevanh Posts: 15,967
    edited 2022-12-10 22:42

    [ignore]

  • @ManAtWork said:
    @ersmith I've just found a minor bug related to 64 bit integer types:

    Thank you, that's fixed in the github sources now.

    The following simple program should print "Text=Hello World len=11"

    It does for me using FlexProp 5.9.21. Which version were you trying it with?

  • Binaries for FlexProp 5.9.21 are available now on github (they've been up on Patreon for a little while). Changes include:

    - Automatically zero local Spin2 variables
    - Fixed loop test for downwards loops with steps > 1.
    - Fixed some problems with variable offsets in Spin
    - Fixed an incorrect read/write optimization affecting assembly output
    - Improved handling of two dimensional arrays in BASIC
    - Improved handling of method pointers in Spin2
    - Optimized ZEROX (thanks Ada)
    - Optimize some "obvious" 64 bit shifts
    - Restored generation of all public methods in spin2cpp C and C++ output
    
  • evanhevanh Posts: 15,967
    edited 2022-12-11 22:45

    @ersmith said:

    @ManAtWork said:
    The following simple program should print "Text=Hello World len=11"

    It does for me using FlexProp 5.9.21. Which version were you trying it with?

    5.9.20 had the problem. Like you say, 5.9.21 works.

    With 5.9.21, I'm getting some extraneous emitted text when -gbrk is specified. It looks like maybe the baud is wrong with presumably the [COG0] startup message is being emitted. I'm defining DEBUG_BAUD as 230400. Examples:
    d$TfDt4�
    $tgt$T�
    d4T&6$�

    PS: I wasn't actually using any debug calls in my code.

  • @evanh said:
    With 5.9.21, I'm getting some extraneous emitted text when -gbrk is specified. It looks like maybe the baud is wrong with presumably the [COG0] startup message is being emitted. I'm defining DEBUG_BAUD as 230400.

    What language are you using? Do you have some sample cod you can share? It could be a case problem, if it's in C. If all else fails put -D_BAUD=230400 on the command line; that's the way FlexProp defines the baud and it always seems to work.

Sign In or Register to comment.