Are you saying using any long filenames will break the boot from sd process?
Or, that people are trying to boot from files with long filenames and it doesn't work?
Neither. If I remember correctly, not that I tested the combinations, the problem only comes about with deleted long names.
@ersmith Have you thought about adding the long filenames option to FatFs?
Or, is it already there?
It's there, but not enabled. I had intended to allow it to be defined on the command line with -DFF_USE_LFN=1, but I forgot to wrap the definition in filesys/fatfs/ffconf.h with a #ifndef. That's fixed in github now.
Also, is there a way to change which pins are assigned to the uSD card?
Not yet. Having just one uSD card and changing the pins for it would be straightforward, but I suspect most uses for different pins would want there to be an option for multiple uSD cards, and that would require some work.
I get this warning (warning: parameter passing discards const attribute from pointer) on things like this:
playVideo("fun-1500.avi");
where playVideo declared like this:
void playVideo(char* filename)
{//Play a .avi video using media fifo we will set up and top of RAM_G
Is this warning warrented?
I'm able to get rid of it like this:
playVideo((char *) "fun-1500.avi");
I don't really understand the reason for the "const" attribute. Guess I should look that up one day...
const before the star means that the data that is pointed to is read-only. A function that takes a string and only reads it and doesn't write to it must be declared to take a "const char *".
I get this warning (warning: parameter passing discards const attribute from pointer) on things like this:
playVideo("fun-1500.avi");
where playVideo declared like this:
void playVideo(char* filename)
{//Play a .avi video using media fifo we will set up and top of RAM_G
Is this warning warrented?
I think it is warranted, because with that declaration the playVideo function is allowed to modify the file name in place (e.g. by doing something like filename[0] = 'x' to change the first letter).
If you declare playVideo as:
void playVideo(const char* filename)
it'll get rid of the warning; this assumes, of course, that playVideo doesn't need to change the file name (which is likely true).
In FlexC literal strings are constant (should not be modified by the application), and that's what the "const" attribute means. Technically I'm not quite sure what the C standard says about this, but practically speaking it's a very bad idea to try to write over a literal string. For example, many compilers will put them in ROM, or share multiple instances of a single string.
I don't really understand the reason for the "const" attribute.
The inline quoted string is default treated as a const char. The compiler then sees it being assigned to a char type without the const attribute so informs to that effect. And your workaround is to cast to the same (non-const) so thereby avoiding the warning.
I presume that less strict compliers wouldn't produce such a warning.
Having just one uSD card and changing the pins for it would be straightforward, but I suspect most uses for different pins would want there to be an option for multiple uSD cards, and that would require some work.
I would like the capability for a single uSD card at different pins than the default ones. I have a P2 Edge, which doesn't have a uSD connector, and I would like to connect a uSD to it using different pins.
Booting from SD does not use long filename, and the two boot files must be uppercase _BOOT_P2.BIX and _BOOT_P2.BIY IIRC, and the SD card must be formatted as FAT32.
There is an alternative method where the bootfile is stored in the MBR/VOL sector(s) - for more info, see the P2 Boot ROM writeup thread.
The long filenames used by Windows use more then one directory entry for the name and shortening the first one to attach some ~ and number to distinguish.
I have a (not just by me) modified Version of KYE's driver supporting long filenames (might work in P2 too with the existing port the changes are just in Spin).
But if you have multiple copies of _BOOT_P2.BIX with too similar names then windows will start to even make a long filename out of a perfectly valid 8.3 name.
And there the trouble might arise. Because the boot process needs the 8.3 name.
So long filenames are possible, one just need to take care of having the boot file as 8.3, not sure how to force that when writing to SD in case of trouble...
You cannot have multiple copies of _BOOT_P2.BIX
And you cannot have files beginning with _BOOT_P2 as long file names. Not sure what parts the extension plays.
Having just one uSD card and changing the pins for it would be straightforward, but I suspect most uses for different pins would want there to be an option for multiple uSD cards, and that would require some work.
I would like the capability for a single uSD card at different pins than the default ones. I have a P2 Edge, which doesn't have a uSD connector, and I would like to connect a uSD to it using different pins.
I've modified the current github so you can add defines for PIN_CLK, PIN_SS, PIN_MOSI, PIN_MISO on the command line to change the default pins. Documentation for that is in "general.md" under the "File I/O" section.
As I mentioned I'd like eventually to have some parameters to the _vfs_mount_sdcard() function to allow for multiple cards, but that will have to wait a bit.
Ok, good to know. Wasn't sure if should use the .h or the .c or maybe it doesn't matter?
This would help separate the namespace and make it look more like a class.
Here are the errors I get now:
1>D:/Propeller2/FastSpin/Demos_P2/Antares/Antares.c:17: error: Variable FifoWriteLocation is initialized twice
1>D:/Propeller2/FastSpin/Demos_P2/Antares/Antares.c:1186: error: syntax error, unexpected type name `LPCOLORREF', expecting identifier or '('
Ok, I got past those errors by moving those global things from the ".c" to the ".h" file.
But then, I get a ton of errors and warnings like this:
1>D:/Propeller2/FastSpin/Demos_P2/Antares/Antares.c:944: error: redefining function Wait4CoProFIFOEmpty
1>Antares.c:944: note: the previous definition is here
1>D:/Propeller2/FastSpin/Demos_P2/Antares/Antares.c:960: warning: duplicate definition for StartCoProTransfer
1>Antares.c:960: note: the previous definition is here
1>D:/Propeller2/FastSpin/Demos_P2/Antares/Antares.c:1004: error: redefining function CoProWrCmdBuf
1>Antares.c:1004: note: the previous definition is here
1>D:/Propeller2/FastSpin/Demos_P2/Antares/Antares.c:1024: error: redefining function WriteBlockRAM
1>Antares.c:1024: note: the previous definition is here
1>D:/Propeller2/FastSpin/Demos_P2/Antares/Antares.c:1041: warning: duplicate definition for LoadFile
1>Antares.c:1041: note: the previous definition is here
I image it is due to the convoluted way I'm building the file...
To avoid adding Antares.c to the build command line, I've added it inside the Antares.h file like this:
Tried removing that include and put on command line, but still get a bunch of errors.
Doesn't look like it's going to work. But, it's fine like it is anyway. I'll just leave it alone.
Only issue I really have is a couple of global variables like "w" and "h" that could easily be redefined by accident... Maybe I'll just rename them to something more complex.
BTW: The compiler output often says "1 succeeded" when it actually failed.
But, I've learned to look for the "Program size" message to tell if it really worked.
Rayman,
I believe you are running into the "no linker" issue. If you want to be able to call C functions in another c file, then in the header file for that other c file you need to add special __fromfile() tags to your declarations like this:
unsigned get_states(int endPin, int startPin) __fromfile("libsimpletools/getStates.c");
This will cause the compiler to build the code referenced in the __fromfile() for your code to then be able to call.
If/When we get a linker, then it can be done the normal way.
I can't really diagnose the errors without seeing the code, but my guess is you put too much into the .h file, either directly or indirectly (via the #include "antares.c"). In general .h files should just have declarations, not anything executable, because they're designed to be included multiple times by other files.
It sounds like the correct solution really is to put the .c file on the command line, if that's the way it's designed to be used. The FlexProp GUI doesn't directly support multiple files, but the command line tools do.
Sometimes the errors & warnings appear at the top of the output and sometimes at the bottom (at least for me in my Visual Studio setup).
Would be better to all be at the bottom. But again, small thing...
That sounds more like a Visual Studio problem than anything I can fix in the compiler. flexspin and flexcc always output errors and warnings to stderr, and other messages to stdout.
If not, is there a way to use something like fullduplexserial() with FlexSpin C?
(or, a smartpin version of fullduplexserial())
The C standard doesn't have anything like that. If you're willing to be FlexC specific and just want serial input, the function _rxraw(n) returns a character from the serial port with an n millisecond timeout (if the timeout hits before the character arrives it returns -1). n=0 means no timeout, it blocks forever.
Using a Spin fullduplexserial object (or smartserial on P2) is done the same way as using any Spin object from C, via struct __using. The docs has this example:
Thanks! That first way is just what I needed.
I had resorted to using USB keyboard input, but this is simpler.
I used it to get this Tetris game working (attached).
It displays screen as ascii characters in terminal window.
Got it from here: https://github.com/Gregwar/ASCII-Tetris
@ersmith Re: FlexProp V5.0.6. I was chasing what I thought was a memory corruption bug in my string handling code. However, I think the corruption is being caused by the driver that talks up the USB channel to the GUI. This code demonstrates it:
var z = 0
var x$ = ""
x$ = "================================================================================================="
do
'pauseMS(100) '<-- uncomment this to "fix" it
print x$
print x$
print x$
print x$
print x$
z += 1
print "Loop Count: ";z
print
loop
My idea here is just to push lots of data up the comm channel to the PC. If you run the code without the delay, eventually (5-10 seconds) you'll start seeing erroneous data. But if you give it a short breather occasionally, then it works fine. Note that increasing things like HEAPSIZE or adding _gc_collect() does not affect this much at all.
Comments
playVideo("fun-1500.avi");where playVideo declared like this:void playVideo(char* filename) {//Play a .avi video using media fifo we will set up and top of RAM_GIs this warning warrented?I'm able to get rid of it like this:
I don't really understand the reason for the "const" attribute. Guess I should look that up one day...
Not yet. Having just one uSD card and changing the pins for it would be straightforward, but I suspect most uses for different pins would want there to be an option for multiple uSD cards, and that would require some work.
const before the star means that the data that is pointed to is read-only. A function that takes a string and only reads it and doesn't write to it must be declared to take a "const char *".
If you declare playVideo as: it'll get rid of the warning; this assumes, of course, that playVideo doesn't need to change the file name (which is likely true).
In FlexC literal strings are constant (should not be modified by the application), and that's what the "const" attribute means. Technically I'm not quite sure what the C standard says about this, but practically speaking it's a very bad idea to try to write over a literal string. For example, many compilers will put them in ROM, or share multiple instances of a single string.
I presume that less strict compliers wouldn't produce such a warning.
This sounds like a pretty serious issue! Hope it's mentioned in the docs...
Thank you all for the "const" info. I think I get it now...
I was just trying this:
struct __using("Antares.c") Ant; //RJA: Visual Studio will show an error here, but it's OK void setup() { Ant.begin(); }Looks like it's trying to work, but gives me some errors...
There is an alternative method where the bootfile is stored in the MBR/VOL sector(s) - for more info, see the P2 Boot ROM writeup thread.
...
I have a (not just by me) modified Version of KYE's driver supporting long filenames (might work in P2 too with the existing port the changes are just in Spin).
But if you have multiple copies of _BOOT_P2.BIX with too similar names then windows will start to even make a long filename out of a perfectly valid 8.3 name.
And there the trouble might arise. Because the boot process needs the 8.3 name.
So long filenames are possible, one just need to take care of having the boot file as 8.3, not sure how to force that when writing to SD in case of trouble...
Mike
And you cannot have files beginning with _BOOT_P2 as long file names. Not sure what parts the extension plays.
I've modified the current github so you can add defines for PIN_CLK, PIN_SS, PIN_MOSI, PIN_MISO on the command line to change the default pins. Documentation for that is in "general.md" under the "File I/O" section.
As I mentioned I'd like eventually to have some parameters to the _vfs_mount_sdcard() function to allow for multiple cards, but that will have to wait a bit.
Generally speaking it should work, although it does depend somewhat on what exactly is in "Antares.c". What errors are you getting?
This would help separate the namespace and make it look more like a class.
Here are the errors I get now:
1>D:/Propeller2/FastSpin/Demos_P2/Antares/Antares.c:17: error: Variable FifoWriteLocation is initialized twice 1>D:/Propeller2/FastSpin/Demos_P2/Antares/Antares.c:1186: error: syntax error, unexpected type name `LPCOLORREF', expecting identifier or '('Guess I look to see if they are really errors.
But then, I get a ton of errors and warnings like this:
I image it is due to the convoluted way I'm building the file...
To avoid adding Antares.c to the build command line, I've added it inside the Antares.h file like this:
I imaging that's the source of the problem...
Doesn't look like it's going to work. But, it's fine like it is anyway. I'll just leave it alone.
Only issue I really have is a couple of global variables like "w" and "h" that could easily be redefined by accident... Maybe I'll just rename them to something more complex.
BTW: The compiler output often says "1 succeeded" when it actually failed.
But, I've learned to look for the "Program size" message to tell if it really worked.
I believe you are running into the "no linker" issue. If you want to be able to call C functions in another c file, then in the header file for that other c file you need to add special __fromfile() tags to your declarations like this:
unsigned get_states(int endPin, int startPin) __fromfile("libsimpletools/getStates.c");This will cause the compiler to build the code referenced in the __fromfile() for your code to then be able to call.If/When we get a linker, then it can be done the normal way.
It sounds like the correct solution really is to put the .c file on the command line, if that's the way it's designed to be used. The FlexProp GUI doesn't directly support multiple files, but the command line tools do.
I see the Mandelbrot, but that looks to launch hubexec code...
Or, is better to do this with a Spin2 file and call it with the typdef struct way?
led_server_asm.c and led_server_pasm.c (both in the samples/ directory).
Sometimes the errors & warnings appear at the top of the output and sometimes at the bottom (at least for me in my Visual Studio setup).
Would be better to all be at the bottom. But again, small thing...
That sounds more like a Visual Studio problem than anything I can fix in the compiler. flexspin and flexcc always output errors and warnings to stderr, and other messages to stdout.
If not, is there a way to use something like fullduplexserial() with FlexSpin C?
(or, a smartpin version of fullduplexserial())
The C standard doesn't have anything like that. If you're willing to be FlexC specific and just want serial input, the function _rxraw(n) returns a character from the serial port with an n millisecond timeout (if the timeout hits before the character arrives it returns -1). n=0 means no timeout, it blocks forever.
Using a Spin fullduplexserial object (or smartserial on P2) is done the same way as using any Spin object from C, via struct __using. The docs has this example:
struct __using("FullDuplexSerial.spin") fds; void main() { fds.start(31, 30, 0, 115200); fds.str("hello, world!\r\n"); }I had resorted to using USB keyboard input, but this is simpler.
I used it to get this Tetris game working (attached).
It displays screen as ascii characters in terminal window.
Got it from here: https://github.com/Gregwar/ASCII-Tetris