Page 1 of 1

NSDL "wait" and PDL iApply

Posted: Tue Jun 16, 2015 7:45 pm
by Michele
Referring to June 8 minutes:

I would just like to add another analogy, as probably the usage of "wait" in NSDL is not as familiar to everyone as it is to Brad and myself!

1687 PDL does something similar : multiple iRead and iWrite commands can be called in a PDL snippet, but they will not have effect until an iApply takes place. The iWrite is especially a good example! multiple iWrite calls to the same TDR register will be queued, and only the last one will take effect during iApply. So, a PDL player would need to keep an internal state of all TDRs, modify their value following the succession of iWrites and synchronise the hardware TDR with the last value when the iApply is executed.
Similarly, only the first iRead will actually provoke a scan operation, while all successive calls will refer to the same value, store inside the internal model. But in some ways I find this behaviour not coherent, as I posted in the forum earlier...

Re: NSDL "wait" and PDL iApply

Posted: Tue Jun 16, 2015 7:46 pm
by Michele
Adam made me note an error in my example: iRead is used only to compare expected data, the command I was looking for is iGetReadData, which indeed looks at the last value received from a scan operation.

Re: NSDL "wait" and PDL iApply

Posted: Tue Jun 16, 2015 7:47 pm
by Adam W Ley
Though I don’t take issue with Michele’s phrasing, I think the following amendment a bit easier to read and understand:
iGetReadData looks at the value received from the last scan operation, if any*, that accessed the target TDR
(* note – since iGetReadData doesn’t infer a scan operation, it is possible that it is called at a point before any scan operation has accessed the target TDR – in that event, the iGetReadData would return “undefined”)
Comments and questions invited!