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

2»

Comments

  • jmgjmg Posts: 14,278
    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: 1,994
    edited 2020-02-04 - 06:13:07
    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: 8,962
    edited 2020-02-04 - 08:03:21
    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: 1,994
    edited 2020-02-05 - 00:10:06
    @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
  • 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.

Sign In or Register to comment.