It would seem that if I let PSELx stay at its existing value at the end of a transaction, rather than unconditionally setting it to 0, it would reduce power consumption, since PSELx wouldn't have to change when the next transaction selects the same PSELx.This is certainly an advantage.
Nevertheless, why does the APB spec. require PSELx to be set to 0 at the end of a transaction?
This would instead probably increase power consumption because PSELx high and PENABLE low tells the selected peripheral that this is the "setup" phase of a transfer and that it should sample the PADDR, PWRITE and other control signals so that it knows what data transfer to perform in the next cycle (when PENABLE should then be high).
If there is no transfer required, PSELx must be driven low, and then the peripherals on the bus don't need to do anything (no registering of control inputs).
You can keep PSELx high if you are performing back-to-back transfers on the bus, but otherwise the protocol uses PSELx low as indicating no activity.
Okay. So you're saying that peripherals are constantly sampling PADDR and PWRITE from the SETUP phase in order to accept them when PENABLE goes High?
Is the method of continuously sampling PADDR and PWRITE from the SETUP phase used by all peripherals? Or is this only for high performance devices that can give PREADY in 1 cycle?
I'm not sure what you are thinking by "constantly" and "continuously", but when an APB access starts with PSELx high and PENABLE low, this is when the peripheral will look at PADDR, PWRITE and so on to work out what location will be accessed in the next cycle when PENABLE will be high.
So the selected peripheral will sample the request ONCE in the "setup" phase of the access (your use of "constantly" and "continuously" implies the sampling happens multiple times for one access, which is not the case).
For a series of APB accesses the selected peripheral will sample the "setup" phase" request once in each access. It needs to do this so it knows what each request wants.
And finally, it doesn't matter whether a peripheral needs to add wait states or not, the selected peripheral needs to sample PADDR and PWRITE in the "setup" phase of the transfer. It's how the protocol works, so will presumably be how all peripherals implement their APB interface.
Thank you for your response !!
It really helps me to learn the APB protocol.
But I have a question about Sampling.You said that sampling is done in the SETUP phase.Is the sampling done in the middle of the PCLK, not at the PCLK edge?If only PSELx has the correct value in the middle of the SETUP phase, but PADDR is still being set to the correct value and has an incorrect value, if Peripheral is sampling at this time, Peripheral may sample the incorrect value and cause problems.When does Peripheral sample PSELx and PADDR in the SETUP phase?
The APB protocol is designed to be used in a synchronous design, so all sampling will be done on PCLK rising edges. At that time both PSELx and PADDR will be valid.
I should add that you can use the APB protocol with combinatorial logic, using PSELx & ! PENABLE to open a latch to sample PADDR during the "setup" phase (so PADDR would be valid as the latch closes), and the PSELx & PENABLE to then enable data latching or driving during the "access" phase.
However virtually all designs nowadays use synchronous logic, so it would be the registering signals on PCLK rising edges that would be the standard solution.
Ah, that explains it, I see now.Thank you for your response !!