As per what we discussed previously Harley, there are two ways of communicating data from Spin to Assembly. Either passing a pointer and using rd(long/word/byte), or assigning the constant in the code before loading it into a cog. If your values are run time constants, use the second method. If your values are variable, or you require sending data from the cog to Spin or other assembly cogs, use the first method. The second method is faster for the assembly cog, but limited in it's capabilities. The second is more versatile, but slower (since it requires accessing the hub memory). Either way you only have the variable declared once, in the Spin VAR section for the first method or after your assembly code in the DAT section for the second method.
I possibly didn't appreciate previous remarks; too 'newbie' to the details to catch the point before bumping my head on those details. Now will read over the comments; hopefully things will 'click'.
This Propeller has been an interesting journey. I hadn't planned to get THIS DEEP into it,. But then I saw some of the things it could do and OH MY!!, was pleasantly pleased what the Prop can do.
Thanks for all the 'hand-holding', answering (maybe dumb) questions and the general pleasant help that everyone on this forum has provided. I've not followed a lot of forums, but this is one of best, in my opinion. Some are too full of bickering. Thanks Parallax for providing such a useful and pleasant forum for the Propeller.
The variable passing side of the propeller is something I have struggled with, a concise description in laymen's terms would make an excellent piece of documentation.
Maybe if I can plow through this and get something working, I can start something general to contribute, though w/enough details that. someone who really knows the Propeller can finish the frosting on itand make it useful to others. (But, no one hold your breath, please, for this to see the light of day.)
I must not understand the WAITPEQ/WAITPNE instructions for assembly.·
The input signal on A6 is a repeating signal that is low for 8 microsec and high for 50 microsec.· I would think the code below would finish its test of pin A6 in about·8 microsec.· Instead, it outputs a high state on the tri-stated pins for about 140 microsec!!!· Probably for 3 periods, minus the 8 microseconds which would be 142 microsec.· Scope measurements on a 100 MHz scope; 150 MHz probe; a 2247A Tektronix.
If I comment out the WAITPNE then the output is high for a very very short time, like a glitch.
DAT
''****************************************
'' DT bus controller
''***************************************
org 0
DTbusRd shl statFOO,#16 ' position for first transfer
mov OUTA, statFOO ' move byte to output register
waitpeq zero, IOmask ' wait for BIORQn low level
mov DIRA, DTbusmask ' make pins outputs
' something else goes in here
waitpne zero,IOmask ' wait for BIORQn hi level
mov OUTA, statFOO ' move byte to output register
mov DIRA,zero ' make pins inputs again
:id LONG $0000_0000
cogid :id
cogstop :id
' fit
statFOO long 0
zero long 0 ' zero value
IOmask long $0000_0020 ' mask for only BIORQn pin (A6)
DTbusmask LONG $00FF_0000
''****************************************
This code is invoked in the top Spin object once for each keypress from another board.· So it's repetition rate makes it difficult to see the PW of the 'glitch'.
Can anyone clarify why this is acting this way?__·
The I/O pins are labelled from A0 to A31 and the bit mask (IOmask) is actually for A5. If you're using A6, the mask should be $0000_0040. It may be clearer to define IOmask as "IOmask long |<6".
Also, you can't move the ":id" variable into the middle of the instructions. As a zero initially, I think it functions as a NOP, but it's bad form.
Post Edited (Mike Green) : 10/26/2006 10:45:01 PM GMT
Thanks Graham and Mike for the 'knock on the head' for forgetting my counting. I guess I get kicked back a grade or two!? A D- on my assembly coding test?
Yes, when I first got the PropSTICK, when I read 'pins' I thought they meant 40-pin DIP pins. So the TV Demo didn't display. I wish the manual didn't refer to 'pins' when dealing with A0..31. Confusing!
I changed that mask and it now works as expected. I'm not sure why it even passed the WAITPEQ test. Unless, as an input was floating and A5 capacitatively coupled some edge to trigger.
I like the suggestion of "IOmask long |<6"; yes, clearer. And, I also moved the ':id' variable. I moved so much around trying to get every thing going. Don't know why the COGSTOP worked.
Learning something new each and every day, now with the Propeller. I'm still amazed what all it can provide. If we had the A/B port version, I could do the whole task with one Prop; got close to 40 signals to i/f. (I like this little guy, Yeah!) Guess it is time to temporarily use another cog to simulate better timing, now with this portion of assembly code going good.
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
I possibly didn't appreciate previous remarks; too 'newbie' to the details to catch the point before bumping my head on those details. Now will read over the comments; hopefully things will 'click'.
This Propeller has been an interesting journey. I hadn't planned to get THIS DEEP into it,. But then I saw some of the things it could do and OH MY!!, was pleasantly pleased what the Prop can do.
Thanks for all the 'hand-holding', answering (maybe dumb) questions and the general pleasant help that everyone on this forum has provided. I've not followed a lot of forums, but this is one of best, in my opinion. Some are too full of bickering. Thanks Parallax for providing such a useful and pleasant forum for the Propeller.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
h.a.s. designn
Graham
I agree with your comment, Graham.
Maybe if I can plow through this and get something working, I can start something general to contribute, though w/enough details that. someone who really knows the Propeller can finish the frosting on itand make it useful to others. (But, no one hold your breath, please, for this to see the light of day.)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
h.a.s. designn
The input signal on A6 is a repeating signal that is low for 8 microsec and high for 50 microsec.· I would think the code below would finish its test of pin A6 in about·8 microsec.· Instead, it outputs a high state on the tri-stated pins for about 140 microsec!!!· Probably for 3 periods, minus the 8 microseconds which would be 142 microsec.· Scope measurements on a 100 MHz scope; 150 MHz probe; a 2247A Tektronix.
If I comment out the WAITPNE then the output is high for a very very short time, like a glitch.
DAT ''**************************************** '' DT bus controller ''*************************************** org 0 DTbusRd shl statFOO,#16 ' position for first transfer mov OUTA, statFOO ' move byte to output register waitpeq zero, IOmask ' wait for BIORQn low level mov DIRA, DTbusmask ' make pins outputs ' something else goes in here waitpne zero,IOmask ' wait for BIORQn hi level mov OUTA, statFOO ' move byte to output register mov DIRA,zero ' make pins inputs again :id LONG $0000_0000 cogid :id cogstop :id ' fit statFOO long 0 zero long 0 ' zero value IOmask long $0000_0020 ' mask for only BIORQn pin (A6) DTbusmask LONG $00FF_0000 ''****************************************This code is invoked in the top Spin object once for each keypress from another board.· So it's repetition rate makes it difficult to see the PW of the 'glitch'.
Can anyone clarify why this is acting this way?__·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
h.a.s. designn
I don't know if that will help.
Don't hesitate to write a test program so that the repetition rate is to your liking.
Graham
Also, you can't move the ":id" variable into the middle of the instructions. As a zero initially, I think it functions as a NOP, but it's bad form.
Post Edited (Mike Green) : 10/26/2006 10:45:01 PM GMT
Yes, when I first got the PropSTICK, when I read 'pins' I thought they meant 40-pin DIP pins. So the TV Demo didn't display. I wish the manual didn't refer to 'pins' when dealing with A0..31. Confusing!
I changed that mask and it now works as expected. I'm not sure why it even passed the WAITPEQ test. Unless, as an input was floating and A5 capacitatively coupled some edge to trigger.
I like the suggestion of "IOmask long |<6"; yes, clearer. And, I also moved the ':id' variable. I moved so much around trying to get every thing going. Don't know why the COGSTOP worked.
Learning something new each and every day, now with the Propeller. I'm still amazed what all it can provide. If we had the A/B port version, I could do the whole task with one Prop; got close to 40 signals to i/f.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
h.a.s. designn