STM32 SPI not working as it I expect it should based on online reading
Clash 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?
spi stm32f103c8t6 rfm69
add a comment |Â
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?
spi stm32f103c8t6 rfm69
add a comment |Â
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?
spi stm32f103c8t6 rfm69
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
spi stm32f103c8t6 rfm69
asked 55 mins ago
Sam Hammamy
1345
1345
add a comment |Â
add a comment |Â
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(...);
add a comment |Â
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.
New contributor
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
add a comment |Â
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(...);
add a comment |Â
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(...);
add a comment |Â
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(...);
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(...);
answered 28 mins ago
bitsmack
11.2k63376
11.2k63376
add a comment |Â
add a comment |Â
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.
New contributor
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
add a comment |Â
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.
New contributor
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
add a comment |Â
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.
New contributor
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.
New contributor
edited 34 mins ago
New contributor
answered 40 mins ago
isdi
6066
6066
New contributor
New contributor
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
add a comment |Â
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
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
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
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password