@Rayman said:
Think the FlexProp VGA demo can also work at 720p, see attached.
Doesn't like 1080p though...
A more recent version of the VGA demo is at https://github.com/totalspectrum/p2_vga_text . I should update the one in FlexProp I guess, but the p2_vga_text one is larger and has more stuff (including timings for 1280x1024 and some tools for converting fonts).
FlexProp version 6.9.4 is available now from github and from my Patreon page. It has some significant bug fixes, particularly for Windows (where an uninitialized variable could cause mysterious and apparently random error messages).
FlexProp has been updated to 6.9.9. Since the last release there are quite a few compiler fixes. The changelog looks like:
Version 6.9.9
- Fixed `--compress` flag on Windows
- Added `--zip` flag to flexcc (previously it was just in flexspin)
- Improved handling of file names in .zip output
- Improved error message for sizeof(x) when x is undefined
Version 6.9.8
- Fix `#foo+CONST` calculation
- Fix a problem with pointer calculations in structs
Version 6.9.7
- Fixed infinite loop when CORDIC and Read/Write optimizations fight
- Fixed potential crash when compiling empty functions
- Allow `#foo+CONST` for inline assembly when `foo` is a HUB label
Version 6.9.6
- Added a peephole for some address calculations (as suggested by Evan)
- Fixed some built-in functions in spin2cpp
Version 6.9.5
- Fixed immediate ranges for load/store, and made out of range immediates an error (thanks to Ada)
- Fixed an inappropriate memory forwarding with WZ (also thanks to Ada)
- Made sure arrays of bytes are put into memory, even if inside structs or unions
The binary releases are available on GitHub and on my Patreon page; links are in my signature.
@ersmith Seem to be having an issue with the shell.c example...
When copying this python file from /host to /sd, it doesn't copy the whole file.
Any idea what might cause that?
@Rayman thanks for the bug report. I tried copying that file from host to host, and it worked, so it seems like it's some problem in the FAT file system. Most likely it's in the interface between FAT and the stdio library. Your work-around seems like a good one for now.
Ah, I think I found the bug -- because FATFS provides a flush function, we're not calling the default flush which fputc() relies on. The fix is to insert a call
__default_flush(fil);
at the beginning of the v_flush function in include/filesys/fatfs/fatfs.cc (before any of the #if or other statements)
@ersmith,
I am just getting started with FlexProp and I am getting the follwing error when compiling with FlexProp but not PNUT. What am I not understanding?
Hmm... Wonder if it's one of those new things that one has to specify the Spin2 version to use with PropTool and FlexProp?
Looks like can fix like this?
It's probably because Flexspin's return codes are passed in registers by default, and that Flexspin is not identifying the referencing for placing tc on the stack instead.
you could probably replace @tc.byte[2] with @tc+2, but you really shouldn't, since that enables locals-on-stack mode (There's -Ospin-relax-memory, but it's not perfect).
Thank you all. I rewrote code as suggested by Rayman and it now compiles in both PNUT and Flexspin. I am somewhat torn as to which tool to use long-term. I am liking each one of them for slightly different reasons. Any input from the community as to what they like/dislike about either tool would be helpful to me as well as maybe to others. I certainly do appreciate the community!
Flexspin compiles to native, so is always going to be faster. It's ability to gobble and share a mix of Spin, Basic and C all together is impressive too. Probably its biggest weakness is not supporting interrupts. Chip has been very careful to ensure the Pnut/Proptool Spin2 VM is interrupt safe.
EDIT: On that note, any "inline" assembly that isn't explicitly coded for interrupt safety will break when subjected to interrupts, on the same cog, under Pnut too. My latest SD card driver is one such case. I wrote it for FlexC and have ported it to Spin2 without consideration for interrupts. However, historically, most drivers have tended to launch their own cog for such activities. Interrupts usually are lone to the code on that cog.
Comments
A more recent version of the VGA demo is at https://github.com/totalspectrum/p2_vga_text . I should update the one in FlexProp I guess, but the p2_vga_text one is larger and has more stuff (including timings for 1280x1024 and some tools for converting fonts).
FlexProp version 6.9.4 is available now from github and from my Patreon page. It has some significant bug fixes, particularly for Windows (where an uninitialized variable could cause mysterious and apparently random error messages).
FlexProp has been updated to 6.9.9. Since the last release there are quite a few compiler fixes. The changelog looks like:
The binary releases are available on GitHub and on my Patreon page; links are in my signature.
FlexProp 6.9.10 is now available on GitHub (see my signature for links). This has several fairly significant bug fixes, so it's worth updating.
@ersmith Seem to be having an issue with the shell.c example...
When copying this python file from /host to /sd, it doesn't copy the whole file.
Any idea what might cause that?
Don't know what's up with fputc(), but works when copy is rewritten like this:
char buf[100]; for(;;) { c = fread(buf, 1, 100, inf);// fgetc(inf); if (c == 0) break; fwrite(buf, 1, c, outf); count+=c; if (c < 100) break; }@Rayman thanks for the bug report. I tried copying that file from host to host, and it worked, so it seems like it's some problem in the FAT file system. Most likely it's in the interface between FAT and the stdio library. Your work-around seems like a good one for now.
Ah, I think I found the bug -- because FATFS provides a flush function, we're not calling the default flush which fputc() relies on. The fix is to insert a call
at the beginning of the
v_flushfunction in include/filesys/fatfs/fatfs.cc (before any of the #if or other statements)I'll try to get this fix up to github soon.
Glad you found it. Was trying calling flush and it didn't help. Guess that's why...
@ersmith,
I am just getting started with FlexProp and I am getting the follwing error when compiling with FlexProp but not PNUT. What am I not understanding?
Hmm... Wonder if it's one of those new things that one has to specify the Spin2 version to use with PropTool and FlexProp?
Looks like can fix like this?
It's probably because Flexspin's return codes are passed in registers by default, and that Flexspin is not identifying the referencing for placing
tcon the stack instead.It's kind of amazing that the FlexProp version of Spin2 is compatible as it is with PNUT, when completely different under the hood...
you could probably replace
@tc.byte[2]with@tc+2, but you really shouldn't, since that enables locals-on-stack mode (There's-Ospin-relax-memory, but it's not perfect).Thank you all. I rewrote code as suggested by Rayman and it now compiles in both PNUT and Flexspin. I am somewhat torn as to which tool to use long-term. I am liking each one of them for slightly different reasons. Any input from the community as to what they like/dislike about either tool would be helpful to me as well as maybe to others. I certainly do appreciate the community!
Flexspin compiles to native, so is always going to be faster. It's ability to gobble and share a mix of Spin, Basic and C all together is impressive too. Probably its biggest weakness is not supporting interrupts. Chip has been very careful to ensure the Pnut/Proptool Spin2 VM is interrupt safe.
EDIT: On that note, any "inline" assembly that isn't explicitly coded for interrupt safety will break when subjected to interrupts, on the same cog, under Pnut too. My latest SD card driver is one such case. I wrote it for FlexC and have ported it to Spin2 without consideration for interrupts. However, historically, most drivers have tended to launch their own cog for such activities. Interrupts usually are lone to the code on that cog.