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

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

1262729313238

Comments

  • ersmithersmith Posts: 5,498

    @pilot0315 said:
    @ersmith

    The tab setting change appears to have fixed the problem in FlexProp.
    I do have a question with the Proptool 2.6.2
    I am trying to receive data asynchronous from a gps. I did it fine in Prop C on the P1. Trying in P2 Spin but I cannot get the rx to work with the jmfullduplexserial. Attempting to use simple serial in a second cog for receiving and pass the data as my next move. But for simplicity launching FDS twice with two different nick names should work. The rx in the jm version does not seem to work.
    Any suggestions.
    Thanks
    Martin

    This isn't a good place to ask questions about Proptool, as it's focused specifically on Flexprop and the people who know the most about Proptool may not be reading. I'd start a different thread to ask about your serial problems. Include as much detail as you can (ideally the code)! Saying "I cannot get the rx to work" is kind of like saying "I can't get my airplane to take off"; there's not nearly enough information there to diagnose the problem. What kind of airplane is it? Does the engine start? Are there warning lights of any sort? Can the plane taxi? There are so many questions... ideally you would take us out to the plane and show us the problem (i.e. share the code) so we can see exactly what you're trying.

    So my suggestion is: start a new thread, post your code there and what you're seeing (any messages from the compiler, behavior when you try to run, etc.).

  • @ersmith
    Thanks for the suggestion. I will do that. I like your airplane analogy. :D

  • pik33pik33 Posts: 1,797

    Is it possible - in Linux environment - to prevent running more than one copy of Flexprop at once?

  • RaymanRayman Posts: 12,914

    There's some strange coding style giving me trouble, converting code from Arduino..

    void SetHeight(int height) {
        height = height;
    }
    
    

    So, there's a global variable called height and local variable with same name.
    I don't know how the Arduino compiler figures out which one to use but FlexProp C doesn't seem to get it the same way...

  • @Rayman said:
    There's some strange coding style giving me trouble, converting code from Arduino..

    void SetHeight(int height) {
        height = height;
    }
    
    

    So, there's a global variable called height and local variable with same name.
    I don't know how the Arduino compiler figures out which one to use but FlexProp C doesn't seem to get it the same way...

    I think that's just... Not a thing that actually works? Like, you sure the code is good to begin with?

  • RaymanRayman Posts: 12,914
    edited 2022-01-29 23:08

    @Wuerfel_21 It's from Seeed Studio Github for 2.7" E-Ink display. I'm pretty sure it works (somehow).

    @ersmith Maybe you don't have time for this, but this code is doing something I don't understand...
    I'm telling it the height and width variable settings with Paint() and also SetWidth() and SetHeight() in the Demo() function in 3Color_EInk.c.
    But, it seems to be just ignoring that and somehow getting the value of the full screen resolution (176x264).

    This code is using a smaller than full screen buffer because the Arduino doesn't have enough ram for full screen buffer (1 bit per pixel).
    By making the buffer bigger, I made it not crash and it actually works, but not how it's supposed to.

    Anyway, next job is to actually ask for full screen buffer, so maybe it doesn't matter.
    But, it's some really strange behavior...

    Update: Okay, turns out it wasn't actually making a new binary when all the .c files were on the build line.
    Moved them back as #include and now it works...

  • RaymanRayman Posts: 12,914
    edited 2022-01-29 23:15

    Ok, figured out it wasn't actually making a new binary, even though it said it was...
    This is the command line:
    C:\FlexProp\bin\flexspin.exe -2 -L C:\FlexProp\include epdif.c epd2in7b.c epdpaint.c 3Color_EInk.c

    I was previously using #include on the other .c files, guess I'll switch back to that...

    Ok, maybe this was operator error... I just noticed there's an epdif.binary.
    Guess the first file decides the output filename... Thought it was the last one...

  • ersmithersmith Posts: 5,498

    @Rayman said:
    Ok, maybe this was operator error... I just noticed there's an epdif.binary.
    Guess the first file decides the output filename... Thought it was the last one...

    It is the first one. But if you want to be sure, you can add "-o SomeOutputFileName.binary" to the command line to explicitly specify what output name you want.

    Is everything else sorted out? I kind of lost track of the comments above.

  • RaymanRayman Posts: 12,914

    Yes, all good now
    Thanks

  • ersmithersmith Posts: 5,498

    @pik33 said:
    Is it possible - in Linux environment - to prevent running more than one copy of Flexprop at once?

    I don't think there's any easy way to do that. Actually it might be useful to run multiple copies, if you have multiple propellers (e.g. one for the P2 and one for the P1).

  • RaymanRayman Posts: 12,914

    Does mount() return anything that tells you if it worked?

    Maybe this?

    /* Results of Disk Functions /
    typedef enum {
    RES_OK = 0, /
    0: Successful /
    RES_ERROR, /
    1: R/W Error /
    RES_WRPRT, /
    2: Write Protected /
    RES_NOTRDY, /
    3: Not Ready /
    RES_PARERR /
    4: Invalid Parameter */
    } DRESULT;

  • ersmithersmith Posts: 5,498

    mount(), like most disk functions, returns 0 on success and a negative number on failure. In the latter case more detail on the error is put in "errno"; the file <errno.h> has a list of defines for error conditions.

  • ersmithersmith Posts: 5,498

    I've released FlexProp 5.9.8. This has some major changes, particularly in the GUI, and so it probably has a few rough edges. But the benefits are substantial too, I think. The new GUI features include:

    • An option to use a default built in terminal (either ANSI or PST compatible) instead of the external terminal (which is still an option, but the internal ANSI terminal is the default).
    • Preliminary support for the Spin2 TERM and PLOT windows. BITMAP and SCOPE will be coming soon, I hope, with the rest of the DEBUG windows to follow eventually.
    • Support for programming P2s over WiFi, based on the proploader changes made by @VonSzarvas This does mean that proploader is now the default terminal program, rather than loadp2, which again is a pretty big change (although loadp2 is still included in the distribution, so it's possible to switch back to it).
    • Default tab width is now 8 rather than 4, for backwards compatibility with Spin programs
    • The config file for this release is called ".flexprop6.config" rather than ".flexprop.config", so it can co-exist with older releases; but it means that FlexProp 5.9.8 will start fresh without any of your font and other settings.

    The compiler also has a number of changes, including:

    • Added some more bit-banging optimizations (e.g. bith/bitl -> bitc)
    • Added a new optimization for simple FOR loops with constant bounds
    • Added special function optimizations for pinread/pinwrite
    • Added SIZEOF operator to BASIC
    • Added BITREV function to BASIC
    • Added ALIAS, DECLARE, EXTERN, LINE, and LIB keywords to BASIC
    • Added support for DLY() to default -g debugging
    • Added #pragma ignore_case directive to the preprocessor
    • Added DECLARE ALIAS to BASIC
    • Allowed printing of pointers in BASIC
    • Changed default runtime tests to use P2 instead of P1
    • Fixed a few missing definitions in <propeller.h>
    • Fixed a problem with SendRecvDevice() in BASIC
    • Fixed an incorrect optimization for loops containing GOSUB
    • Fixed multiple args in DEBUG() statements with -gbrk
    • Fixed a problem with extern declarations in C not working in .o files
    • Fixed in bug in mis-detecting use of result values in bytecode output
    • Fixed a nasty bug for functions with more than 99 local registers used
    • Fixed a bug in DIR$() in subdirectories of SD cards
    • Fixed printing of values passed by reference
    • Improved C++ compatibility for class functions, including supporting "static" in classes and declarations of functions outside the class
    • Made RESULT no longer a reserved word in Spin2, should fix a number of bugs
    • Optimized local variable push/pull (thanks Ada)
    • Reduced number of temporary registers needed by the compiler
  • JRoarkJRoark Posts: 1,131

    Wowzers. @ersmith has been BUSY! 👍

  • @ersmith said:

    • Preliminary support for the Spin2 TERM and PLOT windows. BITMAP and **SCOPE **will be coming soon, I hope, with the rest of the DEBUG windows to follow eventually.

    :)B):)<3

  • RsadeikaRsadeika Posts: 3,685

    In my Win 10 Pro setup, the new flexprop GUI 'Compile and flash', is not writing to flash.

    Ray

  • ersmithersmith Posts: 5,498

    @Rsadeika said:
    In my Win 10 Pro setup, the new flexprop GUI 'Compile and flash', is not writing to flash.

    Ray

    What is it doing? Can you give us any more information about your setup -- are you using WiFi or Serial, Internal or External terminal, are there any messages printed? Can you run ordinary programs? What are the DIP switch settings on your board (and what kind of P2 board are you using)? Forgetting to set the DIP switches is a common reason for flash failures.

  • pik33pik33 Posts: 1,797
    edited 2022-02-03 15:17

    I have some glitches in serial terminal in Linux (Xubuntu 20.04):

    • 2 Mbps is "not stable" - sometimes uploads fast, sometimes much slower
    • debug(udec(something)) where this something is fast displays garbage on the internal terminal while on the external terminal it works. Also, while the internal terminal works in most cases uploading and flashing programs, it can sometimes fail to flash. The workaround, if it happens - as in the debug - was to use the external terminal.
  • whickerwhicker Posts: 739
    edited 2022-02-05 03:49

    I'm also seeing issues with the prop loader. I realize it's probably not a flexprop complier problem, but proploader is pretty obtuse.

    It claims download was successful, but the P2 only starts up maybe 1 in 5 attempts. The last thing in the terminal window says is that it found a revision G prop 2.

    I'm using the older P1 era style prop plug on the edge mini breakout with Windows 10, which wasn't a problem before. Baud rate doesn't seem to affect the odds as I've tried all of them from the flexprop gui drop down menu. And then pressed the "compile and run on P2" button for 10 trials in a row with a simple blink program. It actually started in about 2 to 4 times, out of 10 tries.

  • dgatelydgately Posts: 1,540

    @whicker said:
    I'm also seeing issues with the prop loader. I realize it's probably not a flexprop complier problem, but proploader is pretty obtuse.

    It claims download was successful, but the P2 only starts up maybe 1 in 5 attempts. The last thing in the terminal window says is that it found a revision G prop 2.

    I'm seeing similar problems with the most recent proploader, as well... I get 2-4 failed uploads before a successful upload to the P2. That's for a "Compile & Run on P2"... And, "Compile & Flash", although stating a successful upload, results in a reset of the P2 and it runs previously saved code from flash (i.e. the new binary does NOT get uploaded). This has been true for both wired (USB) and WiFi uploads.

    version info:

    PropLoader (totalspectrum branch) v1.9-1 (2022-01-31 14:10:10 g48e7aeb)
    

    dgately

  • AribaAriba Posts: 2,599

    My problem with PropLoader is that it it does not support reset by RTS.
    Just toggle RTS together with DTR for a reset, no extra commandline switch needed.

    Andy

  • JRoarkJRoark Posts: 1,131

    @whicker said:
    I'm also seeing issues with the prop loader.
    It claims download was successful, but the P2 only starts up maybe 1 in 5 attempts. The last thing in the terminal window says is that it found a revision G prop 2.

    Same issue here. Running under Win10 with a Rev B Eval board. I have tried all 16 combos of dip switches on the board with no joy. My interim solution is to use the old loader from 3 versions of FlexProp ago. This gets me back to working again, but the GUI is unresponsive while the terminal window is open (ie, the terminal window is modal to the GUI window).

  • Same issue here under MacOS with a mini breakout board with either a direct serial connection or via WiFi. Most times I try to program into flash, it claims download was successful, but the flash still contains the previous version. I can Compile & Run

  • RS_JimRS_Jim Posts: 1,614
    edited 2022-02-04 21:45

    Flexprop 5.9.8 install issues.
    followed the script exactly to make 5.9.8 on a linux Mint vr 20 . Ran the makefile, made the new flexprop DIR but it contains no flexprop. type cd flexprop and it goes to the directory. type "./flexprop" get "no such file or directory. I was sort of looking to trying out the debug commands.
    Jim

  • ersmithersmith Posts: 5,498

    If you're having a problem with FlexProp, particularly with serial downloads, please let me know the operating system you're using. Mac, Linux, and Windows all use different serial drivers, and it's hard to debug these because they're timing dependent.

    As for flash not working, of course it does here for me (on all of my OSes) :(. I have heard that what is programmed into the flash might matter, e.g. if it uses serial or SPI pins then there might be an issue. I haven't been able to confirm this, but it's worth investigating -- if you can change what you have in your flash, and/or report what it is, that might be helpful.

  • ersmithersmith Posts: 5,498

    @Ariba said:
    My problem with PropLoader is that it it does not support reset by RTS.
    Just toggle RTS together with DTR for a reset, no extra commandline switch needed.

    I believe that adding the command line option "-D reset=rts" makes proploader use RTS reset instead of DTR.

  • ersmithersmith Posts: 5,498

    @RS_Jim said:
    Flexprop 5.9.8 install issues.
    followed the script exactly to make 5.9.8 on a linux Mint vr 20 . Ran the makefile, made the new flexprop DIR but it contains no flexprop. type cd flexprop and it goes to the directory. type "./flexprop" get "no such file or directory. I was sort of looking to trying out the debug commands.

    What errors did you get when you ran "make install"? If it was:

    /bin/sh: 1: tclsh: not found
    

    you can fix this by replacing the two instances of the word "tclsh" in the Makefile with "tclsh8.6". For some reason Linux Mint does not include an alias for tclsh, but installing tk8.6-dev does install tclsh8.6.

  • AribaAriba Posts: 2,599

    @ersmith said:

    @Ariba said:
    My problem with PropLoader is that it it does not support reset by RTS.
    Just toggle RTS together with DTR for a reset, no extra commandline switch needed.

    I believe that adding the command line option "-D reset=rts" makes proploader use RTS reset instead of DTR.

    Thanks Eric. That works!
    I have no problems with downloads on a newer Win10 computer.

  • RS_JimRS_Jim Posts: 1,614

    Thanks Eric. I will try that 1st chance I get.
    Jim1.

  • RaymanRayman Posts: 12,914

    @ersmith Where should I ask questions about using FlexProp in C with P1 (actually P1V)?

    Anyway, I was testing out this 3-color epaper C code with P1V and was amazed that it compiled without changes. But, was too big, so had to cut a lot of fonts...

    Still, the size seems to be much bigger than it should be. I'm wondering if there's some way to figure out what is using up all the space...

    Also, I was getting gibberish in the terminal until I realized that my P1V has a 6.25 MHz fake crystal. The manual didn't really help in this regard as it just mentions using the Spin clkset() function, which I don't think applies in this case. Anyway, did this to fix it:

        uint32_t * p=0;
        *p=100000000;
    

    Maybe there's a prettier way? This is just writing the 100 MHz clock frequency to the first long in hub memory...

Sign In or Register to comment.