Read non conventional ADC with STM32F3












1















I'm attempting to interface an STM32F303 Nucleo with an AD7748-4 ADC. Datasheet for the ADC:



https://www.analog.com/media/en/technical-documentation/data-sheets/ad7768-7768-4.pdf



The issue is, the ADC DOES NOT output the converted value through the SPI port, but rather employs a Data Ready Signal (DRDY), a Data Clock (DCLK), and a combination of 4 Data Outputs (DOUT0-DOUT3). The output streams 96 bits serially through one wire if I set it up that way, but timing is critical in my application and I need to clock the data in using DOUT0 to DOUT2, which would each output 32 bits. If I were serially streaming the data, I could trick the SPI port into reading it, but I'm not. The ADC is running at 20MHz, so DCLK will be operating at the same frequency. The Nucleo runs at a maximum of 72MHz, but when the DAM is utilized, it sets the clock to 64MHz.



In the STM manual, it describes a "GPIO port input data register (GPIOx_IDR) (x = A..H)" as being a read only register - my understanding is that the lower 16 bits can store an inputted value up to 16 bits (most likely for memory data R/W) - so the question is, how can I configure the GPIO to read in the data? I'm at a slight impass here. My instinct tells me that the Nucleo may not be fast enough to read the data coming from the ADC... Any ideas? All being written in C/C++ basically bare metal... I'm new to the Nucleo, haven't written code in 4 years - pardon any lapse in knowledge...










share|improve this question





























    1















    I'm attempting to interface an STM32F303 Nucleo with an AD7748-4 ADC. Datasheet for the ADC:



    https://www.analog.com/media/en/technical-documentation/data-sheets/ad7768-7768-4.pdf



    The issue is, the ADC DOES NOT output the converted value through the SPI port, but rather employs a Data Ready Signal (DRDY), a Data Clock (DCLK), and a combination of 4 Data Outputs (DOUT0-DOUT3). The output streams 96 bits serially through one wire if I set it up that way, but timing is critical in my application and I need to clock the data in using DOUT0 to DOUT2, which would each output 32 bits. If I were serially streaming the data, I could trick the SPI port into reading it, but I'm not. The ADC is running at 20MHz, so DCLK will be operating at the same frequency. The Nucleo runs at a maximum of 72MHz, but when the DAM is utilized, it sets the clock to 64MHz.



    In the STM manual, it describes a "GPIO port input data register (GPIOx_IDR) (x = A..H)" as being a read only register - my understanding is that the lower 16 bits can store an inputted value up to 16 bits (most likely for memory data R/W) - so the question is, how can I configure the GPIO to read in the data? I'm at a slight impass here. My instinct tells me that the Nucleo may not be fast enough to read the data coming from the ADC... Any ideas? All being written in C/C++ basically bare metal... I'm new to the Nucleo, haven't written code in 4 years - pardon any lapse in knowledge...










    share|improve this question



























      1












      1








      1








      I'm attempting to interface an STM32F303 Nucleo with an AD7748-4 ADC. Datasheet for the ADC:



      https://www.analog.com/media/en/technical-documentation/data-sheets/ad7768-7768-4.pdf



      The issue is, the ADC DOES NOT output the converted value through the SPI port, but rather employs a Data Ready Signal (DRDY), a Data Clock (DCLK), and a combination of 4 Data Outputs (DOUT0-DOUT3). The output streams 96 bits serially through one wire if I set it up that way, but timing is critical in my application and I need to clock the data in using DOUT0 to DOUT2, which would each output 32 bits. If I were serially streaming the data, I could trick the SPI port into reading it, but I'm not. The ADC is running at 20MHz, so DCLK will be operating at the same frequency. The Nucleo runs at a maximum of 72MHz, but when the DAM is utilized, it sets the clock to 64MHz.



      In the STM manual, it describes a "GPIO port input data register (GPIOx_IDR) (x = A..H)" as being a read only register - my understanding is that the lower 16 bits can store an inputted value up to 16 bits (most likely for memory data R/W) - so the question is, how can I configure the GPIO to read in the data? I'm at a slight impass here. My instinct tells me that the Nucleo may not be fast enough to read the data coming from the ADC... Any ideas? All being written in C/C++ basically bare metal... I'm new to the Nucleo, haven't written code in 4 years - pardon any lapse in knowledge...










      share|improve this question
















      I'm attempting to interface an STM32F303 Nucleo with an AD7748-4 ADC. Datasheet for the ADC:



      https://www.analog.com/media/en/technical-documentation/data-sheets/ad7768-7768-4.pdf



      The issue is, the ADC DOES NOT output the converted value through the SPI port, but rather employs a Data Ready Signal (DRDY), a Data Clock (DCLK), and a combination of 4 Data Outputs (DOUT0-DOUT3). The output streams 96 bits serially through one wire if I set it up that way, but timing is critical in my application and I need to clock the data in using DOUT0 to DOUT2, which would each output 32 bits. If I were serially streaming the data, I could trick the SPI port into reading it, but I'm not. The ADC is running at 20MHz, so DCLK will be operating at the same frequency. The Nucleo runs at a maximum of 72MHz, but when the DAM is utilized, it sets the clock to 64MHz.



      In the STM manual, it describes a "GPIO port input data register (GPIOx_IDR) (x = A..H)" as being a read only register - my understanding is that the lower 16 bits can store an inputted value up to 16 bits (most likely for memory data R/W) - so the question is, how can I configure the GPIO to read in the data? I'm at a slight impass here. My instinct tells me that the Nucleo may not be fast enough to read the data coming from the ADC... Any ideas? All being written in C/C++ basically bare metal... I'm new to the Nucleo, haven't written code in 4 years - pardon any lapse in knowledge...







      c stm32 gpio adc nucleo






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Nov 13 '18 at 13:18







      Jedi Engineer

















      asked Nov 13 '18 at 13:10









      Jedi EngineerJedi Engineer

      1301721




      1301721
























          1 Answer
          1






          active

          oldest

          votes


















          3














          If DCLK works at 20Mhz, the uC is obviously not fast enough (you have about 3 instructions between each cycle, so even assembly language would be difficult to implement...). As I am not familiar with the stm architecture, I can only suggest a trick that will maybe spark some ideas in your head. Rather than using a crystal for the ADC, use a timer from the STM that is connected to an output pin, and clock the ADC using that pin (MCLK). When configuring the ADC using spi, idle mode, etc. you can leave this clock signal at 20Mhz. But when you need a sample from the ADC, stop the STM timer and clock the ADC "manually". (you practically control the DCLK signal). After your conversion routine is over, restart the timer at 20Mhz.






          share|improve this answer
























          • A 20 Mhz clock for 32 bit data would mean you need approx. 600k samples per second. Are you sure you need that kind of data rate ? If so, maybe a microcontroller is not the appropriate solution.

            – luci88filter
            Nov 13 '18 at 15:00











          • Thanks @luci88filter, we have set the clock divider to 4, so it's 20MHz/4/32 = 80kSPS which is what we're shooting for. None the less, we're switching to a faster processor - 216MHz - should give us enough time to clock in and go - a total of 11 cycles at least, so we should be able to shift the data into a register at each clock edge. Hopefully. Thanks!

            – Jedi Engineer
            Nov 13 '18 at 15:21













          Your Answer






          StackExchange.ifUsing("editor", function () {
          StackExchange.using("externalEditor", function () {
          StackExchange.using("snippets", function () {
          StackExchange.snippets.init();
          });
          });
          }, "code-snippets");

          StackExchange.ready(function() {
          var channelOptions = {
          tags: "".split(" "),
          id: "1"
          };
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function() {
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled) {
          StackExchange.using("snippets", function() {
          createEditor();
          });
          }
          else {
          createEditor();
          }
          });

          function createEditor() {
          StackExchange.prepareEditor({
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: true,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: 10,
          bindNavPrevention: true,
          postfix: "",
          imageUploader: {
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          },
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          });


          }
          });














          draft saved

          draft discarded


















          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53281745%2fread-non-conventional-adc-with-stm32f3%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          3














          If DCLK works at 20Mhz, the uC is obviously not fast enough (you have about 3 instructions between each cycle, so even assembly language would be difficult to implement...). As I am not familiar with the stm architecture, I can only suggest a trick that will maybe spark some ideas in your head. Rather than using a crystal for the ADC, use a timer from the STM that is connected to an output pin, and clock the ADC using that pin (MCLK). When configuring the ADC using spi, idle mode, etc. you can leave this clock signal at 20Mhz. But when you need a sample from the ADC, stop the STM timer and clock the ADC "manually". (you practically control the DCLK signal). After your conversion routine is over, restart the timer at 20Mhz.






          share|improve this answer
























          • A 20 Mhz clock for 32 bit data would mean you need approx. 600k samples per second. Are you sure you need that kind of data rate ? If so, maybe a microcontroller is not the appropriate solution.

            – luci88filter
            Nov 13 '18 at 15:00











          • Thanks @luci88filter, we have set the clock divider to 4, so it's 20MHz/4/32 = 80kSPS which is what we're shooting for. None the less, we're switching to a faster processor - 216MHz - should give us enough time to clock in and go - a total of 11 cycles at least, so we should be able to shift the data into a register at each clock edge. Hopefully. Thanks!

            – Jedi Engineer
            Nov 13 '18 at 15:21


















          3














          If DCLK works at 20Mhz, the uC is obviously not fast enough (you have about 3 instructions between each cycle, so even assembly language would be difficult to implement...). As I am not familiar with the stm architecture, I can only suggest a trick that will maybe spark some ideas in your head. Rather than using a crystal for the ADC, use a timer from the STM that is connected to an output pin, and clock the ADC using that pin (MCLK). When configuring the ADC using spi, idle mode, etc. you can leave this clock signal at 20Mhz. But when you need a sample from the ADC, stop the STM timer and clock the ADC "manually". (you practically control the DCLK signal). After your conversion routine is over, restart the timer at 20Mhz.






          share|improve this answer
























          • A 20 Mhz clock for 32 bit data would mean you need approx. 600k samples per second. Are you sure you need that kind of data rate ? If so, maybe a microcontroller is not the appropriate solution.

            – luci88filter
            Nov 13 '18 at 15:00











          • Thanks @luci88filter, we have set the clock divider to 4, so it's 20MHz/4/32 = 80kSPS which is what we're shooting for. None the less, we're switching to a faster processor - 216MHz - should give us enough time to clock in and go - a total of 11 cycles at least, so we should be able to shift the data into a register at each clock edge. Hopefully. Thanks!

            – Jedi Engineer
            Nov 13 '18 at 15:21
















          3












          3








          3







          If DCLK works at 20Mhz, the uC is obviously not fast enough (you have about 3 instructions between each cycle, so even assembly language would be difficult to implement...). As I am not familiar with the stm architecture, I can only suggest a trick that will maybe spark some ideas in your head. Rather than using a crystal for the ADC, use a timer from the STM that is connected to an output pin, and clock the ADC using that pin (MCLK). When configuring the ADC using spi, idle mode, etc. you can leave this clock signal at 20Mhz. But when you need a sample from the ADC, stop the STM timer and clock the ADC "manually". (you practically control the DCLK signal). After your conversion routine is over, restart the timer at 20Mhz.






          share|improve this answer













          If DCLK works at 20Mhz, the uC is obviously not fast enough (you have about 3 instructions between each cycle, so even assembly language would be difficult to implement...). As I am not familiar with the stm architecture, I can only suggest a trick that will maybe spark some ideas in your head. Rather than using a crystal for the ADC, use a timer from the STM that is connected to an output pin, and clock the ADC using that pin (MCLK). When configuring the ADC using spi, idle mode, etc. you can leave this clock signal at 20Mhz. But when you need a sample from the ADC, stop the STM timer and clock the ADC "manually". (you practically control the DCLK signal). After your conversion routine is over, restart the timer at 20Mhz.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Nov 13 '18 at 14:55









          luci88filterluci88filter

          787




          787













          • A 20 Mhz clock for 32 bit data would mean you need approx. 600k samples per second. Are you sure you need that kind of data rate ? If so, maybe a microcontroller is not the appropriate solution.

            – luci88filter
            Nov 13 '18 at 15:00











          • Thanks @luci88filter, we have set the clock divider to 4, so it's 20MHz/4/32 = 80kSPS which is what we're shooting for. None the less, we're switching to a faster processor - 216MHz - should give us enough time to clock in and go - a total of 11 cycles at least, so we should be able to shift the data into a register at each clock edge. Hopefully. Thanks!

            – Jedi Engineer
            Nov 13 '18 at 15:21





















          • A 20 Mhz clock for 32 bit data would mean you need approx. 600k samples per second. Are you sure you need that kind of data rate ? If so, maybe a microcontroller is not the appropriate solution.

            – luci88filter
            Nov 13 '18 at 15:00











          • Thanks @luci88filter, we have set the clock divider to 4, so it's 20MHz/4/32 = 80kSPS which is what we're shooting for. None the less, we're switching to a faster processor - 216MHz - should give us enough time to clock in and go - a total of 11 cycles at least, so we should be able to shift the data into a register at each clock edge. Hopefully. Thanks!

            – Jedi Engineer
            Nov 13 '18 at 15:21



















          A 20 Mhz clock for 32 bit data would mean you need approx. 600k samples per second. Are you sure you need that kind of data rate ? If so, maybe a microcontroller is not the appropriate solution.

          – luci88filter
          Nov 13 '18 at 15:00





          A 20 Mhz clock for 32 bit data would mean you need approx. 600k samples per second. Are you sure you need that kind of data rate ? If so, maybe a microcontroller is not the appropriate solution.

          – luci88filter
          Nov 13 '18 at 15:00













          Thanks @luci88filter, we have set the clock divider to 4, so it's 20MHz/4/32 = 80kSPS which is what we're shooting for. None the less, we're switching to a faster processor - 216MHz - should give us enough time to clock in and go - a total of 11 cycles at least, so we should be able to shift the data into a register at each clock edge. Hopefully. Thanks!

          – Jedi Engineer
          Nov 13 '18 at 15:21







          Thanks @luci88filter, we have set the clock divider to 4, so it's 20MHz/4/32 = 80kSPS which is what we're shooting for. None the less, we're switching to a faster processor - 216MHz - should give us enough time to clock in and go - a total of 11 cycles at least, so we should be able to shift the data into a register at each clock edge. Hopefully. Thanks!

          – Jedi Engineer
          Nov 13 '18 at 15:21




















          draft saved

          draft discarded




















































          Thanks for contributing an answer to Stack Overflow!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53281745%2fread-non-conventional-adc-with-stm32f3%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          Popular posts from this blog

          Coverage of Google Street View

          Full-time equivalent

          Surfing