Remember, booting the SD card fails if there is, I think, any deleted long filenames. From memory, there's something different, from the 8.3 deleted marker, about the double entry deleted marker that the SD boot routine gets tangled up in.
@evanh said:
Remember, booting the SD card fails if there is, I think, any deleted long filenames. From memory, there's something different, from the 8.3 deleted marker, about the double entry deleted marker that the SD boot routine gets tangled up in.
I don't think this is correct.
It is just that I completely ignore the long filename sections in the dir. What will cause issues are if you want an 8.3 file and there are multiple entries for long filenames that fit this mask. Then the 8+3 get mangled to allow multiple 8+3 for the multiple long filename entries. This is a bit convoluted so hope you can follow.
My memory of the behaviour from when I did test this, years back, is the spelling is unrelated. If there is any deleted long name still in the root entries then the boot fails.
Hmm, dunno now. Just had a go at duplicating that ... and can't.
Cool indeed. Probably my No.1 feature that proptool has that flexspin doesn't (didn't?).
Can you give some of your cents on the problems I brought up on Github? In particular, the expression string and "it doesn't work when there's Spin" ones. I'm kinda stumped with the latter and just no idea on how to approach the former.
@Wuerfel_21 said:
Can you give some of your cents on the problems I brought up on Github? In particular, the expression string and "it doesn't work when there's Spin" ones. I'm kinda stumped with the latter and just no idea on how to approach the former.
I've just now had a chance to look at the code. The "doesn't work when there's Spin" is because if there's a high level language the second pass (final compilation of assembly) is done in case sensitive mode, so the PASM in sys/p2_brkdebug.spin has to use all lower case (e.g. change CON to con, DAT to dat; I think those are the only keywords getting tripped up).
I'm not sure about the expression one, I'll have to look further into that.
@ersmith said:
The "doesn't work when there's Spin" is because if there's a high level language the second pass (final compilation of assembly) is done in case sensitive mode, so the PASM in sys/p2_brkdebug.spin has to use all lower case (e.g. change CON to con, DAT to dat; I think those are the only keywords getting tripped up).
Ahh, that's the issue. Instead of changing the code, just disabling case sensitive mode seems to do the trick (the debugger is built last, so it shouldn't be a problem). Works now, but it gets the wrong clock settings for some reason (it tries pulling them from __clkfreq_con and __clkmode_con and it's getting... 2 MHz???), so after the spin startup sets the correct clock everything is garbled.
Strange, it seems to be working for me, although locally I made it work by changing the CON and DAT declarations to lower case instead of disabling the case sensitive mode; maybe the clkfreq settings aren't being found for some case related reason?
@ersmith said:
Strange, it seems to be working for me, although locally I made it work by changing the CON and DAT declarations to lower case instead of disabling the case sensitive mode; maybe the clkfreq settings aren't being found for some case related reason?
That's be odd though, since pure PASM is case insensitve and it finds the clock settings in that just fine. I think CalcClkFreqP2 fails with case sensitivity enabled and defaults to RCFAST (checks for lowercase constants, but the .p2asm file contains the clock constants as they are written in the source)
@ersmith This is an odd one in FlexBASIC. Run this code:
print number$(10,2,16)
This should be equiv to calling HEX$() like this:
print hex$(10,2)
but it isn't. Instead, NUMBER$() prints "1669341856" instead of "0A". Since NUMBER$() is called by HEX$(), OCT$(), BIN$(), etc, I would expect all of those functions to be broken, but they aren't. The only time there is a problem is when NUMBER$() is called from outside of STRINGS.BAS.
@JRoark said:
@ersmith This is an odd one in FlexBASIC. Run this code:
print number$(10,2,16)
Just that code on its own gives me an error about number$ being undefined. Which is wrong, it is documented, but for some reason the definition for it didn't make it into the internal list of definitions. That's bug #1
If you add a line using hex$, then the code runs but prints garbage (as you observed). What's happening there is that because number$ is undefined, it's initially guessing it returns an integer, and printing the result accordingly. However, number$ actually returns a string. There's no "undefined symbol" because it's called from hex$ and hence being pulled in, but the missing definition is causing confusion. Bug #2 .
@Rayman said:
Started getting these messages in serial output:
!!! corrupted heap??? !!! !!! corrupted heap??? !!! !!! corrupted heap??? !!! !!! corrupted heap??? !!!
This is after one malloc for an array of structures that is ~3kB
Am using enum { heapsize = 16000 }; //override the default heapsize to give more, if needed
So, I don't think it's a memory issue...
The code works, but spits out this error message every once in a while...
Any idea what might be causing this?
It could be some code writing past the end of an allocated buffer. FlexProp's library is more sensitive to this than many other libraries (on PCs I think allocations tend to be rounded up to the next page size, so they're more forgiving).
BTW: That allocates from the stack instead of heap. So I'm guessing that makes it an "auto", which means if you want it persistent then main() should do the allocation.
No. A malloc()'d pointer stays valid until free()'d. Ie: The allocation stays even if that same pointer is reassigned a new malloc(). Doing so is called a memory leak.
@deets : I'm not sure what's going on there. I've checked out a fresh copy of the flexprop and did a "git checkout v5.5.2", and it built fine on my Debian Linux machine. I also tried the release/v5.5 branch.
Are you able to build the "master" branch? That has the most up to date code.
My build fails on the sdcard.c file too. Different error than Deets is getting but since flexspin loadp2 still builds I just ignore the error and copy flexspin loadp2 over to my prop directories and use it without any install. I've been putting the error down to me not knowing what is needed.
Here's what I get with just "make":
evanh@controlled:~/hoard/coding/prop2/P123A9_board/loadp2-rl$ make
mkdir -p ./build
flexspin -2 -o MainLoader_fpga.bin MainLoader_fpga.spin2
Propeller Spin/PASM Compiler 'FlexSpin' (c) 2011-2021 Total Spectrum Software Inc.
Version 5.9.2-beta-v5.4.3-452-gb18e0ded Compiled on: Aug 24 2021
MainLoader_fpga.spin2
MainLoader_fpga.spin2
Done.
Program size is 512 bytes
xxd -i MainLoader_fpga.bin > MainLoader_fpga.h
flexspin -2 -o MainLoader_chip.bin MainLoader_chip.spin2
Propeller Spin/PASM Compiler 'FlexSpin' (c) 2011-2021 Total Spectrum Software Inc.
Version 5.9.2-beta-v5.4.3-452-gb18e0ded Compiled on: Aug 24 2021
MainLoader_chip.spin2
MainLoader_chip.spin2
Done.
Program size is 1024 bytes
xxd -i MainLoader_chip.bin > MainLoader_chip.h
gcc -Wall -O -g -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: In function ‘terminal_mode’:
osint_linux.c:472:25: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Wunused-result]
472 | write(fileno(stdout), realbuf, realbytes);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
osint_linux.c:486:21: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Wunused-result]
486 | write(hSerial, buf, cnt);
| ^~~~~~~~~~~~~~~~~~~~~~~~
make -C board/sdcard P2CC="flexspin -2"
make[1]: Entering directory '/home/evanh/hoard/coding/prop2/P123A9_board/loadp2-rl/board/sdcard'
flexspin -2 -o sdboot.binary sdboot.c ff.c sdmm.c
Propeller Spin/PASM Compiler 'FlexSpin' (c) 2011-2021 Total Spectrum Software Inc.
Version 5.9.2-beta-v5.4.3-452-gb18e0ded Compiled on: Aug 24 2021
sdboot.c
error: Preprocessor errors:
/home/evanh/hoard/coding/prop2/P123A9_board/loadp2-rl/board/sdcard/sdboot.c:6: error: Can't open include file "stdio.h"
#include <stdio.h>
/home/evanh/hoard/coding/prop2/P123A9_board/loadp2-rl/board/sdcard/sdboot.c:7: error: Can't open include file "propeller2.h"
#include <propeller2.h>
2 errors in preprocessor.
make[1]: *** [Makefile:8: sdboot.binary] Error 1
make[1]: Leaving directory '/home/evanh/hoard/coding/prop2/P123A9_board/loadp2-rl/board/sdcard'
make: *** [Makefile:79: board/P2ES_sdcard.bin] Error 2
rm MainLoader_chip.bin MainLoader_fpga.bin
Comments
Is there a way to add long filename and directory support with FatFS?
If so, is it mentioned in the docs anywhere? I went looking, but couldn't find it...
Yes, it's under File I/O > Options for SD Card in the general documentation (general.html):
There's quite a lot of stuff in general.html that applies to all languages.
Remember, booting the SD card fails if there is, I think, any deleted long filenames. From memory, there's something different, from the 8.3 deleted marker, about the double entry deleted marker that the SD boot routine gets tangled up in.
I don't think this is correct.
It is just that I completely ignore the long filename sections in the dir. What will cause issues are if you want an 8.3 file and there are multiple entries for long filenames that fit this mask. Then the 8+3 get mangled to allow multiple 8+3 for the multiple long filename entries. This is a bit convoluted so hope you can follow.
My memory of the behaviour from when I did test this, years back, is the spelling is unrelated. If there is any deleted long name still in the root entries then the boot fails.
Hmm, dunno now. Just had a go at duplicating that ... and can't.
So, uhhhh, PASM debug is now happening, I guess?
Where is the reference for installing the latest version on linux?
Jim
For flexprop it's in the README.md file.
For just flexspin / spin2cpp there's not really an installation procedure, just do "make" and then use the binaries from the "build" directory.
This is looking very cool! Thanks, Ada.
Cool indeed. Probably my No.1 feature that proptool has that flexspin doesn't (didn't?).
Can you give some of your cents on the problems I brought up on Github? In particular, the expression string and "it doesn't work when there's Spin" ones. I'm kinda stumped with the latter and just no idea on how to approach the former.
I've just now had a chance to look at the code. The "doesn't work when there's Spin" is because if there's a high level language the second pass (final compilation of assembly) is done in case sensitive mode, so the PASM in sys/p2_brkdebug.spin has to use all lower case (e.g. change CON to con, DAT to dat; I think those are the only keywords getting tripped up).
I'm not sure about the expression one, I'll have to look further into that.
Ahh, that's the issue. Instead of changing the code, just disabling case sensitive mode seems to do the trick (the debugger is built last, so it shouldn't be a problem). Works now, but it gets the wrong clock settings for some reason (it tries pulling them from
__clkfreq_conand__clkmode_conand it's getting... 2 MHz???), so after the spin startup sets the correct clock everything is garbled.Strange, it seems to be working for me, although locally I made it work by changing the CON and DAT declarations to lower case instead of disabling the case sensitive mode; maybe the clkfreq settings aren't being found for some case related reason?
That's be odd though, since pure PASM is case insensitve and it finds the clock settings in that just fine. I think
CalcClkFreqP2fails with case sensitivity enabled and defaults to RCFAST (checks for lowercase constants, but the .p2asm file contains the clock constants as they are written in the source)Yeah, that was it, got it sorted...
@ersmith This is an odd one in FlexBASIC. Run this code:
This should be equiv to calling HEX$() like this:
but it isn't. Instead, NUMBER$() prints "1669341856" instead of "0A". Since NUMBER$() is called by HEX$(), OCT$(), BIN$(), etc, I would expect all of those functions to be broken, but they aren't. The only time there is a problem is when NUMBER$() is called from outside of STRINGS.BAS.
Also,
Started getting these messages in serial output:
!!! corrupted heap??? !!! !!! corrupted heap??? !!! !!! corrupted heap??? !!! !!! corrupted heap??? !!!This is after one malloc for an array of structures that is ~3kB
Am using
enum { heapsize = 16000 }; //override the default heapsize to give more, if neededSo, I don't think it's a memory issue...
The code works, but spits out this error message every once in a while...
Actually, the code breaks as soon as this message prints...
Any idea what might be causing this?
Could be bad programming on my part...
Here's the relevant code:
typedef struct
{
int x;
int y;
int n;
int status;
} TileObject;
TileObject * map_list;
int map_tilecount;
printf("Map list count=%d, size=%d bytes\n", map_tilecount, sizeof(TileObject) * map_tilecount);
map_list = (TileObject*)malloc(sizeof(TileObject) * map_tilecount);
Just that code on its own gives me an error about number$ being undefined. Which is wrong, it is documented, but for some reason the definition for it didn't make it into the internal list of definitions. That's bug #1
If you add a line using hex$, then the code runs but prints garbage (as you observed). What's happening there is that because number$ is undefined, it's initially guessing it returns an integer, and printing the result accordingly. However, number$ actually returns a string. There's no "undefined symbol" because it's called from hex$ and hence being pulled in, but the missing definition is causing confusion. Bug #2
.
Bug #1 is easily fixed, not sure about bug #2.
Also?
It could be some code writing past the end of an allocated buffer. FlexProp's library is more sensitive to this than many other libraries (on PCs I think allocations tend to be rounded up to the next page size, so they're more forgiving).
@ersmith Whoops. Sorry. That “also” was a rogue fragment from an earlier edit.
Try removing the ENUM, no extra heap, then using
map_list = (TileObject*)__builtin_alloca(sizeof(TileObject) * map_tilecount);BTW: That allocates from the stack instead of heap. So I'm guessing that makes it an "auto", which means if you want it persistent then main() should do the allocation.
Thanks @evanh
Maybe my my Malloc needs to be in main() ?
No. A malloc()'d pointer stays valid until free()'d. Ie: The allocation stays even if that same pointer is reassigned a new malloc(). Doing so is called a memory leak.
I'm interested to see what sort of misbehaviour occurs when you change to the stack based solution.
I'm getting this error
16:03 $ make install (make -C board/sdcard P2CC="`pwd`/bin/flexspin -2 -I`pwd`/spin2cpp/include") make[1]: Entering directory '/home/deets/software/vc/flexprop/board/sdcard' /home/deets/software/vc/flexprop/bin/flexspin -2 -I/home/deets/software/vc/flexprop/spin2cpp/include -o sdboot.binary sdboot.c ff.c sdmm.c Propeller Spin/PASM Compiler 'FlexSpin' (c) 2011-2021 Total Spectrum Software Inc. Version 5.5.1-HEAD-v5.5.1 Compiled on: Jun 26 2021 sdboot.c /home/deets/software/vc/flexprop/spin2cpp/include/sys/unistd.h:24: error: syntax error, unexpected __fromfile, expecting '{' make[1]: *** [Makefile:8: sdboot.binary] Error 1 make[1]: Leaving directory '/home/deets/software/vc/flexprop/board/sdcard' make: *** [Makefile:310: board/sdcard/sdboot.binary] Error 2 ✘-2 ~/software/vc/flexprop [v5.5.2|✚ 1…492⚑ 1]when attempting to build v5.5.2 of github.com:totalspectrum/flexprop.git
Am I missing something? I updated the submodules.
@deets : I'm not sure what's going on there. I've checked out a fresh copy of the flexprop and did a "git checkout v5.5.2", and it built fine on my Debian Linux machine. I also tried the release/v5.5 branch.
Are you able to build the "master" branch? That has the most up to date code.
My build fails on the sdcard.c file too. Different error than Deets is getting but since flexspin loadp2 still builds I just ignore the error and copy flexspin loadp2 over to my prop directories and use it without any install. I've been putting the error down to me not knowing what is needed.
Here's what I get with just "make":
evanh@controlled:~/hoard/coding/prop2/P123A9_board/loadp2-rl$ make mkdir -p ./build flexspin -2 -o MainLoader_fpga.bin MainLoader_fpga.spin2 Propeller Spin/PASM Compiler 'FlexSpin' (c) 2011-2021 Total Spectrum Software Inc. Version 5.9.2-beta-v5.4.3-452-gb18e0ded Compiled on: Aug 24 2021 MainLoader_fpga.spin2 MainLoader_fpga.spin2 Done. Program size is 512 bytes xxd -i MainLoader_fpga.bin > MainLoader_fpga.h flexspin -2 -o MainLoader_chip.bin MainLoader_chip.spin2 Propeller Spin/PASM Compiler 'FlexSpin' (c) 2011-2021 Total Spectrum Software Inc. Version 5.9.2-beta-v5.4.3-452-gb18e0ded Compiled on: Aug 24 2021 MainLoader_chip.spin2 MainLoader_chip.spin2 Done. Program size is 1024 bytes xxd -i MainLoader_chip.bin > MainLoader_chip.h gcc -Wall -O -g -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: In function ‘terminal_mode’: osint_linux.c:472:25: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Wunused-result] 472 | write(fileno(stdout), realbuf, realbytes); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ osint_linux.c:486:21: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Wunused-result] 486 | write(hSerial, buf, cnt); | ^~~~~~~~~~~~~~~~~~~~~~~~ make -C board/sdcard P2CC="flexspin -2" make[1]: Entering directory '/home/evanh/hoard/coding/prop2/P123A9_board/loadp2-rl/board/sdcard' flexspin -2 -o sdboot.binary sdboot.c ff.c sdmm.c Propeller Spin/PASM Compiler 'FlexSpin' (c) 2011-2021 Total Spectrum Software Inc. Version 5.9.2-beta-v5.4.3-452-gb18e0ded Compiled on: Aug 24 2021 sdboot.c error: Preprocessor errors: /home/evanh/hoard/coding/prop2/P123A9_board/loadp2-rl/board/sdcard/sdboot.c:6: error: Can't open include file "stdio.h" #include <stdio.h> /home/evanh/hoard/coding/prop2/P123A9_board/loadp2-rl/board/sdcard/sdboot.c:7: error: Can't open include file "propeller2.h" #include <propeller2.h> 2 errors in preprocessor. make[1]: *** [Makefile:8: sdboot.binary] Error 1 make[1]: Leaving directory '/home/evanh/hoard/coding/prop2/P123A9_board/loadp2-rl/board/sdcard' make: *** [Makefile:79: board/P2ES_sdcard.bin] Error 2 rm MainLoader_chip.bin MainLoader_fpga.binOh, Deets, try a
make cleanbefore themake installRight on the money! This (after installing tk headers) solved my problem.
The version info looks a bit wonky, but
But it is usable.