6 Replies Latest reply on Jan 12, 2017 6:15 AM by user_342122993

    ADC_SAR: eoc signal to faint?

    thomas.baehler

      Im tinkering with a PSoC 4  M-Series Prototyping Kit. I want to use a ADC_SAR for one channel with hardware triggering (see picture).

         

      To trigger an off-board component with a 10-microsecond-pulse I want to use the eoc (end of conversion) output of the ADC_SAR. I connected the eoc-signal to a puls-converter, but there is no signal coming out of it. So I connected the eoc-signal to a pin and watched it on a oszilloscope. The puls is there but it has only a width of 20 to 50 ns. I tried to connect it to other digital components in the PSoC but with no (consistent) luck. So I'm wondering how I could use the eoc.

         

      Thanks
      Thomas

        • 1. Re: ADC_SAR: eoc signal to faint?
          user_342122993
                  Thomas, the eos terminal will produce short pulse, typically corresponding to BUS_CLOCK. Many components require longer pulse for triggering, thus PulseConverter component comes handy. Consider using SDONE output instead of EOS because of timing delay which eos have. This time delay is variable and depends on ADC_SAR settings. In your case, PulseConverter component has input clock 12MHz, which is lower than pulse frequency (BUS_CLOCK), so input pulse is simply missed (see timing requirements of component), I believe that pulse length should be longer than 2 clock periods. Consider using 1-shot timer instead of PulseConverter for more deterministic timing. Lastly, external clock for ADC_SAR probably not required. Internal clock may suffice.   
          • 2. Re: ADC_SAR: eoc signal to faint?
            user_1377889

            Carefully with the sdone output: The conversion is not complete when this signal comes! Only the sampling time is over at that point. Normally it is used to switch a multiplexor to the next channel allowing for the signal to settle as early as possible.

               

             

               

            Bob

            • 3. Re: ADC_SAR: eoc signal to faint?
              thomas.baehler

              Thanks for the tips.

                 

              I increased the sample-clock at the Pulse Converter (with an additional clock) to 24MHz and now it works :-)
              There is of course a jitter within 10 microseconds of the pulse-start coming out of the Pulse Converter, but I don't mind.

                 

              The sdone-signal wouldn't work because my ADC_SAR measures four times and saves the average. That would result in four pulses out of sdone, and three of them came to early.

                 

              I do worry a bit that I miss some eoc-pulses because, as odissey1 writes, with 24MHz I'm a the limit of detecting a pulse width of less than 50 ns. I could do the pulse-width conversion outside of the PSoC, but isn't there a way to make the pulse longer inside the chip?

                 

              Thomas

              • 4. Re: ADC_SAR: eoc signal to faint?
                user_342122993

                Attached example of the project using 1-shot timer to shape 10us signals.

                   

                 

                   

                • 5. Re: ADC_SAR: eoc signal to faint?
                  thomas.baehler

                  Great, that OneShot_02 works perfect! Thanks a lot!

                     


                  Though I get a warning I dont understand:
                  Warning-1366: Setup time violation found in a path from clock ( CyHFCLK ) to clock ( CyHFCLK ).
                  The Timing Analysis Report shows a violation because the maximum frequency of the CYHFCLK is 38.473 MHz (see picture).

                     

                  Thomas

                     

                   

                     

                   

                     

                  • 6. Re: ADC_SAR: eoc signal to faint?
                    user_342122993
                            Warning suggests that current design is not optimal and has max clock limitation 38MJz due to pulse front skew. Notice that HFCLK was set at 24MHz. I will look into it (try to remove SR latch). This gives general idea. Try to do same using fixed function TCPWM to save resources.