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

15455565759

Comments

  • I've just notices that in the official Spin2 documentation there is a predefined constant "P_PERIODS_TICKS" for smartpin mode %10011. The name in Fastspin is different: "P_PERIOD_TICKS". Which one is correct? The later makes sense because the purpose is measuring ticks per period. But "periods" also makes sense because multiple periods can be measured (oversampling).
  • Whatever PNut does is the "correct" form. It looks like it should be P_PERIODS_TICKS and the fastspin version is a typo. I'll fix that in the next release.
  • Eric,
    I notice when using the terminal (W10 command prompt) after compiling with fastspin and loading with loadp2 (l424 z0%1.binary -b115200 -t -SINGLE) that the backspace does not translate to a $08. I haven't traced what precisely is being sent. Should backspace work?
  • The backspace key sends a value of 127.
  • Cluso99 wrote: »
    Eric,
    I notice when using the terminal (W10 command prompt) after compiling with fastspin and loading with loadp2 (l424 z0%1.binary -b115200 -t -SINGLE) that the backspace does not translate to a $08. I haven't traced what precisely is being sent. Should backspace work?

    It's whatever Windows wants to send -- loadp2 isn't doing any translation on the key presses, except that in PST mode a line feed gets added to all carriage returns. I guess in Windows ANSI mode the backspace key sends 127, as Dave mentioned above.
  • Thanks Dave & Eric,
    Converted $7F to $08 and all works :)
  • There's a new version of fastspin (4.2.5) with quite a few bug fixes and a new flag, -Wall, to enable additional warnings. This will tell you about (some) uses of fastspin extensions, e.g. .spin2 code where you don't put parentheses after function calls with no arguments. It should help in porting code from fastspin to Chip's compiler.
  • I greatly underestimated the difficulty in catching all of the fastspin-specific bits in my code when trying to make my code closer to PNut-compatible before the existence of this switch... Thanks millions for that one!
  • @ersmith: Patreon has been having issues all morning. Fortunately Github seems fine.

    Error 504
    Ray ID: 5b6f56a7970a0e5a • 2020-07-22 18:49:03 UTC
    Gateway time-out
    You: Browser Working
    Cloudflare: Working
    Host: www.patreon.com
    Error: 504

    What happened?
    The web server reported a gateway time-out error.

    What can I do?
    Please try again in a few minutes.
  • @ersmith The new -Wall command is really nice, even coding in BASIC. This compiler output was from working code that I had "blessed" and was using successfully, yet the compiler now shows bits of contention that I had no idea existed. This is a *wonderful* addition, Eric.
    d:\Flex2Gui\flexgui\P2 Libs\DateTimeLibP2.bas:630: warning: definition of Day hides a member variable
    DS3231RTC_P2_V2.spin:50: warning: () for empty parameter lists is a fastspin extension
    DS3231RTC_P2_V2.spin:59: warning: () for empty parameter lists is a fastspin extension
    DS3231RTC_P2_V2.spin:68: warning: () for empty parameter lists is a fastspin extension
    DS3231RTC_P2_V2.spin:77: warning: () for empty parameter lists is a fastspin extension
    DS3231RTC_P2_V2.spin:86: warning: () for empty parameter lists is a fastspin extension
    DS3231RTC_P2_V2.spin:95: warning: () for empty parameter lists is a fastspin extension
    DS3231RTC_P2_V2.spin:104: warning: () for empty parameter lists is a fastspin extension
    DS3231RTC_P2_V2.spin:113: warning: () for empty parameter lists is a fastspin extension
    DS3231RTC_P2_V2.spin:125: warning: () for empty parameter lists is a fastspin extension
    DS3231RTC_P2_V2.spin:148: warning: () for empty parameter lists is a fastspin extension
    DS3231RTC_P2_V2.spin:372: warning: () for empty parameter lists is a fastspin extension
    DS3231RTC_P2_V2.spin:167: warning: definition of tmp hides a member variable
    DS3231RTC_P2_V2.spin:191: warning: definition of tmp hides a member variable
    DS3231RTC_P2_V2.spin:217: warning: definition of tmp hides a member variable
    d:\Flex2Gui\flexgui\P2 Libs\DHT22LibP2.bas:266: warning: signed/unsigned comparison may not work properly
    d:\Flex2Gui\flexgui\P2 Libs\DHT22LibP2.bas:273: warning: signed/unsigned comparison may not work properly
    d:\Flex2Gui\flexgui\P2 Libs\StringLibP2.bas:275: warning: definition of cnt hides a member variable
    d:\Flex2Gui\flexgui\P2 Libs\StringLibP2.bas:620: warning: definition of cnt hides a member variable
    d:/Flex2Gui/flexgui/P2 Libs/Library Test Code/GPS-RTC-Serial-TestP2.bas:475: warning: definition of unixStamp hides a member variable
    d:/Flex2Gui/flexgui/P2 Libs/Library Test Code/GPS-RTC-Serial-TestP2.bas:740: warning: definition of unixStamp hides a member variable
    d:/Flex2Gui/flexgui/P2 Libs/Library Test Code/GPS-RTC-Serial-TestP2.bas:804: warning: definition of msg$ hides a member variable
    d:/Flex2Gui/flexgui/P2 Libs/Library Test Code/GPS-RTC-Serial-TestP2.bas:821: warning: definition of msg$ hides a member variable
    d:/Flex2Gui/flexgui/P2 Libs/Library Test Code/GPS-RTC-Serial-TestP2.bas:287: warning: signed/unsigned comparison may not work properly
    d:/Flex2Gui/flexgui/include/libsys/fmt.c:695: warning: incompatible pointer types in parameter passing
    
  • garryjgarryj Posts: 322
    edited 2020-07-22 - 19:42:10
    I've run into a snag with the 4.2.5 fastspin.exe that's a bit beyond my ability to find the exact cause. The attached zip file has my "Preview" USB keyboard/mouse demo that builds and runs with PNut v34u and fastspin v4.2.4. With fastspin v4.2.5, it builds with no errors and the serial and control objects work, but when the USB object (spin2 + p2asm) loads and starts it goes off into the ether, so I suspect that it is likely an addressing issue. The zip file includes .lst files for each fastspin version, if that helps.

    I'm using Win10 with a P2 Eval RevB, with Parallax "Serial Host" (pin block 16) and "Control" (pin block 24) addon boards. The top object USBB_BASEPIN constant must be edited and the ctrl.start(ctrl.BASEPIN_*) call on line 103 for the control board. The control board is optional, but is useful for testing the USB reset and suspend/resume features.

    The "KbMObjPreview.spin2" should build/run using the FlexGUI default P2 parameters.

    @rogloh, it's way overdue, but this code should be stable enough for you to give it a whirl, if you'd like!
  • Garry: I can't seem to get any of my keyboards or mice to be recognized (no matter which version of fastspin I use :( ). I'll have to dig around to see if I have some other USB keyboards; I know at one time I had one that worked.

    In the meantime, when you say "it goes off into the ether" do you mean that it looks to be running (LED status blinking, etc.) but just never responds?
  • The USB's long repository smartpin that passes event IDs to the client is no longer working. I remember that you had mentioned recently that a change was made regarding inline asm in fastspin?
    I am using inline asm to poll/read the long repository data. So far, this is the best lead I have and I'll look into it asap.
  • @garryj, thanks I'll try to give it a go when I get another chance, although I am already using 4.2.5 too so it might not work for me either. Right now I'm using your existing driver experimenting with a simple gfx+mouse GUI with HyperRAM using fastspin. It's working quite nicely but I'm certainly getting tired of changing the clock setting in 1CogKbM.spin and recompiling it for each different video resolution I use (because they typically each operate at a different P2 frequency), so if that change is part of your latest version too that will be great. :smile:
  • garryjgarryj Posts: 322
    edited 2020-07-23 - 02:02:03
    There's a fastspin_v_2_4.exe in the zip if you want to give it a go.
    Edit: @rogloh Yes, changing clock settings and suspend/resume are functional.
  • I forgot to change the ACC HDR jumper on my board to 5V; d'oh! After that change I was able to find a mouse that worked and tracked down the bug (I think). Here's a new fastspin binary that should work to compile things.

    Thanks for the bug report!
  • ersmith wrote: »
    I forgot to change the ACC HDR jumper on my board to 5V; d'oh! After that change I was able to find a mouse that worked and tracked down the bug (I think). Here's a new fastspin binary that should work to compile things.

    Thanks for the bug report!

    Unfortunately, no. I've replaced the inline assembly with Spin2 built-in methods. PNut is still happy, but v4_2_5 and the new version throw this error when compiling:
    "O:/OneDrive/Prop2/flexgui/bin/fastspin" -2 -l -D_BAUD=230400 -O1  -I "O:/OneDrive/Prop2/flexgui/include"  "F:/Development/Repos/ZipTest/1CogKbMObjPreview/KbMObjPreview.spin2"
    Propeller Spin/PASM Compiler 'FastSpin' (c) 2011-2020 Total Spectrum Software Inc.
    Version 4.2.6-beta-v4.2.1-135-g40064f8e Compiled on: Jul 22 2020
    KbMObjPreview.spin2
    |-jm_serial.spin2
    |-|-jm_nstr.spin2
    |-1CogKbM.spin2
    |-CtrlAddon.spin2
    KbMObjPreview.p2asm
    Done.
    F:/Development/Repos/ZipTest/1CogKbMObjPreview/KbMObjPreview.p2asm:489: error: Unknown symbol _1CogKbM_eventCheck
    child process exited abnormally
    Finished at Wed Jul 22 20:15:39 2020
    
    The USB object's "eventCheck()" is the method that originally had the inline assembly. It being the only method that fastspin flagged as "unknown" is a strange coincident...
    Here's a new .zip that includes a PNut binary, the above .P2asm file and the updated Spin2 sources.
    I hope this helps.
  • Ah, another bug. Thanks for your patience and for reporting this. I think it's fixed now, and here's a newer version.
  • ersmith wrote: »
    Ah, another bug. Thanks for your patience and for reporting this. I think it's fixed now, and here's a newer version.
    Back in the saddle again. Thank you, sir, for the quick find/fix 👍!
  • garryjgarryj Posts: 322
    edited 2020-07-23 - 20:33:12
    Oops, spoke too soon. It looks like there may be an issue with byte/word/long overrides.
    I have these routines in 1CogKbm.spin2:
    '' Get new key from the buffer, zero if no key (never waits).
    '-+-------------------+---------------+----------+-------------+
    ' |       Byte3       |     Byte2     |   Byte1  |    Byte0    |
    '-+-------------------+---------------+----------+-------------+
    ' | Toggle Key States | Modkey States | Scancode | ASCII Value |
    '-+-------------------+---------------+----------+-------------+
    PUB rawKey() : data
      if kbd_tail <> kbd_head
        data := kbd_buffer[kbd_tail]
        kbd_tail := ++kbd_tail & KBD_BUFFMASK
    
    '' Get a new key from the buffer. Combine the left/right CTRL, ALT, SHIFT keys
    '' and the "Application" key scan codes to make it easier to set up a CASE
    '' block using a [modifier(s)|scancode] WORD.
    '-+-------------------+-------------+--------------------+----------+
    ' |       Byte3       |    Byte2    |  Byte1, bits 3..0  |   Byte0  |
    '-+-------------------+-------------+--------------------+----------+
    ' | Toggle Key States | ASCII Value | APP|ALT|CTRL|SHIFT | Scancode |
    '-+-------------------+-------------+--------------------+----------+
    PUB key() : data | tmp
      if kbd_tail <> kbd_head
        tmp := kbd_buffer[kbd_tail]
        kbd_tail := ++kbd_tail & KBD_BUFFMASK
        dbgData := tmp
        data.byte[3] := tmp.byte[3]
        data.byte[2] := tmp.byte[0]
        if (tmp.byte[2] & KEYS_APP)
          data += 1 << 11
        if (tmp.byte[2] & KEYS_ALT)
          data += 1 << 10
        if (tmp.byte[2] & KEYS_CTRL)
          data += 1 << 9
        if (tmp.byte[2] & KEYS_SHIFT)
          data += 1 << 8
        data += tmp.byte[1]
    
    And the client unpack method:
    PRI handleKbdData(keydata) | asciival, tglstates
      asciival := keydata.byte[2]
      tglstates := keydata.byte[3]
    
      case keydata.word[0]
        usb1.KEY_BKSPACE:
          ser.str(@szbackspace)
        usb1.KEY_ENTER, usb1.KEY_KPENTER:
          ser.str(nlPtr)
        usb1.KEY_CAPSLK, usb1.KEY_SCRLK, usb1.KEY_KPNUMLK:
          ser.tx(ser.BELL)                                  ' Ring the terminal bell on toggle key state change
        CTRL_A_ANSILOVE:
          showAnsiLove()
          ser.fstr2(string("Raw keydata: $%8.8x%s"), usb1.getDebugData(), nlPtr)
          ser.fstr4(string("keydata: $%8.8x, asciival: $%x, tglstates: $%x%s"), keydata, asciival, tglstates, nlPtr)
        CTRL_E_CLS:
          case termType
            ANSI: ser.fstr2(string("%c[H%1c[J"), ESC, ESC)
            PST:  ser.tx(0)
        CTRL_ALT_SHIFT_R_URESET:
          resetUSB()
        CTRL_ALT_SHIFT_S_SYSCLK:
          setSysClock(long[freqPtr], long[freqPtr + modePtr])
        usb1.KEY_F1:
          ser.fstr1(string("HELP!!!%s"), nlPtr)
        CTRL_KEY_LEFT: nextSysclk(-1)
        CTRL_KEY_RIGHT: nextSysclk(1)
        other:
          ser.tx(asciival)
    
    The screenshots show the "raw" keyboard data and the byte-shifted, more client-friendly, format emitted by PNut and fastspin Version 4.2.6-beta-v4.2.1-137. PNut is as expected:
    819 x 832 - 31K
    819 x 832 - 31K
  • Ha, I pestered Eric to add optimization for x.word[1], he added optimization for both word and byte overrides and then everyone proceeded to not test the byte overrides.
  • Wuerfel_21 wrote: »
    Ha, I pestered Eric to add optimization for x.word[1], he added optimization for both word and byte overrides and then everyone proceeded to not test the byte overrides.

    Nah, I tested the byte overrides. The problem was I tested both byte and word overrides for read only. It didn't occur to me that my changes to optimize reads would break the writes :(.

    So, here goes another version. Let's hope it's 3rd time lucky!
  • Eric,
    Today I noticed that v4.2.5 is reporting errors with line numbers one line out. Forget which way around.
    BTW I like the extra warnings on the pin instructions if # is missing. So I added the obligatory-0 and all was fine :)
  • Cluso99 wrote: »
    Today I noticed that v4.2.5 is reporting errors with line numbers one line out. Forget which way around.
    You'll have to be more specific, I'm afraid. I definitely know that not all errors are one line out, because there are tests in the automatic test suite which verify a selection of them and those haven't changed.

    It is likely that some of the new warnings about Spin2 syntax differences are off by one, because the parser is already on the next line before we get to discovering those difference. I'm not sure how much effort it's worth putting in to fixing those.
    BTW I like the extra warnings on the pin instructions if # is missing. So I added the obligatory-0 and all was fine :)

    :)

  • ersmith wrote: »
    Nah, I tested the byte overrides. The problem was I tested both byte and word overrides for read only. It didn't occur to me that my changes to optimize reads would break the writes :(.

    So, here goes another version. Let's hope it's 3rd time lucky!
    Yep, the 3rd time was a charm 😊.
    And testing your fix exposed a couple more bugs of my own 😒.
  • Eric,
    Most, if not all, were indeed the new format warnings where the line numbers were 1 out. I will recheck over the w/e. It’s not a problem as long as you realise it could be a line out.
  • Eric,
    Just confirmed that the usual errors report the correct line number.

    Not sure how pedantic you want to be with fastspin error reporting? Let me know if this is the sought of thing you want to know, or if you have more important things to do please.

    This line is missing a ",".
        if_nc     mov       ledpin,           ##LED_p2d2     '|
    
    The error message is (which is indeed the error) but a "missing comma" may be more appropriate???
    pasmdemo.spin2:61: error: syntax error, unexpected '#', expecting identifier or RESULT
    
  • @ersmith When coding in FlexBASIC v4.2.5 under Win10:

    I have spent the last couple of days weeding-out literally hundreds of warnings in my libraries that the -Wall flag has uncovered. I'm mostly there except for the following error that occurs in fmt.c:
    D:/Flex2Gui/flexgui/include/libsys/fmt.c:695: warning: incompatible pointer types in parameter passing
    
    I'm not much of a C-type, and I'm not seeing the error the compiler sees. Here is the offending routine from fmc.c:
    int _basic_open_string(unsigned h, char *fname, unsigned iomode)
    {
        vfs_file_t *v;
        int r;
        
        v = __getftab(h);
        if (!v) return -1;
    
        r = _openraw(v, fname, iomode, 0666);   ' <---- This is the error line #695
        return r;
    }
    
  • It's probably the vfs_file_t type for pointer v. If you're sure it's correct then look up what openraw() is expecting and cast to it. eg: If openraw() wants a char * for the first pointer type then do this:
    r = _openraw((char *)v, fname, iomode, 0666); 
    
  • @Cluso99 : The parser is automatically generated by YACC, so I'm afraid there's not a lot I can do to improve syntax errors. But thanks for the suggestion, and if I can think of a way to implement it I will.

    @JRoark : I think the definitions for vfs_file_t end up different between submodules and the main module -- not actually different, but because they're in different modules one is treated differently :(. I've hacked around it for now by using void * (basically C's equivalent to the ANY type).
Sign In or Register to comment.