Shop OBEX P1 Docs P2 Docs Learn Events
FlexGUI 4.3.1: Program your P2 in Spin, BASIC, or C - Page 2 — Parallax Forums

FlexGUI 4.3.1: Program your P2 in Spin, BASIC, or C

2456

Comments

  • jmgjmg Posts: 15,140
    rogloh wrote: »
    What seems to be happening is that on my machine the two space characters being transmitted from the loadp2 code get buffered together (one space initially then the first one from the retry loop) and are arriving back to back on the P2 and in the PASM code the 8 bit waitx delay after auto baud means that the smartpin rx is not always ready for the 2nd space to arrive and it can get missed. Adding a wait_drain() in the right spot plus a 1ms delay solves it.


    autobaud
    ...
    mov a, waitbit
    shl a, #3
    waitx a

    ret
    Yes, I noticed the Autobaud code there has an unusual exit delay (makes things less tolerant), and my personal preference for autobaud is to measure over multiple bits to reduce sampling errors
    That matters more on Boot code, where RCFAST is not a large multiple of BAUD, and so getting the correct centred capture is more important.
    The boot code carefully selects a unique autobaud char, that cannot have a false skew-sample in the smart pin hardware used for capture.
    SW polled autobaud could select another char - eg '|" is not used in Base64, and has 3L+5H for an 8bw capture possible.
  • rogloh wrote: »
    Interesting dgately. How does you machine compare? I have OS X 10.10.5 with a 2.9 GHz Intel Core i5 dual core CPU:
    Intel(R) Core(TM) i5-5287U CPU @ 2.90GHz

    Looking at the MainLoader1.Spin2 code in some more detail here is the fix I've found that I now think solves the issue...using it I now have 100% success with the download at both 2Mbps and the default (which I think might be 921600bps). This was with 100 iterations each.

    What seems to be happening is that on my machine the two space characters being transmitted from the loadp2 code get buffered together (one space initially then the first one from the retry loop) and are arriving back to back on the P2 and in the PASM code the 8 bit waitx delay after auto baud means that the smartpin rx is not always ready for the 2nd space to arrive and it can get missed. Adding a wait_drain() in the right spot plus a 1ms delay solves it.

    A slower machine that introduces longer gaps into the serial transmission between these space characters, or one with no buffering, may not see this problem.

    Not a slower machine...
    MacBook Pro (15-inch, 2019)
    Processor 2.3 GHz 8-Core Intel Core i9
    Memory 32 GB 2400 MHz DDR4
    Graphics Intel UHD Graphics 630 1536 MB
    macOS Catalina 10.15.2 (19C57)

    dgately



  • roglohrogloh Posts: 5,122
    edited 2020-02-04 06:13
    Wow, ok certainly not slow @dgately :smile: . Perhaps this is more of an OS version difference causing back to back data to come out over the USB serial port on my machine, or something else to do with the USB HW or custom FTDI drivers etc.

    I have kept this older OS X so I can still use BST and PropellerIDE with some legacy P1 projects I developed. If it wasn't for that (and a bunch of other tool customisations I setup over years with homebrew etc), I'd want to upgrade this machine to the newer OS. But then I'm in another world of hurt upgrading all the tools and seeing what is broken/missing. Almost better off to just buy another Mac I guess, unless I setup some type of dual boot machine. Ugh.

  • evanhevanh Posts: 15,126
    edited 2020-02-04 08:03
    Keep trying with the source code. It will be possible to get a solution. The older code worked after all.

    Presumably Git can be used to wind things back but I wouldn't know how. Here's an old set of sources from July last year.
  • I have already found the fix evanh from what I can tell. The latest diff to loadp2.c I posted is all that was needed to stop the timeout (in 200 downloads anyway).
  • Thanks for testing this guys. Here's a revised binary (built with the latest github sources) that incorporates @rogloh's suggestions and @jmg's idea for more robust autobaud detection. It works fine on my Mac Mini, but OTOH the older version of the code did too, so evidently there is some OS/hardware variation. If get a chance please give it a try and let me know how it works.
  • ersmith wrote: »
    Thanks for testing this guys. Here's a revised binary (built with the latest github sources) that incorporates @rogloh's suggestions and @jmg's idea for more robust autobaud detection. It works fine on my Mac Mini, but OTOH the older version of the code did too, so evidently there is some OS/hardware variation. If get a chance please give it a try and let me know how it works.
    Didn't break anything on my config for this initial test:
    % for (( i=1; i<50; i++ )); do echo -n "$i " && ./loadp2.mac main.binary -p /dev/cu.usbserial-DN43WMDD && echo SUCCESS; done
    1 SUCCESS
    2 SUCCESS
    ...
    48 SUCCESS
    49 SUCCESS
    
    dgately
  • roglohrogloh Posts: 5,122
    edited 2020-02-05 00:10
    @ersmith After checking out the latest github release I wasn't able to make the latest loadp2 to test. Looks like this B921600 related change broke the Mac build (on my system anyway).
    RLs-MacBook-Pro:loadp2 roger$ make
    mkdir -p ./build
    gcc -Wall -O -g -DMACOSX -o build/loadp2 loadp2.c loadelf.c osint_linux.c u9fs/u9fs.c u9fs/authnone.c u9fs/print.c u9fs/doprint.c u9fs/rune.c u9fs/fcallconv.c u9fs/dirmodeconv.c u9fs/convM2D.c u9fs/convS2M.c u9fs/convD2M.c u9fs/convM2S.c u9fs/readn.c
    osint_linux.c:215:25: error: use of undeclared identifier 'B921600'
        cfsetospeed(&sparm, B921600); // dummy speed, overridden later
                            ^
    osint_linux.c:216:25: error: use of undeclared identifier 'B921600'
        cfsetispeed(&sparm, B921600); // dummy speed
                            ^
    

    There probably was a good reason that code was #ifdef'd out originally in osint_linux.c to stop this problem.
  • rogloh wrote: »
    @ersmith After checking out the latest github release I wasn't able to make the latest loadp2 to test. Looks like this B921600 related change broke the Mac build (on my system anyway).
    Try changing it to B9600 (I've done that in github, so you can re-pull yourself if you'd prefer). We do need that cfsetospeed/cfsetispeed because MacOS (or at least some versions of it) have a bug where doing a tcsetattr() on the result of tcgetattr() can fail if the terminal is not at one of the "standard" speeds. But the exact speed chosen doesn't matter at all because it's overridden (on the Mac at least) by the later call to ioctl(hSerial, IOSSIOSPEED, &speed).
  • Ok, got the latest with that B9600 change and retested. Result was 100 successful downloads.

    Tested it with 50 using -l2000000, and 50 without (which now defaults to 2Mbps as well I think). Seems good so far.


  • @rogloh and @dgately : thanks for trying this! It sounds like the new loadp2 should be much more stable on the Mac.
  • I've released FlexGUI version 4.1.3 on Patreon and github. This includes Mac binaries with the improved loadp2, as well as the "asm const" change and the fix for missing proploader.
  • Eric,
    I tried your suggestion for getting flexgui running on Mint. Here is the error message I received:
    ~/flexgui$ make install
    make -C spin2cpp
    make[1]: Entering directory '/home/jim/flexgui/spin2cpp'
    mkdir -p ./build
    bison -p spinyy -t -b ./build/spin -d frontends/spin/spin.y
    frontends/spin/spin.y: warning: 25 shift/reduce conflicts [-Wconflicts-sr]
    bison -p basicyy -t -b ./build/basic -d frontends/basic/basic.y
    frontends/basic/basic.y: warning: 10 shift/reduce conflicts [-Wconflicts-sr]
    bison -p cgramyy -t -b ./build/cgram -d frontends/c/cgram.y
    frontends/c/cgram.y: warning: 3 shift/reduce conflicts [-Wconflicts-sr]
    gcc -g -Wall -I. -I./build -DFLEXSPIN_BUILD -o build/lexer.o -c frontends/lexer.c
    frontends/lexer.c:7:10: fatal error: string.h: No such file or directory
     #include <string.h>
              ^~~~~~~~~~
    compilation terminated.
    Makefile:141: recipe for target 'build/lexer.o' failed
    make[1]: *** [build/lexer.o] Error 1
    make[1]: Leaving directory '/home/jim/flexgui/spin2cpp'
    Makefile:200: recipe for target 'spin2cpp/build/fastspin' failed
    make: *** [spin2cpp/build/fastspin] Error 2
    
    where did the wheels come off?
    Jim
  • @RS_Jim ... Mint is a Debian sibling? Check whether "build-essential" is installed:
    dpkg --status build-essential
    
  • @RS_Jim : The string.h header file is part of the standard C libraries, so it should have been installed when you installed the C compiler. I don't know what could be wrong. @yeti's suggestion that you try installing (or re-installing) build-essential is a good one.
  • Eric & Yeti,
    Thanks for the replies. I will check to see if build-essential is installed. The C compiler is not installed as I don’t normally work in C. Which one do you recommend, or is there a standard one that will come with my linux distribution?
    Jim
  • evanhevanh Posts: 15,126
    You've got GCC already. It's standard issue in full distros like that. You'd be getting command not found type errors if it wasn't there.

    Strange that it can't find the basic headers.

  • RS_JimRS_Jim Posts: 1,751
    edited 2020-04-01 15:42
    Bringing this back to top as I am seeing weird behaviors.
    Jim
    Edit:
    Weird behaviors partially a result of 2 Flex Gui threads. I can't seem to find my original post asking about setting up Flex Gui in Mint and his answer.
  • I am getting closer, A big part of the problem was my not applying software updates to a newly installed Version of linux mint.
    Jim
  • I have verified the presence of gcc on the system (linux mint) and installed all of the updates. I still get the error «string.h» not found. do I uninstall gcc and try again? Or is there some other solution?
    Jim
  • Make sure you install the build-essential package
  • I did, error comesback from missing string.h file.
    Jim
  • OK here is the latest:
    :~/flexgui$ make install
    make -C spin2cpp
    make[1]: Entering directory '/home/jim/flexgui/spin2cpp'
    gcc -g -Wall -I. -I./build -DFLEXSPIN_BUILD -o build/lexer.o -c frontends/lexer.c
    frontends/lexer.c:7:10: fatal error: string.h: No such file or directory
     #include <string.h>
              ^~~~~~~~~~
    compilation terminated.
    Makefile:141: recipe for target 'build/lexer.o' failed
    make[1]: *** [build/lexer.o] Error 1
    make[1]: Leaving directory '/home/jim/flexgui/spin2cpp'
    Makefile:200: recipe for target 'spin2cpp/build/fastspin' failed
    make: *** [spin2cpp/build/fastspin] Error 2
    
    I think I will see what happens if I uninstall and reinstall gcc.
    Jim
  • I don't think uninstalling and reinstalling gcc will help. Mint must be pretty broken if build-essential doesn't include this already, but you could try installing "libc-dev" or "libc6-dev".

    As a sanity check before you try to build flexgui I'd suggest building some simple C program like hello, world:
    #include <stdio.h>
    
    int main() {
      printf("hello, world!\n");
      return 0;
    }
    
    Until you get the headers (including stdio.h and string.h) installed, you won't be able to build anything in C :(.
  • RS_JimRS_Jim Posts: 1,751
    edited 2020-04-03 02:42
    Eric,
    Thanks for the advice. Will try hello world.
    Jim
  • RS_JimRS_Jim Posts: 1,751
    edited 2020-04-03 16:47
    Eric,
    I guess I am getting to old for this stuff! I created a txt file and saved it in home/jim/Documents. Now I can't figure out how to run it in GCC.
    Jim
  • yetiyeti Posts: 818
    edited 2020-04-03 20:40
    Mint?
    So a Debian mutant?
    Then it should work like on my not-eBook...

    Write a test C source to a file:
    (yeti@kumari:4)~/Documents$ cat << endcat > xyzzy.c
    > #include <stdio.h>
    > 
    > int main() {
    >   printf("hello, world!\n");
    >   return 0;
    > }
    > endcat
    
    (yeti@kumari:4)~/Documents$ ls -l
    total 4
    -rw-r--r-- 1 yeti yeti 76 Apr  3 20:31 xyzzy.c
    
    'GNU make' has enough builtin 'rules' to compile simple C sources to programs, so this is enough to test compiling:
    (yeti@kumari:4)~/Documents$ make xyzzy
    cc     xyzzy.c   -o xyzzy
    
    (yeti@kumari:4)~/Documents$ ls -l
    total 24
    -rwxr-xr-x 1 yeti yeti 16608 Apr  3 20:31 xyzzy
    -rw-r--r-- 1 yeti yeti    76 Apr  3 20:31 xyzzy.c
    
    (yeti@kumari:4)~/Documents$ ./xyzzy 
    hello, world!
    
  • evanhevanh Posts: 15,126
    edited 2020-04-04 01:02
    Huh, mine compiles a smaller binary:
    evanh@controlled:~/hoard/coding/prop2/testing$ ls -l hello*
    -rwxrwxr-x 1 evanh evanh 8304 Apr  4 13:57 hello-world
    -rw-rw-r-- 1 evanh evanh   76 Apr  4 13:56 hello-world.c
    evanh@controlled:~/hoard/coding/prop2/testing$ ./hello-world 
    hello, world!
    

    EDIT: gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04)

  • Getting back to the original topic, there's a new release of FlexGUI on my Patreon page and on github. The new GUI has one new checkbox option in the Options > Editor options menu; "save session" causes the editor to save which windows are open in the .flexgui.config file and to automatically re-open them the next time it starts.

    The new version of fastspin has many bug fixes, some more simpletools functions (thanks to @"Roy Eltham" !) and improved Spin and Spin2 compatibility. The language incompatibilities between Spin and Spin2 are pretty significant, so going forward I suggest you make sure to name your files appropriately (with a .spin extension for Spin1 code, even if it's intended to run on P2, and with a .spin2 extension for Spin2 code, even if it's intended to run on P1). fastspin uses the file extension to activate some features, e.g. underscore _ for "ignore a value in multiple assignments" is only present in Spin2, because some existing Spin1 code uses a single underscore for user variables or constants.

    The new compiler accepts ORG/END syntax for inline assembly, as well as the original ASM/ENDASM, which should make it easier to port code between Chip's compiler and mine. No address is accepted on the ORG yet.
  • AribaAriba Posts: 2,682
    Thank you Eric, I will try it soon.

    Does ORG .. END produce Cog code, like Spin2 does? I've found that small loops in inline assembly work much faster in Spin2 because of the faster jumps in cogexec. A simple pin toggle is about 2.6 times faster, this can be important if you need the speed.
    For sure if written in Spin, the same pin toggle is about 6 times faster in fastspin.

    I also checked some code sizes and would say Spin2 takes about 1/2 of the size of fastspin, but has to add the 4 kB byte code interpreter. So Fastspin size is smaller up to ~ 7kB, for bigger code Spin2 is smaller.
Sign In or Register to comment.