@ersmith
I understand, that is not necessary to implement sin() and cos() in fastspin.
Therefore we have the cordic - unit.
But is it possible to implement asin() and acos() ?
or does someone know a way to calculate these functions with the available means?
I need this for a 'hot' project.
Reinhard
I think you could implement asin() and acos() in terms of the CORDIC xy to polar conversion. That is, acos(x) is the angle t for which cos(t) = x, so it's the angle you get when you convert (x, sqrt(1-x^2)) to polar coordinates (if x is in the appropriate quadrant, and is between 0 and 1). You do have to do some sanity checking and have code to handle negatives and such, but that's the basic idea. asin() is similar.
@ersmith
I understand, that is not necessary to implement sin() and cos() in fastspin.
Therefore we have the cordic - unit.
But is it possible to implement asin() and acos() ?
or does someone know a way to calculate these functions with the available means?
I need this for a 'hot' project.
Reinhard
I think you could implement asin() and acos() in terms of the CORDIC xy to polar conversion. That is, acos(x) is the angle t for which cos(t) = x, so it's the angle you get when you convert (x, sqrt(1-x^2)) to polar coordinates (if x is in the appropriate quadrant, and is between 0 and 1). You do have to do some sanity checking and have code to handle negatives and such, but that's the basic idea. asin() is similar.
this is very good, also we can floats pass to the asm - block.
THX
Be careful with using floats in assembly, not very many instructions actually operate on floating point values. Even with the --fixed option to FlexGUI you should make sure that the instructions do what you want with 16.16 fixed point values; for example some of the CORDIC operations use 0.32 fixed point.
I'm seeing something that should give an error, but doesn't...
I removed the CON section definition for nco_baud from a code.
This line should now give an error, but it doesn't:
wxpin ##nco_baud, #TX_PIN 'set tx bit period
It's rather difficult to diagnose without any context. I'm guessing that line is in inline assembly inside a method that wasn't used, in which case, that's a feature, not a bug -- inline assembly isn't parsed until the method is actually compiled, and if it's never used it'll never be compiled.
For the lazy out there (pointing at myself), is there a binary distro for Raspberry Pi available?
Perhaps from @DavidZemon 's build server?
I'd taken a cursory look there and didn't see a successful build after 500ms of looking. Digging a little deeper, I found an older build that did succeed (4.0.0-beta).
The current version makefile is failing at the make clean target... tonight I'll try building locally to see if it's a CI error or some weird RPi error and share findings here.
Thanks to everyone here who makes my short attention span work on the prop possible.
For the lazy out there (pointing at myself), is there a binary distro for Raspberry Pi available?
Perhaps from @DavidZemon 's build server?
I'd taken a cursory look there and didn't see a successful build after 500ms of looking. Digging a little deeper, I found an older build that did succeed (4.0.0-beta).
The current version makefile is failing at the make clean target... tonight I'll try building locally to see if it's a CI error or some weird RPi error and share findings here.
Thanks to everyone here who makes my short attention span work on the prop possible.
Yea... I've slacking pretty bad in keeping the build configurations up-to-date. I'll try to take another look soon and get it going again.
For the lazy out there (pointing at myself), is there a binary distro for Raspberry Pi available?
Perhaps from @DavidZemon 's build server?
I'd taken a cursory look there and didn't see a successful build after 500ms of looking. Digging a little deeper, I found an older build that did succeed (4.0.0-beta).
The current version makefile is failing at the make clean target... tonight I'll try building locally to see if it's a CI error or some weird RPi error and share findings here.
Thanks to everyone here who makes my short attention span work on the prop possible.
Yea... I've slacking pretty bad in keeping the build configurations up-to-date. I'll try to take another look soon and get it going again.
Seeing all the work in setting up the CI system, I'd never call you a slacker...
Just a note, I went ahead and pulled the latest spin2cpp (4.1.2-beta-ea965163) from GitHub to my RPi and it builds clean.
It's beyond me what in the CI path is failing though... let me know if I can test anything here for you though.
For the lazy out there (pointing at myself), is there a binary distro for Raspberry Pi available?
Perhaps from @DavidZemon 's build server?
I'd taken a cursory look there and didn't see a successful build after 500ms of looking. Digging a little deeper, I found an older build that did succeed (4.0.0-beta).
The current version makefile is failing at the make clean target... tonight I'll try building locally to see if it's a CI error or some weird RPi error and share findings here.
Thanks to everyone here who makes my short attention span work on the prop possible.
Yea... I've slacking pretty bad in keeping the build configurations up-to-date. I'll try to take another look soon and get it going again.
Seeing all the work in setting up the CI system, I'd never call you a slacker...
Just a note, I went ahead and pulled the latest spin2cpp (4.1.2-beta-ea965163) from GitHub to my RPi and it builds clean.
It's beyond me what in the CI path is failing though... let me know if I can test anything here for you though.
I think I'm seeing something wrong here, but maybe I'm just doing something wrong...
These two codes should do the same thing, but they don't... The first one doesn't work right.
Anybody see the error?
This one broke:
setq #200
wrlong ptrb,ptra
This one works:
rep @.end,#200
wrlong ptrb,ptra++
.end
I'm just trying to write the value in ptrb to several consecutive longs starting at address in ptra...
Compiler doesn't like these last two lines...
Gives this error: error: Internal Error: emitting move to immediate
That error message should be more informative (as you noticed later, it's because of an assignment to a constant). I'll get it to print something like "error: assignment to constant `row'" instead.
Got another strange error when I copied "Graphics_Demo" code into my tile driver test...
I'm sure there are errors, especially with the buffers not yet being defined and such.
But, the strange thing is that it gives me four error messages, all the same.
They all point to the last line of the files (which happens to be blank) and says:
"Unable to determine size of array"
I see the error it is referring to now...
There are lines like this in a var section.
byte x[lines]
But, I hadn't yet copied over the CON section with "lines".
Of course, that's an error, just not sure why it pointed to the last line of the file...
The technical reason it's pointing to the last line of the file is that it doesn't know for sure that the constant "lines" isn't defined until it's scanned the whole file (Spin allows CON and VAR to be mixed in any order). But it's still puzzling, because normally it does save line number info for variable declarations, and uses that saved info. When I tried it just now it did print the correct line number for the array. There must be a case where it's getting the saved info wrong. Are you able to share a repro case?
In many situations we should be able to print the name of the array, and that would be helpful, so I can at least add that.
It's probably more trouble that it's worth to fix this...
This was a badly broken example...
It'd also take me some time to go back to where it was broke...
Sorry, I meant for the Spin versions of these (when starting assembly).
I don't think that is described anywhere...
Chip is still writing the Spin2 documentation, I think. But anyway, the Spin versions do the same thing as the assembly versions, both on P1 (putting the parameter in PAR) and P2 (putting the parameter in PTRA).
Comments
I do that and it works perfect.
// phi2 = acos (res1) res2 = sqrt(1.0 - res1 * res1); __asm{ qvector res1,res2 getqx t1 getqy t2 }; phi2 = t2 * CORDIC_RESOLUTION;I never use t1 in the C - Programm.How I see in the pasm file, fastspin do this: this is very good, also we can floats pass to the asm - block.
THX
Be careful with using floats in assembly, not very many instructions actually operate on floating point values. Even with the --fixed option to FlexGUI you should make sure that the instructions do what you want with 16.16 fixed point values; for example some of the CORDIC operations use 0.32 fixed point.
Chip has added a new feature called "addpins" to his Pasm2 for the purpose of encoding consecutive pins to the immediate value at least. He's used it in his latest flash_loader.spin2 - https://forums.parallax.com/discussion/comment/1488247/#Comment_1488247
I removed the CON section definition for nco_baud from a code.
This line should now give an error, but it doesn't:
Looks like "a addpins b" is syntactic sugar for "a | (b<<6)". I can add that to Spin, but it won't work in inline assembly for C or BASIC.
It's rather difficult to diagnose without any context. I'm guessing that line is in inline assembly inside a method that wasn't used, in which case, that's a feature, not a bug -- inline assembly isn't parsed until the method is actually compiled, and if it's never used it'll never be compiled.
Perhaps from @DavidZemon 's build server?
I put stop first so that it doesn’t do anything if ran alone.
I suppose that technically means that the asm is never run if ran alone.
But, that is not the intent...
The intent is to call start from another spin file...
I wonder if Chip is going to do that for other multi-field situations like HUBSET, WRPIN, COGINIT ... the streamers are quite a handful.
I'd taken a cursory look there and didn't see a successful build after 500ms of looking. Digging a little deeper, I found an older build that did succeed (4.0.0-beta).
The current version makefile is failing at the make clean target... tonight I'll try building locally to see if it's a CI error or some weird RPi error and share findings here.
Thanks to everyone here who makes my short attention span work on the prop possible.
Yea... I've slacking pretty bad in keeping the build configurations up-to-date. I'll try to take another look soon and get it going again.
Seeing all the work in setting up the CI system, I'd never call you a slacker...
Just a note, I went ahead and pulled the latest spin2cpp (4.1.2-beta-ea965163) from GitHub to my RPi and it builds clean.
It's beyond me what in the CI path is failing though... let me know if I can test anything here for you though.
-joe
Thanks, I'll do that.
These two codes should do the same thing, but they don't... The first one doesn't work right.
Anybody see the error?
This one broke:
setq #200 wrlong ptrb,ptraThis one works:
rep @.end,#200 wrlong ptrb,ptra++ .endI'm just trying to write the value in ptrb to several consecutive longs starting at address in ptra...
setq advances both ptrb and ptra….
The REP will cycle every 9 sysclocks. If you decremented it'll cycle every 7 sysclocks. The following will fill a longword every 3 sysclocks: Obviously needs size increments of 32 bytes though.
Another option is have a small empty space in the cog and repeatedly block copy that. With the extra stalls it may not be all that much faster.
I just made this little Spin routine:
PUB VGA_Print(c)|oldCols,oldRows 'patch to make original VGA_Demo work oldCols:=cols oldRows:=rows Print(c) Cols:=oldCols rows:=oldRowsCompiler doesn't like these last two lines...
Gives this error: error: Internal Error: emitting move to immediate
That error message should be more informative (as you noticed later, it's because of an assignment to a constant). I'll get it to print something like "error: assignment to constant `row'" instead.
Thanks,
Eric
I'm sure there are errors, especially with the buffers not yet being defined and such.
But, the strange thing is that it gives me four error messages, all the same.
They all point to the last line of the files (which happens to be blank) and says:
"Unable to determine size of array"
There are lines like this in a var section. But, I hadn't yet copied over the CON section with "lines".
Of course, that's an error, just not sure why it pointed to the last line of the file...
The technical reason it's pointing to the last line of the file is that it doesn't know for sure that the constant "lines" isn't defined until it's scanned the whole file (Spin allows CON and VAR to be mixed in any order). But it's still puzzling, because normally it does save line number info for variable declarations, and uses that saved info. When I tried it just now it did print the correct line number for the array. There must be a case where it's getting the saved info wrong. Are you able to share a repro case?
In many situations we should be able to print the name of the array, and that would be helpful, so I can at least add that.
This was a badly broken example...
It'd also take me some time to go back to where it was broke...
Is this spelled out anywhere?
There is no PAR register anymore... Does it go to PTRA?
Yes, it goes to PTRA on P2. It's documented in Chip's "Parallax Propeller 2 Documentation" Google document.
I don't think that is described anywhere...
Chip is still writing the Spin2 documentation, I think. But anyway, the Spin versions do the same thing as the assembly versions, both on P1 (putting the parameter in PAR) and P2 (putting the parameter in PTRA).
I'm trying to pass a small auto array to inline assembly. But the pointer still seems to be a hub address.
{ long data[10] = {1,2,3,4,5,6,7,8,9,10}; long *addr = data; int len = sizeof(data) / 4 - 1; printf( "addr = %lx, len = %d\n", addr, len ); __asm { ... } }The print is giving me values above 0x1000. What's wrong?