I am following the basic p1 type of code. I wish to just start simple and take a value form spin to pasm and move it to another value and display it in spin in a new variable.
thanks
Also have been reviewing lots of code. Need to get a simple handle on the transfer from spin code or c code to the pasm and back to trtansfer data from spin or c variable and back. Was told that ptra is the equivalent of par in p1 just not able to make it work.
Thanks
I am following the basic p1 type of code. I wish to just start simple and take a value form spin to pasm and move it to another value and display it in spin in a new variable.
thanks
You don't stop the cog so it will crash and do unpredictable things.
cogid temp
cogstop temp
The second "mov" does nothing, because "_data" is immediately written over by the "rdlong". In general it looks like you're confused between "mov" and "rdlong/wrlong". "mov" is for moving things between registers inside the PASM code. "rdlong" and "wrlong" are for reading and writing to HUB memory, which is where the member variables like "data" and "answer" are. In this respect the P2 is just like the P1.
(2) As Mark_T noted, you're not stopping the worker cog when it is finished.
(3) There's no synchronization between the cogs. In this particular case it probably doesn't matter -- the worker COG is doing something very simple, and it'll finish before the original COG has finished printing the "answer" string. But in general you need to be careful to make sure the worker COG has finished its work before trying to use its answer.
I've attached a program where the worker cog adds 1 to the original data.
@ersmith
Thanks. I looked at your code. I forgot that David Carrier at parallax told me that that unlike the P1 in the P2 we are working from hub ram versus going
from cog ram and hub ram. I think? This obviates the need for the mov's back and forth as in the P1.
I will try your code tonight.
Eric,
I've been using version 1.3.7 and today I upgraded to v1.3.9.
When I tried to run a program that used
OBJ
ser: "PrintfSerial.spin"
I got an error. I see that there is no longer a lib folder, so I copied "PrintfSerial.spin" to the include/spin folder, but found that still didn't work unless I placed "spin/" as part of the OBJ file name.
Has "PrintfSerial.spin" been deliberately removed? And has the auto finding of library files been removed?
edit: I moved printfSerial.spin to the include/ folder and it works without having to specify the spin/path.
Has "PrintfSerial.spin" been deliberately removed? And has the auto finding of library files been removed?
Yes, "PrintfSerial.spin" has been deliberately removed, because all the serial modules support printf now (including FullDuplexSerial). You just use:
OBJ ser: "spin/SmartSerial" ' or "spin/FullDuplexSerial", or "spin/SimpleSerial", or whatever
...
ser.printf("hello, world\n")
Note that the newline is "\n" now instead of "%n", which is more what people who are used to using printf would expect.
The files under include/ are found automatically. If your library modules are somewhere else, you have to explicitly set the library path in the spin2gui menu. I think it still defaults to the lib/ directory, unless I'm misremembering.
@ersmith
I really thank you put me back on track. I am not a really good programmer in asm.
See my tutorial on P1 pasm. but with the jumpstart I can move forward.
the rest is fairly easy
I am getting used to working in hub ram. Question why do I need to point back to ptra.Please see the attached file where I have put the multple "?????????????"
If you're doing any programming work on Microsoft Windows you should enable file extensions.
In windows explorer or what can also be called the file browser that lists these files, do the following steps:
1) If you don't see a menu at the top of the file browser window [File Edit View Tools Help] press and release the "Alt" key on your keyboard once while in the folder and it should appear.
2) go to to Tools menu, and select "Folder Options..." from the dropdown list.
3) Click on the "View" tab, usually the second item to the right of "General".
4) In the "Advanced Settings" list, scroll down to and uncheck [ ] Hide extensions for known file types.
5) Click [Apply], click [OK]
Now the file browser will always show file extensions and there will be less confusion:
.spin2, .binary, .lst, .p2asm
Thanks for the tip on windows. Always ready for new stuff on windows.
Back to my original question above.
As opposed to P1 pasm why do I have to point back to ptra?? at the end
Hope I sent the correct file. Found the spin2 file.
"data" is located at the original ptra value.
Your Spin2 program waits until the value of "data" is zero.
In the P2asm you are writing "0" to the location specified by ptra. You want that to be "data" so you need to set ptra to its original ("data" location) value.
On entering the P2asm you could have saved ptra in another variable and that way once the calculation was done just recalled the saved value to ptra. But I have usually seen it done the way you did.
There's no real difference between P1 and P2 in the handling of hub memory for a simple program like this. In both cases the value passed to the PASM program (either par or ptra) is a pointer into memory. The pointer starts pointing at "data". In memory we have "data", "data2", and "answer" in that order, so to read "data2" we have to add 4 to the original pointer, and to read or write "answer" we have to add 8 to the original pointer, since each item is a LONG (4 bytes).
The Spin code waits for the COG to be finished. Your code does this by waiting for the original variable "data" to be set to 0:
'' wait until the COG has finished
'' it indicates this by clearing "data"
repeat while data <> 0
So after we have written "answer" in the PASM code we back up to the original pointer value where it pointed at "data" by subtracting 8, and then write a 0 there.
This probably isn't the best approach, since it means we cannot use a value of 0 for the original data. Better would be to have a separate "finished" variable which indicates that the PASM is done.
All this is exactly the same between P1 and P2. Some P1 programs don't bother with synchronization (waiting for the PASM to finish) because PASM is very fast and Spin bytecode is very slow, so they just assume that the PASM code is finished with answer by the time the Spin gets to it. But that assumption will fail for complicated computations or if you use a faster Spin compiler, so they really should do this.
I can duplicate the "no such file or directory" error you're seeing.
Because spin2gui no longer locks the file while it is open, you can move that file or even delete it.
Or you can even move the folder somewhere else, and again because it's not locked, windows won't complain that it is in use.
So then if you hit for example compile, you see that message.
Edit:
Oh! You can also run into issues having two or more instances of Spin 2 GUI open on the same file.
Then move or delete or rename the file that is open or the folder that it's in, then try to do things from the Spin 2 GUI menu like Save As.
I don't really think this is a bug per se, just user error.
Attempted to use fullduplexserial as shown in the doc's. It was a no go got errors in fds. Is there a better example??
FullDuplexSerial is only for P1, not for P2. I will add a note to that effect in the docs, although I don't think any of the samples there were complete. There are complete examples that work on both P1 and P2 in the samples/ directory of the spin2gui release.
Comments
Thanks again Rayman. Now to learn a little...
thanks
Thanks
You don't stop the cog so it will crash and do unpredictable things.
cogid temp
cogstop temp
(1) There's a lot of funny moving registers around, e.g.: The second "mov" does nothing, because "_data" is immediately written over by the "rdlong". In general it looks like you're confused between "mov" and "rdlong/wrlong". "mov" is for moving things between registers inside the PASM code. "rdlong" and "wrlong" are for reading and writing to HUB memory, which is where the member variables like "data" and "answer" are. In this respect the P2 is just like the P1.
(2) As Mark_T noted, you're not stopping the worker cog when it is finished.
(3) There's no synchronization between the cogs. In this particular case it probably doesn't matter -- the worker COG is doing something very simple, and it'll finish before the original COG has finished printing the "answer" string. But in general you need to be careful to make sure the worker COG has finished its work before trying to use its answer.
I've attached a program where the worker cog adds 1 to the original data.
Thanks. I looked at your code. I forgot that David Carrier at parallax told me that that unlike the P1 in the P2 we are working from hub ram versus going
from cog ram and hub ram. I think? This obviates the need for the mov's back and forth as in the P1.
I will try your code tonight.
I've been using version 1.3.7 and today I upgraded to v1.3.9.
When I tried to run a program that used
OBJ ser: "PrintfSerial.spin"I got an error. I see that there is no longer a lib folder, so I copied "PrintfSerial.spin" to the include/spin folder, but found that still didn't work unless I placed "spin/" as part of the OBJ file name.
Has "PrintfSerial.spin" been deliberately removed? And has the auto finding of library files been removed?
edit: I moved printfSerial.spin to the include/ folder and it works without having to specify the spin/path.
Thanks
Tom
Yes, "PrintfSerial.spin" has been deliberately removed, because all the serial modules support printf now (including FullDuplexSerial). You just use:
OBJ ser: "spin/SmartSerial" ' or "spin/FullDuplexSerial", or "spin/SimpleSerial", or whatever ... ser.printf("hello, world\n")Note that the newline is "\n" now instead of "%n", which is more what people who are used to using printf would expect.The files under include/ are found automatically. If your library modules are somewhere else, you have to explicitly set the library path in the spin2gui menu. I think it still defaults to the lib/ directory, unless I'm misremembering.
Thanks for the code. I am now jumpstarted. Put me back on track.
Martin
I really thank you put me back on track. I am not a really good programmer in asm.
See my tutorial on P1 pasm. but with the jumpstart I can move forward.
the rest is fairly easy
I am getting used to working in hub ram. Question why do I need to point back to ptra.Please see the attached file where I have put the multple "?????????????"
If you're doing any programming work on Microsoft Windows you should enable file extensions.
In windows explorer or what can also be called the file browser that lists these files, do the following steps:
1) If you don't see a menu at the top of the file browser window [File Edit View Tools Help] press and release the "Alt" key on your keyboard once while in the folder and it should appear.
2) go to to Tools menu, and select "Folder Options..." from the dropdown list.
3) Click on the "View" tab, usually the second item to the right of "General".
4) In the "Advanced Settings" list, scroll down to and uncheck [ ] Hide extensions for known file types.
5) Click [Apply], click [OK]
Now the file browser will always show file extensions and there will be less confusion:
.spin2, .binary, .lst, .p2asm
Thanks
@whicker
Thanks for the tip on windows. Always ready for new stuff on windows.
Back to my original question above.
As opposed to P1 pasm why do I have to point back to ptra?? at the end
Hope I sent the correct file. Found the spin2 file.
Martin
Your Spin2 program waits until the value of "data" is zero.
In the P2asm you are writing "0" to the location specified by ptra. You want that to be "data" so you need to set ptra to its original ("data" location) value.
On entering the P2asm you could have saved ptra in another variable and that way once the calculation was done just recalled the saved value to ptra. But I have usually seen it done the way you did.
Tom
The Spin code waits for the COG to be finished. Your code does this by waiting for the original variable "data" to be set to 0: So after we have written "answer" in the PASM code we back up to the original pointer value where it pointed at "data" by subtracting 8, and then write a 0 there.
This probably isn't the best approach, since it means we cannot use a value of 0 for the original data. Better would be to have a separate "finished" variable which indicates that the PASM is done.
All this is exactly the same between P1 and P2. Some P1 programs don't bother with synchronization (waiting for the PASM to finish) because PASM is very fast and Spin bytecode is very slow, so they just assume that the PASM code is finished with answer by the time the Spin gets to it. But that assumption will fail for complicated computations or if you use a faster Spin compiler, so they really should do this.
Thanks
Martin
I cannot save anything.
I can say with 100% certainty that showing all file extensions did not cause or trigger the problem you're seeing.
Did you move the folder that had those files in it somewhere else?
Because spin2gui no longer locks the file while it is open, you can move that file or even delete it.
Or you can even move the folder somewhere else, and again because it's not locked, windows won't complain that it is in use.
So then if you hit for example compile, you see that message.
Edit:
Oh! You can also run into issues having two or more instances of Spin 2 GUI open on the same file.
Then move or delete or rename the file that is open or the folder that it's in, then try to do things from the Spin 2 GUI menu like Save As.
I don't really think this is a bug per se, just user error.
FullDuplexSerial is only for P1, not for P2. I will add a note to that effect in the docs, although I don't think any of the samples there were complete. There are complete examples that work on both P1 and P2 in the samples/ directory of the spin2gui release.