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.
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.
Wow, ok certainly not slow @dgately . 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.
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.
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:
@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.
@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).
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.
@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
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 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
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 .
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
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.
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.
Comments
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.
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
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.
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.
dgately
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.
Tested it with 50 using -l2000000, and 50 without (which now defaults to 2Mbps as well I think). Seems good so far.
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 2where did the wheels come off?Jim
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
Strange that it can't find the basic headers.
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.
Jim
Jim
Jim
:~/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 2I think I will see what happens if I uninstall and reinstall gcc.Jim
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 CThanks for the advice. Will try hello world.
Jim
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
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'GNU make' has enough builtin 'rules' to compile simple C sources to programs, so this is enough to test compiling:EDIT: gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04)
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.
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.