@evanh : It builds for me (I just double checked with a fresh clone). I'm guessing you have to do a "make clean" to fix up dependencies, enough stuff has moved around that the dependency files are probably stale. If that doesn't work, throw the repo away and clone a new one.
It appears to choke on this: # define LV_COLOR_MAKE32(r8, g8, b8) {{b8, g8, r8, 0xff}} /*Fix 0xff alpha*/
with error: error: incompatible types in assignment: expected __struct__anon_98b868fb000000f5 but got multiple values
when used like this: return _LV_COLOR_MAKE_TYPE_HELPER LV_COLOR_MAKE32(r, g, b);
Guessing that define is a magic C way to combine several bytes into a long.
Could it be that this doesn't work in FlexSpin C yet?
No, actually the return value is supposed to be a structure:
@ersmith Ok, I think the real issue in the above is initialization of the union (in post above)...
After several defines, the code is trying to initialize the lv_color_32_t union like this: lv_color32_t rv{ { r,g,b,0xFF } };
which FlexSpin C is not happy with.
Looking some more...
After all the defines, I think the line with the issue looks like this:
return (lv_color32_t) { { r, g, b, 0xFF } };
So, it's trying to return a union directly as data...
FlexProp C looks OK with that as single brackets, but not double brackets.
So, seems this double bracket thing on the union initialization is the actual problem here...
@evanh said:
Grr, my GIT-foo is useless. The output from git pull shows what looks to be a moving of the two branches 'master' and 'release'. But my attempts at selecting the release branch go nowhere. eg: git branch only lists master.
AFAIK (on iPad right now, no git) git branch only shows the branches you checked out locally before. Use git branch -a for all branches. Then do git checkout, and afterwards git branch should show both.
Eric,
I've been comparing my Cordic testing with FlexC's built-in maths functions and happened to do a tanf() of 83.0 degrees and got an answer of 8.144338 with FlexC's built-ins, vs 8.144343 in my Cordic function. Being off by more than one count, I thought I should check elsewhere: My calculator says they should be 8.144346...
83.0 seems to be somewhat of a freak angle to try. None of the others I've tried have disagreed.
EDIT: Ah, here's a clue. I just printf()'d 83.0 as a float and it produced 83.000002.
EDIT2: Doh! And tan of that on the calculator is further away at 8.144349.
@deets said:
AFAIK (on iPad right now, no git) git branch only shows the branches you checked out locally before. Use git branch -a for all branches. Then do git checkout, and afterwards git branch should show both.
Ah, here we go git checkout release/v5.5 along with make clean and git pull ... I might be getting a handle on this.
EDIT: And yes, git branch -a gave me a list of several to choose from.
@evanh said:
Eric,
I've been comparing my Cordic testing with FlexC's built-in maths functions and happened to do a tanf() of 83.0 degrees and got an answer of 8.144338 with FlexC's built-ins, vs 8.144343 in my Cordic function. Being off by more than one count, I thought I should check elsewhere: My calculator says they should be 8.144346...
83.0 seems to be somewhat of a freak angle to try. None of the others I've tried have disagreed.
Hmm, looks like it's simply the 24-bit mantissa limitation when converting to int32 input angle of QROTATE. I guess that's the nature of tangent, approaching 90 deg gets coarse. Time to work on making full use of the 32-bit input angle ...
@evanh : There are a few problems with FlexC's math libraries, particularly the trig functions. Some of these are fixed in my BinFloat.spin2 object (in the github OBEX), which I haven't had a chance to integrate into FlexC yet. Some are just inherent to being restricted to 32 bits. Once I get 64 bit integers working then I'll be able to grab some routines from the PropGCC libraries which use 64 bits for more accurate results, e.g. in the printing.
There's also a "problem" with the CORDIC, namely that it returns fixed point numbers, and hence loses precision rapidly as the result gets close to 0. That's only an issue if you're using floating point arithmetic, obviously.
There was an obvious improvement I forgot to make, namely to use the Taylor's series for sin(x) instead of the CORDIC when x is small (so sin(x) is approximately x). I've checked in that change and the results are much closer (tan(83) gives 8.144345 now).
Nice! Yeah, I'm coming to terms with fixed-point limitations with trig too.
Looks like my bedtime thought, about nearing 90 degrees, was correct. I just tried 89.7 as input angle and the tan() results are horrible. Calculator says 190.984186..., FlexC built-in says 190.984330 and my Cordic version says 190.987770.
EDIT: I can see why there is no Cordic tangent feature. QROTATE returns both the sine and cosine. Tangent is sine divided by cosine. Dividing two zero-crossing equals generates extremes.
@evanh : One thing to remember is that all of the float results are only accurate to about 7 digits (24 bits), regardless of how many digits get printed. So you should ignore the digits after that, they're not "real". We have a tendency to kind of ignore the integer part of the result, but that "190" is consuming nearly half of the significant digits right off the bat...
Python says the correct answer to seven digits for tan(89.7 * pi / 180) should be 190.9842. Even gcc on Linux gives a result that's significantly off from that, namely 190.9799 (that's using single precision floats, so "tanf" rather than "tan").
Right, and same goes for float to int32 input to Cordic ops too. There is compounding loses.
PS: It would be more accurate to say 190 is a third of the binary bits, rather than half the decimal digits.
Hey there. Working on setting up FlexProp and VSCode first time on the Windows following the Quite Bite steps and run into a little snag I'm not seeing the reason for.
When I compile and it hits this spot:
obj
term : "jm_serial"
It spits out the error:
Unable to open file `\\vmware-host\Shared Folders\Documents\_Development\VSCode\Propeller2\SpinProjectTemplate\jm_serial': No such file or directory
The terminal process "C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe -Command flexspin.exe -2 -Wabs-paths -Wmax-errors=99 spin_top_file.spin2" terminated with exit code: 1.
Now I made sure spelling and everything else looked right. That the file was there and that it was not permissions blocked. But it just kept rejecting that simple line. As I check I went in and made it:
obj
term : "jm_serial.spin2"
And then it got passed that but complained about a similar line within jm_serial.spin2. If I also added the '.spin2' extension to the object used within jm_serial.spin2 then it compiles and produces the binary. I double checked the arguments but I don't see anything wrong there:
I was suspect of the -Wabs-paths but that seems to be a directive to print the full directory path rather than requiring the extension. Anyone know what I've got wrong here? Does n't make sense to need to go in and alter the object declarations of anything I use so I figure something is messed up just not sure where. If I open this up with the Propeller Tool application it compiles fine without the extensions being added.
Oh and just a final note: Thanks for making this! A spin to PASM compiler is something I have wanted to see for a long long time.
Eric,
Bug with Spin compiling: REPEAT from large positive to small positive with a negative delta still counts up when it should count down. eg: The below starts with "divd" at 64 then counts up, presumably until wraps back to negatives back up to 1.
repeat divd from 64 to 1 step -1
debug( sdec(divd) )
@evanh : thanks for the bug report. This is a place where Spin1 and Spin2 seem not to match, although flexspin didn't agree with either of them. It should be fixed now in the github sources.
Eric,
Bug with Spin compiling: REPEAT from large positive to small positive with a negative delta still counts up when it should count down. eg: The below starts with "divd" at 64 then counts up, presumably until wraps back to negatives back up to 1.
repeat divd from 64 to 1 step -1
debug( sdec(divd) )
I used this also: "step - 1" was not needed when counting down.
2021-08-23 21:50 Flag
@evanh : thanks for the bug report. This is a place where Spin1 and Spin2 seem not to match, although flexspin didn't agree with either of them. It should be fixed now in the github sources.
Now, what I have to do with these loops after I upgrade my Flexprop version? I have several of them.
Edit: the mess deleted (I don't know what caused this)
Bug with Spin compiling: REPEAT from large positive to small positive with a negative delta still counts up when it should count down. eg: The below starts with "divd" at 64 then counts up, presumably until wraps back to negatives back up to 1.
repeat divd from 64 to 1 step -1
debug( sdec(divd) )
I used this also: "step - 1" was not needed when counting down.
Correct, and the bug only was a problem when an explicit "step" was given. If you have no "step" in your loops then no change will be required to your code.
Getting errors on a super simple c code when optimizations are disabled:
C:/FlexProp/include/FlexEdit2.p2asm:441: error: Unknown symbol __system____getfilebuffer
C:/FlexProp/include/FlexEdit2.p2asm:448: error: Unknown symbol __system____getvfsforfile
//Flex C Stub
#include <propeller.h> //For all things propeller
#include <stdio.h> //for printf()
#define TOGGLEPIN 58 //I/O pin to toggle
void main()
{//Toggle pin forever
int i=0;
for(;;)
{
_pinnot(TOGGLEPIN);
_waitms(1000);
printf("toggle % u\n", i++);
}
}
@Rayman: you've found another interesting bug, but it's actually in the flexspin bug reporting system. For now I think the work around is to fix your printf format string to get rid of the space between the % and the u.
@ersmith said:
@Rayman: you've found another interesting bug, but it's actually in the flexspin bug reporting system. For now I think the work around is to fix your printf format string to get rid of the space between the % and the u.
Is it OK in C to allow a space between the "%" and "u"? I went to the K&R book and it seems to indicate that conversion specifications can only have a very few things before the conversion character but none are a space. I'm just a curious perpetual C rookie, not being Mr. Pedantic... Totally OT, apologies!
Actually as it happens space is legal in a printf format descriptor, but is ignored for unsigned formats (like %u). It's a very rarely used feature that allows printing a space in front of positive numbers (so printing ' ' / '-' for positive/negative). So I was wrong about the error handling being the problem.
The problem only shows up with -O0 because space isn't handled by the builtin printf, and so it gets turned into a library call. That process isn't working right in -O0. I'm looking into that, but the work-around (get rid of the space) will produce better code anyway, and since space is ignored for %u it won't affect the output.
Comments
@evanh : It builds for me (I just double checked with a fresh clone). I'm guessing you have to do a "make clean" to fix up dependencies, enough stuff has moved around that the dependency files are probably stale. If that doesn't work, throw the repo away and clone a new one.
huh, make clean worked. Should have tried that earlier. I can now compile Rayman's latest font stuff.
Thanks again Eric.
Took a shot at compiling LVGL https://github.com/lvgl/lvgl
It's probably hopeless, but trying anyway...
It appears to choke on this:
# define LV_COLOR_MAKE32(r8, g8, b8) {{b8, g8, r8, 0xff}} /*Fix 0xff alpha*/with error:
error: incompatible types in assignment: expected __struct__anon_98b868fb000000f5 but got multiple valueswhen used like this:
return _LV_COLOR_MAKE_TYPE_HELPER LV_COLOR_MAKE32(r, g, b);Guessing that define is a magic C way to combine several bytes into a long.
Could it be that this doesn't work in FlexSpin C yet?
No, actually the return value is supposed to be a structure:
typedef union { struct { uint8_t blue; uint8_t green; uint8_t red; uint8_t alpha; } ch; uint32_t full; } lv_color32_t;So, I guess the define is populating this structure...
@ersmith Ok, I think the real issue in the above is initialization of the union (in post above)...
After several defines, the code is trying to initialize the lv_color_32_t union like this:
lv_color32_t rv{ { r,g,b,0xFF } };which FlexSpin C is not happy with.
Looking some more...
After all the defines, I think the line with the issue looks like this:
return (lv_color32_t) { { r, g, b, 0xFF } };
So, it's trying to return a union directly as data...
FlexProp C looks OK with that as single brackets, but not double brackets.
So, seems this double bracket thing on the union initialization is the actual problem here...
AFAIK (on iPad right now, no git)
git branchonly shows the branches you checked out locally before. Usegit branch -afor all branches. Then do git checkout, and afterwardsgit branchshould show both.Eric,
I've been comparing my Cordic testing with FlexC's built-in maths functions and happened to do a tanf() of 83.0 degrees and got an answer of 8.144338 with FlexC's built-ins, vs 8.144343 in my Cordic function. Being off by more than one count, I thought I should check elsewhere: My calculator says they should be 8.144346...
83.0 seems to be somewhat of a freak angle to try. None of the others I've tried have disagreed.
EDIT: Ah, here's a clue. I just printf()'d 83.0 as a float and it produced 83.000002.
EDIT2: Doh! And tan of that on the calculator is further away at 8.144349.
Ah, here we go
git checkout release/v5.5along withmake cleanandgit pull... I might be getting a handle on this.EDIT: And yes,
git branch -agave me a list of several to choose from.Hmm, looks like it's simply the 24-bit mantissa limitation when converting to int32 input angle of QROTATE. I guess that's the nature of tangent, approaching 90 deg gets coarse. Time to work on making full use of the 32-bit input angle ...
@evanh : There are a few problems with FlexC's math libraries, particularly the trig functions. Some of these are fixed in my BinFloat.spin2 object (in the github OBEX), which I haven't had a chance to integrate into FlexC yet. Some are just inherent to being restricted to 32 bits. Once I get 64 bit integers working then I'll be able to grab some routines from the PropGCC libraries which use 64 bits for more accurate results, e.g. in the printing.
There's also a "problem" with the CORDIC, namely that it returns fixed point numbers, and hence loses precision rapidly as the result gets close to 0. That's only an issue if you're using floating point arithmetic, obviously.
There was an obvious improvement I forgot to make, namely to use the Taylor's series for sin(x) instead of the CORDIC when x is small (so sin(x) is approximately x). I've checked in that change and the results are much closer (tan(83) gives 8.144345 now).
Nice! Yeah, I'm coming to terms with fixed-point limitations with trig too.
Looks like my bedtime thought, about nearing 90 degrees, was correct. I just tried 89.7 as input angle and the tan() results are horrible. Calculator says 190.984186..., FlexC built-in says 190.984330 and my Cordic version says 190.987770.
EDIT: I can see why there is no Cordic tangent feature. QROTATE returns both the sine and cosine. Tangent is sine divided by cosine. Dividing two zero-crossing equals generates extremes.
@evanh : One thing to remember is that all of the float results are only accurate to about 7 digits (24 bits), regardless of how many digits get printed. So you should ignore the digits after that, they're not "real". We have a tendency to kind of ignore the integer part of the result, but that "190" is consuming nearly half of the significant digits right off the bat...
Python says the correct answer to seven digits for tan(89.7 * pi / 180) should be 190.9842. Even gcc on Linux gives a result that's significantly off from that, namely 190.9799 (that's using single precision floats, so "tanf" rather than "tan").
Right, and same goes for float to int32 input to Cordic ops too. There is compounding loses.
PS: It would be more accurate to say 190 is a third of the binary bits, rather than half the decimal digits.
Eric,
Found, and used, a function not in the docs:
_cogid()Hey there. Working on setting up FlexProp and VSCode first time on the Windows following the Quite Bite steps and run into a little snag I'm not seeing the reason for.
When I compile and it hits this spot:
It spits out the error:
Now I made sure spelling and everything else looked right. That the file was there and that it was not permissions blocked. But it just kept rejecting that simple line. As I check I went in and made it:
And then it got passed that but complained about a similar line within jm_serial.spin2. If I also added the '.spin2' extension to the object used within jm_serial.spin2 then it compiles and produces the binary. I double checked the arguments but I don't see anything wrong there:
Executing task: flexspin.exe -2 -Wabs-paths -Wmax-errors=99 spin_top_file.spin2I was suspect of the -Wabs-paths but that seems to be a directive to print the full directory path rather than requiring the extension. Anyone know what I've got wrong here? Does n't make sense to need to go in and alter the object declarations of anything I use so I figure something is messed up just not sure where. If I open this up with the Propeller Tool application it compiles fine without the extensions being added.
Oh and just a final note: Thanks for making this! A spin to PASM compiler is something I have wanted to see for a long long time.
It is the -Wabs-paths option that's causing problems. I suggest taking that out if you can.
Ahhhhh dang it.. I should have tried that since I was suspicious of it.
Done and bingo. That was it. Thanks!
Eric,
Bug with Spin compiling: REPEAT from large positive to small positive with a negative delta still counts up when it should count down. eg: The below starts with "divd" at 64 then counts up, presumably until wraps back to negatives back up to 1.
repeat divd from 64 to 1 step -1 debug( sdec(divd) )@evanh : thanks for the bug report. This is a place where Spin1 and Spin2 seem not to match, although flexspin didn't agree with either of them. It should be fixed now in the github sources.
As far as I remember the step thing in Spin1 is sort of broken.
So a
repeat from 64 to 1 works WITHOUT step -1 as you WOULD expect with adding step -1.
by adding step -1 you break it.
Never tested this in Spin2 but Spin1 seems to calculate the step direction by itself, adding it breaks it.
Works fine the other way around counting low to high.
Never figured it out.
Mike
I didn't think to try removing "step". It's definitely fixed in Pnut anyway.
Thanks Eric,
It tidied up that loop nicely. I keep changing things but I'm pretty happy with what I've got now. See attached.
EDIT: Grr, forgot about the "baudset" hack. Doesn't even work with Pnut. In FlexC I get to use _setbaud() and all is good. No fix at this stage ...
@evanh said:
I used this also: "step - 1" was not needed when counting down.
2021-08-23 21:50 Flag
Now, what I have to do with these loops after I upgrade my Flexprop version? I have several of them.
Edit: the mess deleted (I don't know what caused this)
Correct, and the bug only was a problem when an explicit "step" was given. If you have no "step" in your loops then no change will be required to your code.
Getting errors on a super simple c code when optimizations are disabled:
C:/FlexProp/include/FlexEdit2.p2asm:441: error: Unknown symbol __system____getfilebuffer
C:/FlexProp/include/FlexEdit2.p2asm:448: error: Unknown symbol __system____getvfsforfile
//Flex C Stub #include <propeller.h> //For all things propeller #include <stdio.h> //for printf() #define TOGGLEPIN 58 //I/O pin to toggle void main() {//Toggle pin forever int i=0; for(;;) { _pinnot(TOGGLEPIN); _waitms(1000); printf("toggle % u\n", i++); } }@Rayman: you've found another interesting bug, but it's actually in the flexspin bug reporting system. For now I think the work around is to fix your printf format string to get rid of the space between the % and the u.
Is it OK in C to allow a space between the "%" and "u"? I went to the K&R book and it seems to indicate that conversion specifications can only have a very few things before the conversion character but none are a space. I'm just a curious perpetual C rookie, not being Mr. Pedantic... Totally OT, apologies!
I doubt it is legal. Eric will be looking into why the error message is vague and also why there is no error with optimising.
Actually as it happens space is legal in a printf format descriptor, but is ignored for unsigned formats (like %u). It's a very rarely used feature that allows printing a space in front of positive numbers (so printing ' ' / '-' for positive/negative). So I was wrong about the error handling being the problem.
The problem only shows up with -O0 because space isn't handled by the builtin printf, and so it gets turned into a library call. That process isn't working right in -O0. I'm looking into that, but the work-around (get rid of the space) will produce better code anyway, and since space is ignored for %u it won't affect the output.
Interesting… didn’t add the space on purpose but nice to learn about this nuance.