Shop OBEX P1 Docs P2 Docs Learn Events
FlexProp: a complete programming system for P2 (and P1) - Page 52 — Parallax Forums

FlexProp: a complete programming system for P2 (and P1)

14950525455

Comments

  • JonnyMacJonnyMac Posts: 9,083
    edited 2023-09-23 17:35

    Thanks. As I tend to be very verbose with code, anyway, I modified that routine like this so it doesn't count on the return variable being preset.

    pub enqueue(c) : done
    
    '' Add c to input buffer
    '' -- returns true when terminating char encountered
    
      if (c == 0) || (c == tchar)                                   ' end of input?
        buffer[bidx] := 0                                           '  terminate buffer
        return true                                                 '  let caller know
    
      if (c == 8) && (bidx > 0)                                     ' if backspace and chars in buffer
        buffer[--bidx] := 0                                         '  erase last
        return false
    
      if (bidx < BUF_SIZE-2)                                        ' room in buffer
        if (alphacase == LOWER)                                     '  case setting?
          c := lcase(c)
        elseif (alphacase == UPPER)
          c := ucase(c)
        buffer[bidx++] := c                                         ' add to buffer
    
      return false                                                  ' not done
    
  • Yes, there was a bug in 6.4.0 (and many previous versions) where case statements confused the compiler variable initialization code. That is fixed in 6.5.0.

    In general it's probably best to explicitly initialize variables. The flexspin optimizer wants to initialize them only when it can prove that they aren't set by the user, but it gets it wrong sometimes :(. I guess we could disable that and always initialize everything to 0, but that's actually somewhat expensive (relatively speaking).

  • As mentioned above, there is a new release for FlexProp (6.5.0) which comes with the newest Parallax flash file system, a revised loadp2 loader which can pass command line arguments, DATE/TIME functions for BASIC, the new Spin2 REPEAT n WITH i syntax, and numerous bug fixes.

    The flash file system is used in the samples/shell sample, which sets up a basic command line and allows you to copy files between SD, flash, RAM disk, and the host PC. By default just the host PC is mounted, you have to explicitly mount and unmount the other file systems (because SD and flash cannot both be used at the same time). The file systems built in to the shell are:

    /host   - the host PC file system, accessed over serial
    /pfs    - the flash formatted with the Parallax file system
    /sd     - the SD card formatted with FAT32
    /flash  - the flash formatted with ARM's littlefs
    /ram    - the Edge 32MB RAM formatted with littlefs
    

    You can use different RAMs for the /ram file system, but you'll have to edit shell.c to do so (I've tested the HyperRam module and a 4bit PSRAM; you can also use HUB RAM but there's not much room there).

  • New Xcode released yesturday.

    mcpp/mcpp_support.c:300:18: error: call to undeclared library function 'vsnprintf' with type 'int (char *, unsigned long, const char *, struct __va_list_tag *)'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
    rc = vsnprintf( mem_buffer, sizeof(mem_buffer), format, ap);
    ^
    mcpp/mcpp_support.c:300:18: note: include the header <stdio.h> or explicitly provide a declaration for 'vsnprintf'
    1 error generated.
    make[1]: *** [build/mcpp_support.o] Error 1
    make: *** [spin2cpp/build/flexspin] Error 2

  • @"Greg LaPolla" : stdio.h is included by "configed.H", which is included by "system.H" near the top of mcpp/mcpp_support.c. It looks like Apple may have broken their stdio.h. It wouldn't be the first time :(. I do provide pre-built binaries for MacOS, which are made with an older version of the SDK.

  • @"Greg LaPolla" : Actually I do get the vnsprintf problem even on an older SDK if I use stricter compilation flags. I don't quite understand what's going on; maybe the Apple SDK treats #include "stdio.h" and #include <stdio.h> differently? Anyway, I've checked in some updated sources that pass when much stricter compilation flags are given and which fix some warnings on different platforms.

  • @ersmith said:
    [...]maybe the Apple SDK treats #include "stdio.h" and #include <stdio.h> differently? [...]

    Sorry, but that's the normal way: <systemheader.h>, "usercodeheader.h"
    So if "stdio.h" is not in usercode it is not found. Some compilers/preprocessers may search in system folders if not found in usercode, but if not it is your fault.

  • @dnalor said:

    @ersmith said:
    [...]maybe the Apple SDK treats #include "stdio.h" and #include <stdio.h> differently? [...]

    Sorry, but that's the normal way: <systemheader.h>, "usercodeheader.h"

    I should have been more specific: of course those two are different, but the error isn't that "stdio.h" is not found, it is that the header file is behaving differently in the two cases. (I think virtually every compiler will search the standard system paths in the event of a user header not being found.)

    Something is definitely messed up. Anyway, adding an explicit #include <stdio.h> seems to fix it, so whatever.

  • Sorry for misunderstanding. But doesn't this tell, that <stdio.h> is not included:

    @"Greg LaPolla" said:
    New Xcode released yesturday.

    mcpp/mcpp_support.c:300:18: error: call to undeclared library function 'vsnprintf' with type 'int (char *, unsigned long, const char *, struct __va_list_tag *)'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
    rc = vsnprintf( mem_buffer, sizeof(mem_buffer), format, ap);
    ^
    mcpp/mcpp_support.c:300:18: note: include the header <stdio.h> or explicitly provide a declaration for 'vsnprintf'
    1 error generated.
    make[1]: *** [build/mcpp_support.o] Error 1
    make: *** [spin2cpp/build/flexspin] Error 2

    I agree that most compiler will search in system path, I saw "stdio.h" very often. Personally, I am very accurate about including my own header files or system headers.

  • @ersmith,

    Did a fresh pull from git, still get the same error. Tried to change to <stdio.h> same result.

  • @"Greg LaPolla" : which repo are you working with? The flexprop one still points at the old compiler code, so you'll have to manually update the spin2cpp sub-repo of it to get my changes. Or, you could try adding a #include <stdio.h> to the very top of the mcpp_support.c file.

  • @ersmith,

    I have an application I am working on that compiles and runs from proptool and spintools. Flexprop compiles clean and uploads to the prop but doesn't run. I am not a compiler guru so I have no idea what is going on. Is there anything I can send you to assist ?

  • @"Greg LaPolla" said:
    @ersmith,

    I have an application I am working on that compiles and runs from proptool and spintools. Flexprop compiles clean and uploads to the prop but doesn't run. I am not a compiler guru so I have no idea what is going on. Is there anything I can send you to assist ?

    Are you able to send the application source code, in a form that can run without any special hardware? That would be the easiest way for me to debug. Otherwise have you tried disabling optimization? Sometimes that helps if the bug is in the optimizer.

  • @ersmith

    Sent link to download code in PM

  • I've uploaded FlexProp 6.6.0 to my Patreon page. This has some new -gbrk debug features (pc_key and pc_mouse) and proper boolean types for C and BASIC.

  • RaymanRayman Posts: 14,517

    Wasn’t there already bool in your C?

  • @ersmith,

    When trying to compile to bytecode I get the following error:

    error: Internal error, unknown type 2 passed to TypeSize

    Running version: Version 6.5.2-HEAD-v6.5.2 Compiled on: Oct 21 2023

    Compile command:

    "%D/bin/flexspin" -2nu -l --tabs=%t -D_BAUD=%r %O %I "%S"

  • There's a bug in compiling some method calls in bytecode. It will be fixed in the next version of the compiler. In the meantime the workaround is to add explicit :0 notations on the end of all the function pointer calls in Graphics.spin2, e.g. change

    PUB set_foreground_color(bgr)
      _set_foreground_color(bgr)
    

    to

    PUB set_foreground_color(bgr)
      _set_foreground_color(bgr):0
    

    and similarly for all of the other wrapper functions in that file. This should also work fine with PNut (at least PNut v39 seems to compile these OK).

  • @ersmith

    That fixed the compile error but the code still doesn't run. I am not sure if the flexspin compiler is based off the same compiler @macca uses, but he fixed the issue in spin tools and said it was an issue with the object method index address.

  • jaspastjaspast Posts: 12
    edited 2023-10-30 06:05

    I'm having trouble setting a custom _XTALFREQ in cdemo.c. The board I'm using has a 25 MHz crystal. However, no matter what I do, my LED blinks at the same rate. Furthermore, I can only communicate over serial if I set my terminal to a speed of 288_000 (which is 230_400 * 5/4).

    #define _XTALFREQ   25000000
    
    enum {
        _clkfreq = 180000000,
    };
    
    #include <stdio.h>
    #include <propeller.h>
    
    #define PIN 57
    
    void main()
    {
        unsigned int pinmask = 1<<(PIN-32);
        unsigned i = 0;
    
        DIRB |= pinmask; // set pins as output
        for(;;) {
            OUTB ^= pinmask;
            waitcnt(getcnt() + _clkfreq/4);
            printf("Toggle %u\n", i++);
        }
    }
    

    Edit: Flexprop 6.6.1 on Windows 11

  • evanhevanh Posts: 15,828

    Hehe, haven't seem quite that mistake before.

    Try this (without the #define):

    enum {
        _xtlfreq = 25_000_000,
        _clkfreq = 180_000_000,
    };
    

    If using a buffered crystal oscillator instead of a raw crystal:

    enum {
        _xinfreq = 25_000_000,
        _clkfreq = 180_000_000,
    };
    
  • Setting crystal frequency, like setting clock frequency, must be done with an enum:

    enum { _xtlfreq = 25000000, _clkfreq = 180000000 };
    

    Note that there is no letter A in _xtlfreq.

    The C #define directive does not affect anything outside of the file, and only can define a text substitution macro. That's why we have to use enum to define global constants like the clock frequency.

  • Wow. Thanks @evanh and @ersmith!

    I spent so much time on that. Glad it's behind me now.

  • RaymanRayman Posts: 14,517

    I'm a bit surprised that the compiler doesn't give a warning when initializing a static structure with index beyond what is declared...

    I had this:

    #define EveCount 2  //How many screens do we have?
    
    struct EveType Eves[EveCount];
    

    Then, later on this:

    //See DisplaySettings.h for info on types
    void DefineDisplays()  //Call this function to define attached displays
    {
        //Bottom Left
        Eves[0].CS = 27;
    
    ...
        //Top-Center
        Eves[2].CS = 27 + 10;
    ...
    }
    

    Doesn't give an error or warning on Eves[2] even though obviously bad, right?
    My Visual Studio editor doesn't flag it as wrong either, so maybe it's just something that can't be given a warning on?

  • RaymanRayman Posts: 14,517

    Got some code here that I just had to dial FlexProp back to 5.9.5 to make work...

    There are two versions of SPI, cogged (in Spin2) and not-cogged (in C).
    The C version still works.
    But, the Spin2 version does not with 5.9.20 and on.
    Thinking some change in between those broke it, but don't see how.

    Any ideas @ersmith ?

  • evanhevanh Posts: 15,828
    edited 2023-11-03 20:08

    @Rayman said:
    But, the Spin2 version does not with 5.9.20 and on.

    I can compile SPI.spin2 with Flexspin v6.5 without any error messages. What is the expected problem?

    EDIT: I note it looks a little wonky being in UTF-16 encoding. Maybe re-encoding it might help.

  • @Rayman : when you say "does not work" could you be a bit more specific? Does it fail to compile for you? Does it compile but not run correctly? If the latter, what are the symptoms?

    The archive you sent did not have helloworld.c in it, so I can't compile exactly what you are compiling, but the individual pieces all seem to compile OK for me with flexspin 6.6.1.

  • @Rayman said:
    I'm a bit surprised that the compiler doesn't give a warning when initializing a static structure with index beyond what is declared...

    That's fairly common for C compilers (C actually lets you index wherever you want in an array, and it's up to you to make sure it's within bounds). That said, I will add a warning for this case (it'll be useful for BASIC, where you really shouldn't be trying to reference an array out of bounds).

  • RaymanRayman Posts: 14,517

    @ersmith I may have spoke up too soon. On a different computer with another copy of the hardware, it works with 6.1.1 and 6.4.0.

    When it doesn't work on the other computer, it tries to read the FTDI EVE chip ID and gets 0 instead of what it is supposed to be.

    So, not sure you can help until I can pin this down some more...

Sign In or Register to comment.