Part Number: ADS8588SEVM-PDK
Hello,
We have an application in which we need to use multiple EVMs with our digital controller instead of the PHI controller. We would like to be able to evaluate all of the features e.g. it is possible that we run one ADC in parallel mode and the other one in parallel byte mode. However, we do not need to change the mode of operation, oversampling etc. on the fly. We can change jumpers and rerun.
With that in mind, I have a few questions:
- Since we would not be using the PHI controller, should we just leave pins 56, 58, and 59 unconnected at the 60-pin Samtec connector?
- What is the purpose of pin #34 on the EVM Samtec connector?
- What is the purpose of pin #15 on the EVM Samtec connector?
- Let the board that ties the multiple EVMs together, and these EVMs to our digital controller, be called the bridge board. We intend to supply the power to the LDO for the analog, and the DVDD power to all the EVMs from this board, in the PHI controller's stead. We don't want to wire the power on the J10 and J11 terminal blocks (to minimize wiring).
- The DVDD is clear (pin #50 on the Samtec). Is it sufficient to supply a regulated 3.3V on this pin?
- Is the 5.5V meant to be connected to pin #1 of the Samtec? What is the purpose of the RAW_5V on pins 2 and 4? What is the acceptable range of the 5.5V power?
- Is there any harm in tying CONVST_A and CONVST_B of the same EVM together on the bridge board? This is how we intend to use these pins in the final application too.
- Is FRSTDATA purely a monitoring output from ADC/EVM? Can this be left unrouted?
- In an earlier post on this forum, I had alluded to minimizing the number of digital I/Os. Indeed, we do not need to change modes of operation in our final application. However, I just want to confirm that we can evaluate all of the modes by leaving the following unrouted (no connection between the EVM and our controller), and just by using the jumpers on the EVM:
- REFSEL
- RANGE
- STANDBY
- OS0, 1, 2 (oversampling)
- PAR/SER (parallel/serial/parallel byte modes)
Thank you.
Regards,
Saurabh