STM32 SPI not working as it I expect it should based on online reading

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
1
down vote

favorite












I am using the STM32F103C8 to connect to an HopeRF95W chip for the purpose of learning.



I am only trying to read the chip version register, then write a config register that has a 0x00 reset value and then read it to make sure my write code works.



The hoperf95w datasheet says about SPI transfer:




SINGLE access: an address byte followed by a data byte is sent for a
write access whereas an address byte is sent and a read byte is
received for the read access. The NSS pin goes low at the beginning of
the frame and goes high after the data byte.



MOSI is generated by the master on the falling edge of SCK and is
sampled by the slave (i.e. this SPI interface) on the rising edge of
SCK. MISO is generated by the slave on the falling edge of SCK.



A transfer is always started by the NSS pin going low. MISO is high
impedance when NSS is high. The first byte is the address byte. It is
comprises:



􀂊 A wnr bit, which is 1 for write access and 0 for read
access.



􀂊 Then 7 bits of address, MSB first.




To me this means that reading a register requires only one transfer. Sending the address of the register, then waiting for the SPI_I2S_FLAG_RXNE flag, then the value of this register will be in the SPI data register.



However what's happening is I need two sequential of these write/flag/read operations to get the value:



uint8_t read_register(uint8_t address)

uint8_t data;
GPIO_ResetBits(GPIOA, GPIO_Pin_3); // slave select (low)
delay_ms(100);

while(!SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_TXE));
SPI_I2S_SendData(SPI1, address); // send

while(!SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_RXNE));
data = SPI_I2S_ReceiveData(SPI1); // read received

while(!SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_TXE));
SPI_I2S_SendData(SPI1, address); // send

while(!SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_RXNE));
data = SPI_I2S_ReceiveData(SPI1); // read received

GPIO_SetBits(GPIOA, GPIO_Pin_3); // slave deselect (high)
return data;



only by having these send/receive and then another send/receive can I get the expected value from the register. If don't make the second send, the receive returns a 0x00.



Writing is a little more straight forward, because it's a write of address, followed by a data write.



void write_register()

uint8_t numRead1 = 0;

GPIO_ResetBits(GPIOA, GPIO_Pin_3); // slave select (low)
delay_ms(100);

while(!SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_TXE));
SPI_I2S_SendData(SPI1, 0x40


In this case, I expect numRead1 to be 0x00 which is the default value of the register I am writing to. A subsequent call to read_register with the same address returns the value I wrote to it.



But I am sure there's a fundamental mistake in what I am doing which if not corrected will lead to bigger problems down the road.



Any thoughts?










share|improve this question

























    up vote
    1
    down vote

    favorite












    I am using the STM32F103C8 to connect to an HopeRF95W chip for the purpose of learning.



    I am only trying to read the chip version register, then write a config register that has a 0x00 reset value and then read it to make sure my write code works.



    The hoperf95w datasheet says about SPI transfer:




    SINGLE access: an address byte followed by a data byte is sent for a
    write access whereas an address byte is sent and a read byte is
    received for the read access. The NSS pin goes low at the beginning of
    the frame and goes high after the data byte.



    MOSI is generated by the master on the falling edge of SCK and is
    sampled by the slave (i.e. this SPI interface) on the rising edge of
    SCK. MISO is generated by the slave on the falling edge of SCK.



    A transfer is always started by the NSS pin going low. MISO is high
    impedance when NSS is high. The first byte is the address byte. It is
    comprises:



    􀂊 A wnr bit, which is 1 for write access and 0 for read
    access.



    􀂊 Then 7 bits of address, MSB first.




    To me this means that reading a register requires only one transfer. Sending the address of the register, then waiting for the SPI_I2S_FLAG_RXNE flag, then the value of this register will be in the SPI data register.



    However what's happening is I need two sequential of these write/flag/read operations to get the value:



    uint8_t read_register(uint8_t address)

    uint8_t data;
    GPIO_ResetBits(GPIOA, GPIO_Pin_3); // slave select (low)
    delay_ms(100);

    while(!SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_TXE));
    SPI_I2S_SendData(SPI1, address); // send

    while(!SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_RXNE));
    data = SPI_I2S_ReceiveData(SPI1); // read received

    while(!SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_TXE));
    SPI_I2S_SendData(SPI1, address); // send

    while(!SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_RXNE));
    data = SPI_I2S_ReceiveData(SPI1); // read received

    GPIO_SetBits(GPIOA, GPIO_Pin_3); // slave deselect (high)
    return data;



    only by having these send/receive and then another send/receive can I get the expected value from the register. If don't make the second send, the receive returns a 0x00.



    Writing is a little more straight forward, because it's a write of address, followed by a data write.



    void write_register()

    uint8_t numRead1 = 0;

    GPIO_ResetBits(GPIOA, GPIO_Pin_3); // slave select (low)
    delay_ms(100);

    while(!SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_TXE));
    SPI_I2S_SendData(SPI1, 0x40


    In this case, I expect numRead1 to be 0x00 which is the default value of the register I am writing to. A subsequent call to read_register with the same address returns the value I wrote to it.



    But I am sure there's a fundamental mistake in what I am doing which if not corrected will lead to bigger problems down the road.



    Any thoughts?










    share|improve this question























      up vote
      1
      down vote

      favorite









      up vote
      1
      down vote

      favorite











      I am using the STM32F103C8 to connect to an HopeRF95W chip for the purpose of learning.



      I am only trying to read the chip version register, then write a config register that has a 0x00 reset value and then read it to make sure my write code works.



      The hoperf95w datasheet says about SPI transfer:




      SINGLE access: an address byte followed by a data byte is sent for a
      write access whereas an address byte is sent and a read byte is
      received for the read access. The NSS pin goes low at the beginning of
      the frame and goes high after the data byte.



      MOSI is generated by the master on the falling edge of SCK and is
      sampled by the slave (i.e. this SPI interface) on the rising edge of
      SCK. MISO is generated by the slave on the falling edge of SCK.



      A transfer is always started by the NSS pin going low. MISO is high
      impedance when NSS is high. The first byte is the address byte. It is
      comprises:



      􀂊 A wnr bit, which is 1 for write access and 0 for read
      access.



      􀂊 Then 7 bits of address, MSB first.




      To me this means that reading a register requires only one transfer. Sending the address of the register, then waiting for the SPI_I2S_FLAG_RXNE flag, then the value of this register will be in the SPI data register.



      However what's happening is I need two sequential of these write/flag/read operations to get the value:



      uint8_t read_register(uint8_t address)

      uint8_t data;
      GPIO_ResetBits(GPIOA, GPIO_Pin_3); // slave select (low)
      delay_ms(100);

      while(!SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_TXE));
      SPI_I2S_SendData(SPI1, address); // send

      while(!SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_RXNE));
      data = SPI_I2S_ReceiveData(SPI1); // read received

      while(!SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_TXE));
      SPI_I2S_SendData(SPI1, address); // send

      while(!SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_RXNE));
      data = SPI_I2S_ReceiveData(SPI1); // read received

      GPIO_SetBits(GPIOA, GPIO_Pin_3); // slave deselect (high)
      return data;



      only by having these send/receive and then another send/receive can I get the expected value from the register. If don't make the second send, the receive returns a 0x00.



      Writing is a little more straight forward, because it's a write of address, followed by a data write.



      void write_register()

      uint8_t numRead1 = 0;

      GPIO_ResetBits(GPIOA, GPIO_Pin_3); // slave select (low)
      delay_ms(100);

      while(!SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_TXE));
      SPI_I2S_SendData(SPI1, 0x40


      In this case, I expect numRead1 to be 0x00 which is the default value of the register I am writing to. A subsequent call to read_register with the same address returns the value I wrote to it.



      But I am sure there's a fundamental mistake in what I am doing which if not corrected will lead to bigger problems down the road.



      Any thoughts?










      share|improve this question













      I am using the STM32F103C8 to connect to an HopeRF95W chip for the purpose of learning.



      I am only trying to read the chip version register, then write a config register that has a 0x00 reset value and then read it to make sure my write code works.



      The hoperf95w datasheet says about SPI transfer:




      SINGLE access: an address byte followed by a data byte is sent for a
      write access whereas an address byte is sent and a read byte is
      received for the read access. The NSS pin goes low at the beginning of
      the frame and goes high after the data byte.



      MOSI is generated by the master on the falling edge of SCK and is
      sampled by the slave (i.e. this SPI interface) on the rising edge of
      SCK. MISO is generated by the slave on the falling edge of SCK.



      A transfer is always started by the NSS pin going low. MISO is high
      impedance when NSS is high. The first byte is the address byte. It is
      comprises:



      􀂊 A wnr bit, which is 1 for write access and 0 for read
      access.



      􀂊 Then 7 bits of address, MSB first.




      To me this means that reading a register requires only one transfer. Sending the address of the register, then waiting for the SPI_I2S_FLAG_RXNE flag, then the value of this register will be in the SPI data register.



      However what's happening is I need two sequential of these write/flag/read operations to get the value:



      uint8_t read_register(uint8_t address)

      uint8_t data;
      GPIO_ResetBits(GPIOA, GPIO_Pin_3); // slave select (low)
      delay_ms(100);

      while(!SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_TXE));
      SPI_I2S_SendData(SPI1, address); // send

      while(!SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_RXNE));
      data = SPI_I2S_ReceiveData(SPI1); // read received

      while(!SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_TXE));
      SPI_I2S_SendData(SPI1, address); // send

      while(!SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_RXNE));
      data = SPI_I2S_ReceiveData(SPI1); // read received

      GPIO_SetBits(GPIOA, GPIO_Pin_3); // slave deselect (high)
      return data;



      only by having these send/receive and then another send/receive can I get the expected value from the register. If don't make the second send, the receive returns a 0x00.



      Writing is a little more straight forward, because it's a write of address, followed by a data write.



      void write_register()

      uint8_t numRead1 = 0;

      GPIO_ResetBits(GPIOA, GPIO_Pin_3); // slave select (low)
      delay_ms(100);

      while(!SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_TXE));
      SPI_I2S_SendData(SPI1, 0x40


      In this case, I expect numRead1 to be 0x00 which is the default value of the register I am writing to. A subsequent call to read_register with the same address returns the value I wrote to it.



      But I am sure there's a fundamental mistake in what I am doing which if not corrected will lead to bigger problems down the road.



      Any thoughts?







      spi stm32f103c8t6 rfm69






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked 55 mins ago









      Sam Hammamy

      1345




      1345




















          2 Answers
          2






          active

          oldest

          votes

















          up vote
          2
          down vote



          accepted










          The slave device can only communicate when it is provided a clock from the master (your STM32). This complicates reading from the slave, because you have to cause the master to provide enough clock cycles for the slave to respond.



          When you send an SPI command via SPI_I2S_SendData(), two transmission actually happen during the same eight clock pulses. The first is that your byte is clocked out of the MOSI line. But, at the same time, data is being clocked in to the microcontroller via the MISO line.



          But since the slave doesn't get the full command until the end of these transactions, it doesn't present any data to the bus. This results in a received value of 0x00 or 0xFF.



          Then you need to provide an additional eight clocks to allow the slave to return the actual value. With the STM32, this is done by sending a "dummy byte" to the slave.



          Note that, in the first transmission, the master ignores whatever arrives from the slave. In the second transmission, the slave ignores whatever is sent by the master.



          The code should look something like this:



          // Activate the SS pin
          GPIO_ResetBits(...);

          // Send the command
          SPI_I2S_SendData(SPI_BUS, txbyte);

          // When the byte completes sending, the RXNE flag will get set
          // and must be cleared by reading the Data Register.
          // Notice that the value in the data register is ignored.
          while (SPI_I2S_GetFlagStatus(SPI_BUS, SPI_I2S_FLAG_RXNE) == RESET);
          SPI_I2S_ReceiveData(SPI_BUS); // Notice there is no variable assignment here!

          // Now get the response. Load the data register (DR) with a dummy
          // byte to start data reception.
          SPI_I2S_SendData(SPI_BUS, 0);

          // When the dummy byte completes sending, the RX buffer will contain the
          // response byte. Get it.
          while (SPI_I2S_GetFlagStatus(SPI_BUS, SPI_I2S_FLAG_RXNE) == RESET);
          rxbyte = SPI_I2S_ReceiveData(SPI_BUS);
          }

          // Release the SS line
          GPIO_SetBits(...);





          share|improve this answer



























            up vote
            2
            down vote













            The Hope chip has to get the address of the register you wish to read, that happens on the first byte transfer, at which point it's loaded into the Hope SPI MISO register to be transmitted as the next (dummy) byte is sent out by the master (since it's a read operation).



            Alternatively the next byte transmitted out can be another read/write operation, but the pump has to be primed so to speak, with reads being sent back on the next byte SPI transaction.






            share|improve this answer










            New contributor




            isdi is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
            Check out our Code of Conduct.

















            • Thanks Isdi! I suspected as much but wanted to verify.
              – Sam Hammamy
              29 mins ago










            • Do you have an example of a professional / clean code that does this? I am a hobbyist but I am a soft. developer and want my code to be clean!
              – Sam Hammamy
              28 mins ago






            • 1




              I'm a believer in writing code that the coder can understand 1 year after looking at it. I've seen some TI embedded stuff that makes an embedded programmer with 40 years cringe with the amount of pointer passing (my words not his) just so they're "unified" across their SimpleLink platform. One thing I would do is check the setup time for the chip select, I'm positive you don't need 100ms, probably closer to 100ns; but check the Hope datasheet to be sure.
              – isdi
              20 mins ago










            Your Answer




            StackExchange.ifUsing("editor", function ()
            return StackExchange.using("mathjaxEditing", function ()
            StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix)
            StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["\$", "\$"]]);
            );
            );
            , "mathjax-editing");

            StackExchange.ifUsing("editor", function ()
            return StackExchange.using("schematics", function ()
            StackExchange.schematics.init();
            );
            , "cicuitlab");

            StackExchange.ready(function()
            var channelOptions =
            tags: "".split(" "),
            id: "135"
            ;
            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',
            convertImagesToLinks: false,
            noModals: false,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: null,
            bindNavPrevention: true,
            postfix: "",
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            );



            );













             

            draft saved


            draft discarded


















            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2felectronics.stackexchange.com%2fquestions%2f402672%2fstm32-spi-not-working-as-it-i-expect-it-should-based-on-online-reading%23new-answer', 'question_page');

            );

            Post as a guest






























            2 Answers
            2






            active

            oldest

            votes








            2 Answers
            2






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes








            up vote
            2
            down vote



            accepted










            The slave device can only communicate when it is provided a clock from the master (your STM32). This complicates reading from the slave, because you have to cause the master to provide enough clock cycles for the slave to respond.



            When you send an SPI command via SPI_I2S_SendData(), two transmission actually happen during the same eight clock pulses. The first is that your byte is clocked out of the MOSI line. But, at the same time, data is being clocked in to the microcontroller via the MISO line.



            But since the slave doesn't get the full command until the end of these transactions, it doesn't present any data to the bus. This results in a received value of 0x00 or 0xFF.



            Then you need to provide an additional eight clocks to allow the slave to return the actual value. With the STM32, this is done by sending a "dummy byte" to the slave.



            Note that, in the first transmission, the master ignores whatever arrives from the slave. In the second transmission, the slave ignores whatever is sent by the master.



            The code should look something like this:



            // Activate the SS pin
            GPIO_ResetBits(...);

            // Send the command
            SPI_I2S_SendData(SPI_BUS, txbyte);

            // When the byte completes sending, the RXNE flag will get set
            // and must be cleared by reading the Data Register.
            // Notice that the value in the data register is ignored.
            while (SPI_I2S_GetFlagStatus(SPI_BUS, SPI_I2S_FLAG_RXNE) == RESET);
            SPI_I2S_ReceiveData(SPI_BUS); // Notice there is no variable assignment here!

            // Now get the response. Load the data register (DR) with a dummy
            // byte to start data reception.
            SPI_I2S_SendData(SPI_BUS, 0);

            // When the dummy byte completes sending, the RX buffer will contain the
            // response byte. Get it.
            while (SPI_I2S_GetFlagStatus(SPI_BUS, SPI_I2S_FLAG_RXNE) == RESET);
            rxbyte = SPI_I2S_ReceiveData(SPI_BUS);
            }

            // Release the SS line
            GPIO_SetBits(...);





            share|improve this answer
























              up vote
              2
              down vote



              accepted










              The slave device can only communicate when it is provided a clock from the master (your STM32). This complicates reading from the slave, because you have to cause the master to provide enough clock cycles for the slave to respond.



              When you send an SPI command via SPI_I2S_SendData(), two transmission actually happen during the same eight clock pulses. The first is that your byte is clocked out of the MOSI line. But, at the same time, data is being clocked in to the microcontroller via the MISO line.



              But since the slave doesn't get the full command until the end of these transactions, it doesn't present any data to the bus. This results in a received value of 0x00 or 0xFF.



              Then you need to provide an additional eight clocks to allow the slave to return the actual value. With the STM32, this is done by sending a "dummy byte" to the slave.



              Note that, in the first transmission, the master ignores whatever arrives from the slave. In the second transmission, the slave ignores whatever is sent by the master.



              The code should look something like this:



              // Activate the SS pin
              GPIO_ResetBits(...);

              // Send the command
              SPI_I2S_SendData(SPI_BUS, txbyte);

              // When the byte completes sending, the RXNE flag will get set
              // and must be cleared by reading the Data Register.
              // Notice that the value in the data register is ignored.
              while (SPI_I2S_GetFlagStatus(SPI_BUS, SPI_I2S_FLAG_RXNE) == RESET);
              SPI_I2S_ReceiveData(SPI_BUS); // Notice there is no variable assignment here!

              // Now get the response. Load the data register (DR) with a dummy
              // byte to start data reception.
              SPI_I2S_SendData(SPI_BUS, 0);

              // When the dummy byte completes sending, the RX buffer will contain the
              // response byte. Get it.
              while (SPI_I2S_GetFlagStatus(SPI_BUS, SPI_I2S_FLAG_RXNE) == RESET);
              rxbyte = SPI_I2S_ReceiveData(SPI_BUS);
              }

              // Release the SS line
              GPIO_SetBits(...);





              share|improve this answer






















                up vote
                2
                down vote



                accepted







                up vote
                2
                down vote



                accepted






                The slave device can only communicate when it is provided a clock from the master (your STM32). This complicates reading from the slave, because you have to cause the master to provide enough clock cycles for the slave to respond.



                When you send an SPI command via SPI_I2S_SendData(), two transmission actually happen during the same eight clock pulses. The first is that your byte is clocked out of the MOSI line. But, at the same time, data is being clocked in to the microcontroller via the MISO line.



                But since the slave doesn't get the full command until the end of these transactions, it doesn't present any data to the bus. This results in a received value of 0x00 or 0xFF.



                Then you need to provide an additional eight clocks to allow the slave to return the actual value. With the STM32, this is done by sending a "dummy byte" to the slave.



                Note that, in the first transmission, the master ignores whatever arrives from the slave. In the second transmission, the slave ignores whatever is sent by the master.



                The code should look something like this:



                // Activate the SS pin
                GPIO_ResetBits(...);

                // Send the command
                SPI_I2S_SendData(SPI_BUS, txbyte);

                // When the byte completes sending, the RXNE flag will get set
                // and must be cleared by reading the Data Register.
                // Notice that the value in the data register is ignored.
                while (SPI_I2S_GetFlagStatus(SPI_BUS, SPI_I2S_FLAG_RXNE) == RESET);
                SPI_I2S_ReceiveData(SPI_BUS); // Notice there is no variable assignment here!

                // Now get the response. Load the data register (DR) with a dummy
                // byte to start data reception.
                SPI_I2S_SendData(SPI_BUS, 0);

                // When the dummy byte completes sending, the RX buffer will contain the
                // response byte. Get it.
                while (SPI_I2S_GetFlagStatus(SPI_BUS, SPI_I2S_FLAG_RXNE) == RESET);
                rxbyte = SPI_I2S_ReceiveData(SPI_BUS);
                }

                // Release the SS line
                GPIO_SetBits(...);





                share|improve this answer












                The slave device can only communicate when it is provided a clock from the master (your STM32). This complicates reading from the slave, because you have to cause the master to provide enough clock cycles for the slave to respond.



                When you send an SPI command via SPI_I2S_SendData(), two transmission actually happen during the same eight clock pulses. The first is that your byte is clocked out of the MOSI line. But, at the same time, data is being clocked in to the microcontroller via the MISO line.



                But since the slave doesn't get the full command until the end of these transactions, it doesn't present any data to the bus. This results in a received value of 0x00 or 0xFF.



                Then you need to provide an additional eight clocks to allow the slave to return the actual value. With the STM32, this is done by sending a "dummy byte" to the slave.



                Note that, in the first transmission, the master ignores whatever arrives from the slave. In the second transmission, the slave ignores whatever is sent by the master.



                The code should look something like this:



                // Activate the SS pin
                GPIO_ResetBits(...);

                // Send the command
                SPI_I2S_SendData(SPI_BUS, txbyte);

                // When the byte completes sending, the RXNE flag will get set
                // and must be cleared by reading the Data Register.
                // Notice that the value in the data register is ignored.
                while (SPI_I2S_GetFlagStatus(SPI_BUS, SPI_I2S_FLAG_RXNE) == RESET);
                SPI_I2S_ReceiveData(SPI_BUS); // Notice there is no variable assignment here!

                // Now get the response. Load the data register (DR) with a dummy
                // byte to start data reception.
                SPI_I2S_SendData(SPI_BUS, 0);

                // When the dummy byte completes sending, the RX buffer will contain the
                // response byte. Get it.
                while (SPI_I2S_GetFlagStatus(SPI_BUS, SPI_I2S_FLAG_RXNE) == RESET);
                rxbyte = SPI_I2S_ReceiveData(SPI_BUS);
                }

                // Release the SS line
                GPIO_SetBits(...);






                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered 28 mins ago









                bitsmack

                11.2k63376




                11.2k63376






















                    up vote
                    2
                    down vote













                    The Hope chip has to get the address of the register you wish to read, that happens on the first byte transfer, at which point it's loaded into the Hope SPI MISO register to be transmitted as the next (dummy) byte is sent out by the master (since it's a read operation).



                    Alternatively the next byte transmitted out can be another read/write operation, but the pump has to be primed so to speak, with reads being sent back on the next byte SPI transaction.






                    share|improve this answer










                    New contributor




                    isdi is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                    Check out our Code of Conduct.

















                    • Thanks Isdi! I suspected as much but wanted to verify.
                      – Sam Hammamy
                      29 mins ago










                    • Do you have an example of a professional / clean code that does this? I am a hobbyist but I am a soft. developer and want my code to be clean!
                      – Sam Hammamy
                      28 mins ago






                    • 1




                      I'm a believer in writing code that the coder can understand 1 year after looking at it. I've seen some TI embedded stuff that makes an embedded programmer with 40 years cringe with the amount of pointer passing (my words not his) just so they're "unified" across their SimpleLink platform. One thing I would do is check the setup time for the chip select, I'm positive you don't need 100ms, probably closer to 100ns; but check the Hope datasheet to be sure.
                      – isdi
                      20 mins ago














                    up vote
                    2
                    down vote













                    The Hope chip has to get the address of the register you wish to read, that happens on the first byte transfer, at which point it's loaded into the Hope SPI MISO register to be transmitted as the next (dummy) byte is sent out by the master (since it's a read operation).



                    Alternatively the next byte transmitted out can be another read/write operation, but the pump has to be primed so to speak, with reads being sent back on the next byte SPI transaction.






                    share|improve this answer










                    New contributor




                    isdi is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                    Check out our Code of Conduct.

















                    • Thanks Isdi! I suspected as much but wanted to verify.
                      – Sam Hammamy
                      29 mins ago










                    • Do you have an example of a professional / clean code that does this? I am a hobbyist but I am a soft. developer and want my code to be clean!
                      – Sam Hammamy
                      28 mins ago






                    • 1




                      I'm a believer in writing code that the coder can understand 1 year after looking at it. I've seen some TI embedded stuff that makes an embedded programmer with 40 years cringe with the amount of pointer passing (my words not his) just so they're "unified" across their SimpleLink platform. One thing I would do is check the setup time for the chip select, I'm positive you don't need 100ms, probably closer to 100ns; but check the Hope datasheet to be sure.
                      – isdi
                      20 mins ago












                    up vote
                    2
                    down vote










                    up vote
                    2
                    down vote









                    The Hope chip has to get the address of the register you wish to read, that happens on the first byte transfer, at which point it's loaded into the Hope SPI MISO register to be transmitted as the next (dummy) byte is sent out by the master (since it's a read operation).



                    Alternatively the next byte transmitted out can be another read/write operation, but the pump has to be primed so to speak, with reads being sent back on the next byte SPI transaction.






                    share|improve this answer










                    New contributor




                    isdi is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                    Check out our Code of Conduct.









                    The Hope chip has to get the address of the register you wish to read, that happens on the first byte transfer, at which point it's loaded into the Hope SPI MISO register to be transmitted as the next (dummy) byte is sent out by the master (since it's a read operation).



                    Alternatively the next byte transmitted out can be another read/write operation, but the pump has to be primed so to speak, with reads being sent back on the next byte SPI transaction.







                    share|improve this answer










                    New contributor




                    isdi is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                    Check out our Code of Conduct.









                    share|improve this answer



                    share|improve this answer








                    edited 34 mins ago





















                    New contributor




                    isdi is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                    Check out our Code of Conduct.









                    answered 40 mins ago









                    isdi

                    6066




                    6066




                    New contributor




                    isdi is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                    Check out our Code of Conduct.





                    New contributor





                    isdi is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                    Check out our Code of Conduct.






                    isdi is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                    Check out our Code of Conduct.











                    • Thanks Isdi! I suspected as much but wanted to verify.
                      – Sam Hammamy
                      29 mins ago










                    • Do you have an example of a professional / clean code that does this? I am a hobbyist but I am a soft. developer and want my code to be clean!
                      – Sam Hammamy
                      28 mins ago






                    • 1




                      I'm a believer in writing code that the coder can understand 1 year after looking at it. I've seen some TI embedded stuff that makes an embedded programmer with 40 years cringe with the amount of pointer passing (my words not his) just so they're "unified" across their SimpleLink platform. One thing I would do is check the setup time for the chip select, I'm positive you don't need 100ms, probably closer to 100ns; but check the Hope datasheet to be sure.
                      – isdi
                      20 mins ago
















                    • Thanks Isdi! I suspected as much but wanted to verify.
                      – Sam Hammamy
                      29 mins ago










                    • Do you have an example of a professional / clean code that does this? I am a hobbyist but I am a soft. developer and want my code to be clean!
                      – Sam Hammamy
                      28 mins ago






                    • 1




                      I'm a believer in writing code that the coder can understand 1 year after looking at it. I've seen some TI embedded stuff that makes an embedded programmer with 40 years cringe with the amount of pointer passing (my words not his) just so they're "unified" across their SimpleLink platform. One thing I would do is check the setup time for the chip select, I'm positive you don't need 100ms, probably closer to 100ns; but check the Hope datasheet to be sure.
                      – isdi
                      20 mins ago















                    Thanks Isdi! I suspected as much but wanted to verify.
                    – Sam Hammamy
                    29 mins ago




                    Thanks Isdi! I suspected as much but wanted to verify.
                    – Sam Hammamy
                    29 mins ago












                    Do you have an example of a professional / clean code that does this? I am a hobbyist but I am a soft. developer and want my code to be clean!
                    – Sam Hammamy
                    28 mins ago




                    Do you have an example of a professional / clean code that does this? I am a hobbyist but I am a soft. developer and want my code to be clean!
                    – Sam Hammamy
                    28 mins ago




                    1




                    1




                    I'm a believer in writing code that the coder can understand 1 year after looking at it. I've seen some TI embedded stuff that makes an embedded programmer with 40 years cringe with the amount of pointer passing (my words not his) just so they're "unified" across their SimpleLink platform. One thing I would do is check the setup time for the chip select, I'm positive you don't need 100ms, probably closer to 100ns; but check the Hope datasheet to be sure.
                    – isdi
                    20 mins ago




                    I'm a believer in writing code that the coder can understand 1 year after looking at it. I've seen some TI embedded stuff that makes an embedded programmer with 40 years cringe with the amount of pointer passing (my words not his) just so they're "unified" across their SimpleLink platform. One thing I would do is check the setup time for the chip select, I'm positive you don't need 100ms, probably closer to 100ns; but check the Hope datasheet to be sure.
                    – isdi
                    20 mins ago

















                     

                    draft saved


                    draft discarded















































                     


                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function ()
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2felectronics.stackexchange.com%2fquestions%2f402672%2fstm32-spi-not-working-as-it-i-expect-it-should-based-on-online-reading%23new-answer', 'question_page');

                    );

                    Post as a guest













































































                    Popular posts from this blog

                    How to check contact read email or not when send email to Individual?

                    Displaying single band from multi-band raster using QGIS

                    How many registers does an x86_64 CPU actually have?