results in a very strange error message: "Changing lastorg value for symbol startPid". The symbol startPid is defined in a global _asm{} block in a completely different file.
BTW, what is the printf "%" symbol for "please always use 4 digits even if the number is negative", i.e. print "FFFF" instead of "FFFFFFFF"?
And another one: (no bug, just an inconvenience)
After #inlude-ing <stdio.h> I got an error saying that the symbol "time" is redefined. Before the #include the file compiled without errors. I found out that <stdio.h> includes <sys/types.h> which somewhere defines a time. Well, in the end I had to simply rename my variable, no problem. But it would be very helpful if the "symbol redefined" message would also tell where the symbol had been declared FIRST.
results in a very strange error message: "Changing lastorg value for symbol startPid". The symbol startPid is defined in a global _asm{} block in a completely different file.
Would you be able to send me this example? I can understand why the two printfs are different (the first one can use the builtin printf, the second one calls the library because 'X' is not one of the letters handled by the built in one) but I cannot make either one cause an error in the examples I've tried.
BTW, what is the printf "%" symbol for "please always use 4 digits even if the number is negative", i.e. print "FFFF" instead of "FFFFFFFF"?
C doesn't have this feature. You have to use a mask, e.g.:
printf("x=%04X\n", x & 0xFFFF);
After #inlude-ing <stdio.h> I got an error saying that the symbol "time" is redefined. Before the #include the file compiled without errors. I found out that <stdio.h> includes <sys/types.h> which somewhere defines a time. Well, in the end I had to simply rename my variable, no problem. But it would be very helpful if the "symbol redefined" message would also tell where the symbol had been declared FIRST.
I'll see what I can do to improve the errors in these cases.
4.2.0 seems to break my inline assembly for eMMC driver. This is not using FCACHE. Doesn't work with FCACHE either.
Ah, right, that makes sense. Don't use --fcache for old timing sensitive code. Fastspin originally only used hubexec for inline assembly code. You can ignore the new warning, it should work.
Huh, you're right Eric. I had to reduce the later edition 297 MHz sysclock back down to 250 MHz but I think that was always true. I've been using my own low-level replacement code so haven't been keeping up with Rayman's low-level routines.
I have a compiler problem with these errors using fastspin v4.2.0. I also tried v4.1.9 with same issues.
C:\P2\Propeller_II_Latest\ClusoZ80>f420 test-002.spin2 -2 -l
Propeller Spin/PASM Compiler 'FastSpin' (c) 2011-2020 Total Spectrum Software Inc.
Version 4.2.0 Compiled on: May 29 2020
test-002.spin2
SD_LUT.spin2:72: error: syntax error, unexpected '='
SD_LUT.spin2:87: error: syntax error, unexpected '='
SD_LUT.spin2:93: error: syntax error, unexpected '='
The relevant lines are these
_hub = $fc500 ' base of sd driver hub code
sdx_cs = 60 ' pin SD Card select
sdx_sector = _regs +$001 ' sector number to read/write (shared with sdx_ctr1)
They are in an include file. If I put those lines into the main file and remove the included file it compiles fine. I tried renaming them but that didn't fix the problem. I looked at the source with embedded characters shown and there is nothing that I can see around those lines that might cause this error.
Would it be practical to modify the preprocessor so that #defines in a parent are visible to child objects? I'm trying to write a driver for a device that can interface via I2C or SPI and would like the user to be able to select which via #define at the application level without having to touch the driver.
Right now, it works by setting the define in the child (or manually on the command line with -D), but not in the parent. I thought I'd done this before successfully but I guess I must be mistaken
EDIT: Yes, I was - I was thinking of OpenSpin on the P1
@Cluso99 : It failed on the second CON line because it was trying to figure out the meaning of the first line, and it wasn't until the second line that it completely gave up. At that point it went into an error recovery mode and skipped ahead, apparently until after the next block of comments (the next time the indentation reset). Then the same thing happened again, and then a 3rd time. There were three times the indentation was reset by comments at the left margin, and I think that's why there were 3 error messages.
The parser is kind of a black box to me (it's built with yacc) so there's only so much I can do to change this behavior.
Would it be practical to modify the preprocessor so that #defines in a parent are visible to child objects? I'm trying to write a driver for a device that can interface via I2C or SPI and would like the user to be able to select which via #define at the application level without having to touch the driver.
Right now, it works by setting the define in the child (or manually on the command line with -D), but not in the parent. I thought I'd done this before successfully but I guess I must be mistaken
That would be quite difficult, unfortunately: the preprocessor is structured to deal with source files rather than objects.
However, I think you could achieve a similar effect by putting all the common code into a file "device_common.spin", and then creating two versions of the driver ("device_i2c" and "device_spi") which just #define the appropriate define and then #include "device_common.spin".
For example, device_i2c.spin would look like:
#define SPI 1
#include "device_common.spin"
The application would then use either "device_i2c" or "device_spi" as the object, but you'd only really have to maintain "device_common".
However, I think you could achieve a similar effect by putting all the common code into a file "device_common.spin", and then creating two versions of the driver ("device_i2c" and "device_spi") which just #define the appropriate define and then #include "device_common.spin".
For example, device_i2c.spin would look like:
#define SPI 1
#include "device_common.spin"
The application would then use either "device_i2c" or "device_spi" as the object, but you'd only really have to maintain "device_common".
Excellent suggestion; didn't think of that - that works!
That's really unfortunate if so...a preprocessor makes it so much easier to maintain different codebases. Without it, if you want to truly make a project, say, both PNut and FastSpin compatible (if the two are ever divergent in such a way that your app can't work with the same code on both), you need to maintain separate two sources - which means constantly keeping both synced.
@Cluso99 : It failed on the second CON line because it was trying to figure out the meaning of the first line, and it wasn't until the second line that it completely gave up. At that point it went into an error recovery mode and skipped ahead, apparently until after the next block of comments (the next time the indentation reset). Then the same thing happened again, and then a 3rd time. There were three times the indentation was reset by comments at the left margin, and I think that's why there were 3 error messages.
The parser is kind of a black box to me (it's built with yacc) so there's only so much I can do to change this behavior.
Thanks Eric.
Yes when the code being compiled has a bug, sometimes they cause compiler to go crazy and is to be expected.
When I was able to copy the lines into the main object and it compiled without the error I knew something was causing it. As I debugged it it became apparent that it wasn't actually the lines being reported and that ultimately led me to the missing CON. Evan must have found it around the same time as I did and he just pipped me to the post.
I guess that's what I get when cutting and pasting a block of code without properly checking I copied everything I need.
BTW Fastspin is working nicely. Great job! I'm loading LUT and can easily jump/call between COG/LUT/HUB.
I'm hitting issues with -O2 optimising in newest Fastspin. I'm trying to setup a streamer function and things have been crazy for me so as yet don't have details. When I've got something working I'll get back ...
That's really unfortunate if so...a preprocessor makes it so much easier to maintain different codebases. Without it, if you want to truly make a project, say, both PNut and FastSpin compatible (if the two are ever divergent in such a way that your app can't work with the same code on both), you need to maintain separate two sources - which means constantly keeping both synced.
Totally agree. Some people are against #include and #defines etc, and they can be easy to abuse, but it really helps maintain a single codeabase. Having to develop/maintain two versions of drivers, one for PNut and another one for Fastspin, is going to be a problem if there are differences that can't otherwise be avoided.
I can see that doing #defines/#includes in a self-hosted compiler running on the P2 could make things tricky however. Easier on a PC, and you could even use the existing C pre-processor if you have one installed.
I think I'm seeing something strange here...
If I don't do the explicit return, I get zero back... Doesn't seem like it should need the explicit return...
pub crc8x_pasm3(p_src, n) : crc | b
'' Returns CRC8 of n bytes at p_src
org
.loop rdbyte b, p_src
add p_src, #1
rev b
setq b
crcnib crc, #$8C
crcnib crc, #$8C
djnz n, #.loop
end
'return crc
@Rayman: Yes, it looks like the compiler isn't looking inside of inline assembly to see if the return variable ("crc" in your case) is ever set. That's a bug, I'll try to fix it. For now put an explicit "crc := 0" before the inline assembly; this will make sure the compiler sees that the return variable is used and set, and will also help the reader to see how the crc starts out.
The indentation of "ORG" definitely matters, it's how the compiler knows what the level of the inline assembly is (e.g. whether it goes inside or outside of a preceding IF or REPEAT block). It's like any other Spin statement. Only between the ORG and END is the indentation ignored.
Eric,
I had this error and fastspin reported an erroneous error in another module. Just thought you would like to know.
Missing $ in #$5A
wrlong #5A, lmm_p
C:\P2\Propeller_II_Latest\ClusoZ80>f420 z.spin2 -2 -l
Propeller Spin/PASM Compiler 'FastSpin' (c) 2011-2020 Total Spectrum Software Inc.
Version 4.2.0 Compiled on: May 29 2020
z.spin2
MON_CONST.spin2:130: error: syntax error, unexpected identifier `A', expecting instruction modifier or end of line or ','
@Cluso99: could you post a complete example? The error message you posted makes sense (the 'A' shows up after the '5' as a separate item). I gather the problem is that the file / line number are wrong?
Yes, both the file it was referring to was an included file and the line number was totally wrong - it pointed to a non existent line in the main file.
Think I shot past the problem so not sure I can go back. Should have zipped it at the time
Comments
printf ("x=%04x\n", x);works as expected butprintf ("x=%04X\n", x);results in a very strange error message: "Changing lastorg value for symbol startPid". The symbol startPid is defined in a global _asm{} block in a completely different file.BTW, what is the printf "%" symbol for "please always use 4 digits even if the number is negative", i.e. print "FFFF" instead of "FFFFFFFF"?
And another one: (no bug, just an inconvenience)
After #inlude-ing <stdio.h> I got an error saying that the symbol "time" is redefined. Before the #include the file compiled without errors. I found out that <stdio.h> includes <sys/types.h> which somewhere defines a time. Well, in the end I had to simply rename my variable, no problem. But it would be very helpful if the "symbol redefined" message would also tell where the symbol had been declared FIRST.
C doesn't have this feature. You have to use a mask, e.g.:
printf("x=%04X\n", x & 0xFFFF);I'll see what I can do to improve the errors in these cases.
printf("x=%04.4X\n", x);Postedit: Found it was missing CON section header. But it did not fail on the first, nor on the many, just 3 lines
Not sure about which options to use. I'm just doing this
I have a compiler problem with these errors using fastspin v4.2.0. I also tried v4.1.9 with same issues. The relevant lines are these They are in an include file. If I put those lines into the main file and remove the included file it compiles fine. I tried renaming them but that didn't fix the problem. I looked at the source with embedded characters shown and there is nothing that I can see around those lines that might cause this error.
Thanks Eric
I think you've missed out a CON directive.
Interestingly it didn't fail on the first equate line, nor on the all the others, just 3 of the many of equates.
Would it be practical to modify the preprocessor so that #defines in a parent are visible to child objects? I'm trying to write a driver for a device that can interface via I2C or SPI and would like the user to be able to select which via #define at the application level without having to touch the driver.
Right now, it works by setting the define in the child (or manually on the command line with -D), but not in the parent. I thought I'd done this before successfully but I guess I must be mistaken
EDIT: Yes, I was - I was thinking of OpenSpin on the P1
Thanks!
The parser is kind of a black box to me (it's built with yacc) so there's only so much I can do to change this behavior.
However, I think you could achieve a similar effect by putting all the common code into a file "device_common.spin", and then creating two versions of the driver ("device_i2c" and "device_spi") which just #define the appropriate define and then #include "device_common.spin".
For example, device_i2c.spin would look like: The application would then use either "device_i2c" or "device_spi" as the object, but you'd only really have to maintain "device_common".
I just tried this:
pub Test() PINL(56) pub Main() | r(BTW: Obviously, the first method is the main method, no matter what it is called.)
I see my P56 LED on eval board light for about one second and then goes out.
Is there some know state that the P2 is now in? Or, is it quasi-random?
Also, do you know if it is the same with the Parallax compiler?
Excellent suggestion; didn't think of that - that works!
Cheers
I don't know what Chip's runtime system does.
Thanks Eric.
Yes when the code being compiled has a bug, sometimes they cause compiler to go crazy and is to be expected.
When I was able to copy the lines into the main object and it compiled without the error I knew something was causing it. As I debugged it it became apparent that it wasn't actually the lines being reported and that ultimately led me to the missing CON. Evan must have found it around the same time as I did and he just pipped me to the post.
I guess that's what I get when cutting and pasting a block of code without properly checking I copied everything I need.
BTW Fastspin is working nicely. Great job! I'm loading LUT and can easily jump/call between COG/LUT/HUB.
#include <propeller2.h> #include <stdio.h> #define const1 (1.0 / 32768.0) #define const2 0.00003051757 // same as above float test (float f) { return f * 1.0; // shouldn't change anything } void main () { printf ("c1=%f c2=%f\n", const1, const2); // as expected float a = test (const1); float b = test (const2); printf ("a=%f b=%f\n", a, b); // surprise! }It seems to show up only in larger programs. I'll send you an example tomorrow. I'm out of office today.
Totally agree. Some people are against #include and #defines etc, and they can be easy to abuse, but it really helps maintain a single codeabase. Having to develop/maintain two versions of drivers, one for PNut and another one for Fastspin, is going to be a problem if there are differences that can't otherwise be avoided.
I can see that doing #defines/#includes in a self-hosted compiler running on the P2 could make things tricky however. Easier on a PC, and you could even use the existing C pre-processor if you have one installed.
If I don't do the explicit return, I get zero back... Doesn't seem like it should need the explicit return...
pub crc8x_pasm3(p_src, n) : crc | b '' Returns CRC8 of n bytes at p_src org .loop rdbyte b, p_src add p_src, #1 rev b setq b crcnib crc, #$8C crcnib crc, #$8C djnz n, #.loop end 'return crcWasn't sure it would...
The indentation of "ORG" definitely matters, it's how the compiler knows what the level of the inline assembly is (e.g. whether it goes inside or outside of a preceding IF or REPEAT block). It's like any other Spin statement. Only between the ORG and END is the indentation ignored.
I had this error and fastspin reported an erroneous error in another module. Just thought you would like to know.
Missing $ in #$5A
Think I shot past the problem so not sure I can go back. Should have zipped it at the time