Sampling a 16-channel SAR with an 8-channel programmable SoC
Editor’s Note: Here is how Bob Hu, a Cypress staff application engineer, worked with a customer who wanted to build a 1 Mbps 16-channel successive approximation register-based ADC, but do it with a Cypress PSoC 4, which has a built-in SAR multiplexer but only supports eight channels.
Sampling signals by ADC is a common task for MCU-based applications that requires the conversion of a continuous analog signal into a series of discrete digital data for MCU processing. In some applications, a single ADC needs to sample multiple channels with a high sample rate. For example, a power monitoring system management subsystem needs to sample the output of regulators to monitor the system working status. In sensor-based applications, the MCU needs to sample multiple sensors to implement system feedback.
One of our customers wanted to sample 16 channels with a 1 MSps SAR using a Cypress PSoC 4. This would result in a total duration of less than 19 us for 16 channels sampling. However, the PSoC4 built-in SARMUX only supports 8 channels. This article describes how we met this design challenge.
Analyzing the design requirements
First, we needed to analyze the design requirements carefully. The customer considered a full sampling of 16 inputs as a sampling cycle. As Figure 1 shows, the maximum duration of a sampling cycle is limited to 19us. There can be a break among cycles to store SAR results using an interrupt service request (ISR).
To achieve this using an 8-channel SAR, we needed to build a customized design based on universal data blocks (UDBs) that are part of the PSoC4 architecture. The idea was to switch channels with a digital signal interconnect (DSI)-based mux, temporarily buffer sampling results in datapath-based FIFOs, and then read them all via an interrupt service routine (ISR).
Datapath is the most valuable portion of a UDB block. Each UDB block contains one datapath and each datapath contains an 8-bit ALU with several registers. The details of UDB structure and datapath functions can be found in the PSoC 4 technical reference manual. Each datapath can be constructed as an 8-byte FIFO. We needed four FIFOs to buffer sixteen 12-bit SAR results.
Figure 2 shows a DSI-based switch that can automatically change the current sampled channel among multiple inputs, while Figure 3 shows an overview of the hardware FIFOs buffering the sampling results.
Configuring the SAR
The SAR is configured as single-channel input, single-end mode, 0~Vdd range, and 1 MSps sample rate. It receives a trigger signal to start the channel conversion and an “SDONE” signal is routed to the DSI named “ADC_SDONE”. The current SAR component available in the Creator Library does not support output sampling result on the DSI bus. Thus, we needed to import the SAR component into the project and modify it as marked out in red in Figure 4.
Figure 4: Design Detail - SAR Component
Figure 5 shows the SAR output connection. We also needed to add one line of code after the SAR_Start function to enable sampling the resulting output shown below:
// start SAR component and wait for conversion trigger
// enable SAR sampling result output on DSI
*((reg32 *)(SAR_SAR_CHAN_CONFIG_IND + (uint32)(0 << 2))) |= SAR_DSI_OUT_EN;
Figure 5: Design Detail – SAR Connection
As shown in blue in Figure 5, the hardware mux controlled by the Digital Signal Interconnect (DSI) replaces the SARMUX to switch 16 channels. A count7 unit is triggered by the SWITCH_CLK clock to generate the channel select signal, as each channel conversion can be divided into two stages – signal acquisition and converting.
Once the signal acquisition completes, the signal is held in the SAR and the input channel can be switched. Therefore, the SDONE, which indicates signal acquisition stage completion, can be used for channel switching. Actually, SWITCH_CLK is a defined clock based on the DSI signal “ADC_SDONE” (SDONE), which is set in the Creator Design Wide Resource page shown in Figure 6.
The Count7 unit is a customized component that is not in the standard Creator Library. It works as a down-counter and output current counter value to the DSI. Its default value is 0x7F; thus, channel selection is from #15 to #0. Code is added to the main routine to enable it.
/* Enter critical section */
interruptState = CyEnterCriticalSection();
/* Set the Count Start bit */
MYCOUNT7_AUX_CTL |= (1 << 5);
/* Exit critical section */
// set default value of count7 as 0x7F
MYCOUNT7_COUNTER = MYCOUNT7_PERIOD;
SAR trigger Step #1: generate next trigger before current sampling done
As there is only one actual input for the SAR, once the current channel sampling is done, the SAR needs a trigger for the next sample. Many signals are suitable; however, the trigger selection should follow two rules:
- There should be no interval between the trigger and current sampling completion, or the trigger could even happen early. This could reduce latency.
- Triggers must ensure they do not corrupt the current sample.
Based on these rules, SDONE and EOC can be candidates for triggering. However, using EOC requires ~1.4 us for one channel sampling. This is caused by overhead between the trigger rising and the SAR starting sampling. The SAR needs at least 5 SARADC_CLK clocks to convert a DSI trigger to a signal acquisition start.
Our case is even worse. The EOC signal is synced with the SARADC_CLK rising edge. After going through the DSI network and reaching the SOC (start of conversion) of the SAR, it is a little behind the rising edge of sampling clock. Therefore, it needs 6 SARADC_CLK clocks, or ~340 ns overload.
We had to seek another trigger signal. Fortunately, when the SAR is busy, the SAR can store one trigger, but only one, for the next scan. Therefore, we can use SDONE to trigger conversions. The overload is parallel with the SAR conversion time and the SAR can store the trigger event before the current conversion is done. Now we can have a 1 us conversion time for 16 channel sampling (see period of SDONE in Figure 12).