Assembly question (SPI Engine example) Why does this work?
Stephen Moraco
Posts: 303
I've a couple of questions·regarding the following code exerpt from SPI Engine v1.1:
PUB·SHIFTIN(Dpin,·Cpin,·Mode,·Bits)|Value·
····if·Flag·==·0·······································
·······start·········································
····setcommand(_SHIFTIN,·@Dpin)
····result·:=·Value
There are (at least ;-) two things that seem to be happening.
Can anyone tell me what's really happening?
(1) it appears that the proximity of Value to the preceeding ... Mode, Bits) is what
···· is allowing it to receive the return value from the Cog running assembly
···· [noparse][[/noparse] or, more technically speaking,·it is where all of these are placed on the call stack]
···· Is this correct?· I've not seen any mention of this yet...
(2) There is nothing that appears to be causing the Cog running this code to wait
···· for the result to appear from the Cog running the assembly SPI Engine.· There
···· is code within setcommand() which waits for the command to be overwritten
··· as a means to know that the Cog is acting on the command but I see no
··· further synchronization mechanism.· Is just the relative timing of things
··· that is causing the result := Value to always have the correct received value?
··· (or is there more to this?)
The reason for my asking is that I need to upgrade the SPI engine and I figured
I had better understand these issues before things go sideways for me....·
(I'm measuring about a 9k-Bytes/Sec throughput and I need significantly higher
·which means that I need the back-end to act on whole command sequences
·not single bytes.· I think I've a handle on how to do this and I'll post the
·results when it's working...)
All help and comments appreciated!
·· Oh, Huge KUDOs to deSilva for your intermediate level tutorial!!!!· I''m pouring
···over it for my 2nd or third time now...· great job!· And of course i'm anxiously
·· awaiting your next writings!·· Like you are not already busy... [noparse]:)[/noparse]
Regards,
Stephen, KZ0Q
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·
PUB·SHIFTIN(Dpin,·Cpin,·Mode,·Bits)|Value·
····if·Flag·==·0·······································
·······start·········································
····setcommand(_SHIFTIN,·@Dpin)
····result·:=·Value
There are (at least ;-) two things that seem to be happening.
Can anyone tell me what's really happening?
(1) it appears that the proximity of Value to the preceeding ... Mode, Bits) is what
···· is allowing it to receive the return value from the Cog running assembly
···· [noparse][[/noparse] or, more technically speaking,·it is where all of these are placed on the call stack]
···· Is this correct?· I've not seen any mention of this yet...
(2) There is nothing that appears to be causing the Cog running this code to wait
···· for the result to appear from the Cog running the assembly SPI Engine.· There
···· is code within setcommand() which waits for the command to be overwritten
··· as a means to know that the Cog is acting on the command but I see no
··· further synchronization mechanism.· Is just the relative timing of things
··· that is causing the result := Value to always have the correct received value?
··· (or is there more to this?)
The reason for my asking is that I need to upgrade the SPI engine and I figured
I had better understand these issues before things go sideways for me....·
(I'm measuring about a 9k-Bytes/Sec throughput and I need significantly higher
·which means that I need the back-end to act on whole command sequences
·not single bytes.· I think I've a handle on how to do this and I'll post the
·results when it's working...)
All help and comments appreciated!
·· Oh, Huge KUDOs to deSilva for your intermediate level tutorial!!!!· I''m pouring
···over it for my 2nd or third time now...· great job!· And of course i'm anxiously
·· awaiting your next writings!·· Like you are not already busy... [noparse]:)[/noparse]
Regards,
Stephen, KZ0Q
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·
Comments
You are correct ... the reference to @Dpin tells the Assembly program the start location of the variables that you want to pass.
The preceding variables... Cpin, Mode, Bits, Value, etc... don't care about the parenthesis, commas, or pipes. The only thing
the Assembly knows is that they are each separated by 4 bytes (1 long) and how many of them there are.
As far as the second question is concerned... the 'setcommand' waits for the Assembly program to receive the command, but because
of the substantial differences in speed between Spin and Assembly, having the Spin program wait for the result would be a waste of code.
In other words for these relatively short Assembly functions, the data will be there long before Spin even knows what happened.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.