Il giorno ven 13 set 2019 alle ore 16:00 Couret Charles-Antoine <charles-antoine.couret@xxxxxxxxxxxxx> ha scritto: > > For patch 3, I didn't use delay_usecs fiels due to the timings > definition in the datasheet in "READ/WRITE SPANNING CONVERSION WITHOUT A > BUSY INDICATOR" mode. During the delay, the chip select line must be > released which is not the case when we use delay_usecs field. So I add > the delay instruction after the write step to be compliant with these > timings. Ok, you are right, thank you for pointing this out.. It looks like that, for my original intent of being strict about acquisition time and conversion time (as per my original interpretation), both delays (before and after) CS change would be needed.. But since Alexandru pointed out that the single 2uS delay, as per current implementation, should be OK for the A/D chip, then I'd drop patch 3/4. > For patch 4, I explained a bit in the other thread. Maybe we have a > difference of behaviour due to the choice of the timings "modes"? I don't know.. is it "RAC" the intended working mode? If you want I can take some snapshot of scope images and share them.. > > BTW, from my point of view the datasheet is not totally clear about the > timings and what is mandatory or not in the expected behaviour. I agree with you that datasheet is not so clear about timings.. However I think it makes it pretty clear that we need the extra transfer in order to make sure that the read data is correct (except if the CFG doesn't change). IMO that's could be evinced by both diagrams (all modes I think) and by the following sentence in "READING/WRITING AFTER CONVERSION, ANY SPEED HOSTS" paragraph: "When reading/writing after conversion, or during acquisition(n), conversion results are for the previous (n − 1) conversion, and writing is for the (n + 1) acquisition". I interpret this as follows: - You write a new CFG in cycle n, you get (and discard) data for cycle n-1, and the new CFG will be used for next _acquisition_. - Once you release the CS (you finished to write) the conversion for the _currently_ acquired data (old cfg) starts. Once the A/D finishes the conversion, the acquisition starts with the new CFG - You read data, and the A/D returns results from the last _conversion_ that has been done, which is still related to the old configuration. Once you release the CS (finish to read) the conversion for the currently acquired data - which is now the one with the new CFG - is started. - Finally you read the result of the above conversion So IMO we really need three cycles to read from a random channel > Regards, > > Charles-Antoine Couret >
