7 Replies Latest reply on Jul 13, 2016 2:52 AM by user_1377889

    The injector channel of ADC_SAR_Seq

    cjoachim_1597296

      The ADC_SAR_Seq component has an Injector Channel. The datasheet tells that it can be used as a firmware controlled channel, separate from the main channels, to use at a lower sample rate. But what are the benefits of using this channel? If I am going to make samples at a high rate anyway, I suppose I could get this signal for free as a main channel. Or do I get any power saving gains by using the Injector Channel?

        • 1. Re: The injector channel of ADC_SAR_Seq
          user_1377889

          In "General Description" of the datasheet is a hint what the injection channel is ment for:

             

          An optional “Injection channel” may also be enabled by firmware to occasionally scan a signal that does not need to be scanned at the same rate as other channels.

             

           

             

          Bob

          • 2. Re: The injector channel of ADC_SAR_Seq
            cjoachim_1597296

            Yes, exactly. But if I am sampling the main channels at a high rate, why not just connect the low-rate sampling to a main channel, and read it when I need a sample?

               

            This is my actual use case: I sample ADC in a main channel @1000 Hz. ADC_SAR_Seq sample triggering is done by a clock connected to soc. The eoc signal is connected to DMA (that copiew ADC_SAR_Seq_SAR_CHAN0_RESULT_PTR into a RAM buffer). See attached picture. But as you can see (understand), I also have the DieTemp component connected to the ADC (in addition to other low-rate sample signals). This temperature is not something that needs to be done frequently. So why use the Injection Channel for this, when I can read the result from main channel 3 (ADC_SAR_Seq_GetResult16( 3 ))?

               

            PS. Since I have a sample rate of 1000 Hz, could I benefit, in terms of power saving, of using External Clock Source? The Internal Clock Source gives a very high sample rate, see attached picture. Low power is very important in my application!

               

            PPS. You can see in the attached design that I use a FreqDivider to be able to connect a clock to soc. It looks a bit unecessary to configure the clock to 2000 Hz, and then divide it down to 1000 Hz. How could this be done better (do you remember this topic, Bob: http://www.cypress.com/forum/psoc-4-ble/cannot-connect-clock-directly-adcsarseqsoc ?)?

            • 3. Re: The injector channel of ADC_SAR_Seq
              user_1377889

              Since I have a sample rate of 1000 Hz, could I benefit, in terms of power saving, of using External Clock Source? The minimum clock is a limiting factor and is independent of internal/external selection. Has probably to do with internal S&H.

                 

              When it comes to power saving, it could be good to do conversion in a short time and go to sleep again earlier. This includes the use of the injection channel: not converting that value saves energy, thus convert only when needed.

                 

              For frequency dividing a PWM component can be quite useful (if you have a spare block of TCPWM or UDB)

                 

               

                 

              Bob

              • 4. Re: The injector channel of ADC_SAR_Seq
                cjoachim_1597296

                OK, so ADC_SAR_Seq_GetResult16( /* injector channel index */ ) (assuming ADC_SAR_Seq has been started) will do a read, even though the clock connected to soc is not running (is that the purpose of the injector channel?)?

                   

                I don't understand Clock source. I suppose this is the clock driving the sample engine. But as you can see, Actual sample rate per channel is 15625 SPS, and this is the smallest number possible. Isn't this an overkill? That may drain more battery? I've observed a lower SPS in a example project, I think, but I can't make my SPS smaller.

                   

                And it is still possible to use ADC_SAR_Seq_GetResult16() on another channel than the one @1000 Hz and get correct result? I've always been thinking that an input to soc will sample all my channels, and then trigger eoc when all samples complete.

                   

                 

                   

                (I do software programming, not hardware, so ADC was something I had delegated to our HW guy :) )

                • 5. Re: The injector channel of ADC_SAR_Seq
                  user_1377889

                  I've always been thinking that an input to soc will sample all my channels, and then trigger eoc when all samples complete. That is absolutely correct.

                     

                  Clock source. I suppose this is the clock driving the sample engine. correct too.

                     

                  Actual sample rate per channel is 15625 SPS, and this is the smallest number possible. Isn't this an overkill? That may drain more battery?   for a continuing sampling when not so many samples/s are needed you are right. But you may use the SOC input to perform a complete all-channel scan. When set to Hardware Trigger a high sampling rate will finish the conversion in less time.

                     

                  ADC_SAR_Seq_GetResult16( /* injector channel index */ ) (assuming ADC_SAR_Seq has been started) will do a read, even though the clock connected to soc is not running (is that the purpose of the injector channel?)? I do not know what you mean with that question.

                     

                  See in API section that you can enable and disable conversion of given channels, including the injection channel.

                     

                  I do software programming, not hardware Welcome in my world.

                     

                   

                     

                  Bob

                  • 6. Re: The injector channel of ADC_SAR_Seq
                    cjoachim_1597296

                    Thank you! The datasheet is difficult to understand, for me.

                       

                     

                       

                    I do not know what you mean with that question. I know what I mean: Can I do a read of the Injector channel (ADC_SAR_Seq_GetResult16()) when hardware triggering (soc) is not running? Otherwise, I see no difference between the Injector channel and the main channels.

                       

                     

                       

                    PS: The documentation says that the injector channel "is the number of valid channels". Which number is that (The number of my main channels? The the total number of possible main channels? Or?)

                    • 7. Re: The injector channel of ADC_SAR_Seq
                      user_1377889

                      The documentation says that the injector channel "is the number of valid channels". Which number is that (The number of my main channels? Its the number of "Sequenced Channels" as in attached picture.

                         

                      I know what I mean: That's a good basis!  ;-)

                         

                      Can I do a read of the Injector channel when hardware triggering (soc) is not running? You may, but you should check for an ADC_IsEndConversion().

                         

                      You did not tell yet in which mode you are working, free running or soc triggered

                         

                      Free running: There is at any time (after the first scan is finished!!!) a valid result for all enabled channels, because the values are buffered. No need after setup to scan for ADC_IsEndConversion() or using eoc interrupt.

                         

                      Hardware trigger: Need to wait for conversion cycle ended, either eoc interrupt or by ADC_IsEndConversion()

                         

                      For the ADC cracks: using an analog multipexer in front of a one-channel ADC. Switching the multiplexer to the next channel when the eos signal comes up. (eos = end of sampling. The s&h part is satisfied)

                         

                      The datasheet is difficult to understand, for me. I was working 20 years for a distributor and I spent most of my time to explain the English datasheets to German developers...

                         

                       

                         

                      Bob