

![]() |
  | |||||||||||||
![]() |
|
![]() |
||||||||||||
![]() STM8/SPI Chip Select & Interrupt
Started by ByteMaster, May 15 2012 09:25 PM
7 replies to this topic
#1
Posted 15 May 2012 - 09:25 PM
Being the ultra-impatient developer
![]() ![]()
Kevin D. Wolf
Windows Phone Development MVP President Software Logistics, LLC Tampa, FL
#2
Posted 15 May 2012 - 10:31 PM
Hi Kevin,
One option is to enable interrupts for the actual pin that you are using as the SPI CS input (rather than using any SPI-specific interrupt). For example, you could enable a rising interrupt for pin A3 (if that is the pin you are using for SPI CS) and process the incoming message in the interrupt handler for that pin.
Currently, with the RGB LED and potentiometer modules, all SPI messages are 18 bytes long, with the last byte being the computed CRC8 value for the message. So an alternative to monitoring the SPI CS pin would be to process each incoming message after receiving the 18th byte (as long as that byte contains a valid CRC).
Much of the protocol will be changing once the official generic firmware is released, so it's probably not worth worrying too much about the details of your protocol at this point. Either of these methods should work for now, and you'll be able to update your module's firmware to work with the new protocol in the future (as long as it follows the recommended electrical specifications).
Matt
#3
Posted 16 May 2012 - 12:19 AM
To add to what Matt said...
You can use the SPI Select pin in one of two modes: hardware or software.
If you use it in hardware mode, you'll get an interrupt after every SPI byte is received. But you won't know when your frame started or stopped, apart from your own counting and error correction.
If you use it in software mode, you can use an interrupt on the line to enable SPI receive mode...and then trap the select line's deassertion to know that you've been deselected. That's most likely how we'll be doing things with the generic firmware, since the SS line gives us a good synchronization strategy.
Chris
#4
Posted 16 May 2012 - 07:15 AM Could you please provide more details on why you'd like to get rid of the payload size in the message? I am not saying it is good or wrong, both approaches have their pros and cons. There are a few things to consider, though:
#5
Posted 16 May 2012 - 12:46 PM
Hi Matt - thanks for the reply
I had thought I read somewhere in the STM8 programming manual that if a pin was configured for an alternative purpose, it could contribute to an external interrupt. I guess I could be wrong and it wouldn't be too difficult to test it. Even if we can't use it in an external interrupt, there are usually a couple other unused pins on the device, one of which I could tie to the "Slave Select"/SS line rather than "Chip Select"/CS as I called it. I'm fairly certain some of my messages will be more than 18 bytes and some considerably less. I guess when the chip is running at 16MHz with a fast SPI bus it might not be a big deal. Just trying to be as efficient as possible. Good Point! Thanks! Kevin...
Kevin D. Wolf
Windows Phone Development MVP President Software Logistics, LLC Tampa, FL
#6
Posted 16 May 2012 - 12:48 PM
Interesting...I never considered looking at the software mode, I think I'll have to read up on that this afternoon. I think I see where you are going with this. Thanks Kevin...
Kevin D. Wolf
Windows Phone Development MVP President Software Logistics, LLC Tampa, FL
#7
Posted 16 May 2012 - 01:07 PM
Thanks CW2 - I guess for what I'm doing, I'm controlling both sides of the equation and not necessarily trying to create an industry standard. But reliable communications is a must so you brought up some good points.
To your primary question:
I guess more than anything the primary reason is it's just an extra one or two bytes that get sent that are probably not necessary. But as Matt said earlier in the conversation, this is really just temporary until we get a more standardized approach so what's a few extra micro seconds/clock cycles to simplify things. I guess my original vision was some sort of State Machine on both ends that just read in a byte (or handled an interrupt), and depending on what state and figure out what to do with it. You did bring up a good point though
I know my module code "libraries" will send a frame as a transaction, but really don't know enough about NETMF to know if some other higher priority interrupt could come in and suspend my modules SPI transmission. Right now I'm feeling very much overwhelmed by the stuff Thanks again - Kevin...
Kevin D. Wolf
Windows Phone Development MVP President Software Logistics, LLC Tampa, FL
#8
Posted 18 May 2012 - 01:36 PM
Ok - coming off of vacation mode...I think I finally understand this direction and what Chris suggested. So basically configure SPI to use Software NSS Management or the SPI_NSS_SOFT option in SPI_Init. SPI_Init(SPI_FIRSTBIT_MSB, SPI_BAUDRATEPRESCALER_2, SPI_MODE_SLAVE, SPI_CLOCKPOLARITY_LOW, SPI_CLOCKPHASE_2EDGE, SPI_DATADIRECTION_2LINES_FULLDUPLEX, SPI_NSS_SOFT, 0x07); Then configure the input pin that was originally configured for hardware SS as just a GPIO interrupt; GPIO_Init(NSS_PORT, NSS_PIN, GPIO_MODE_IN_FL_IT); EXTI_SetExtIntSensitivity(EXTI_PORT_GPIOA, EXTI_SENSITIVITY_RISE_FALL); Then in the interrupt handler do something like INTERRUPT_HANDLER(EXTI_PORTA_IRQHandler, 3) { if(GPIO_ReadInputPin(GPIOA, GPIO_PIN_3) == SET) GO_SS_Released(); else GO_SS_Asserted(); } to determine when the transmission starts and ends. Got it...this is exactly what I was looking for. This still brings up CW2's point:
As I mentioned earlier, not knowing about the NETMF internals, is there a case where a higher priority interrupt could come in and suspend the SPI transition from the Master? I think when checking the CRC byte at the end of the message, I know if it's a valid message or not. Maybe implement some ACK/NAK handshaking. Seems like it's starting to get a bit complex/chatty though ![]() Kevin...
Kevin D. Wolf
Windows Phone Development MVP President Software Logistics, LLC Tampa, FL 0 user(s) are reading this topic0 members, 0 guests, 0 anonymous users | ||||||||||||||
![]() |
||||||||||||||
![]() |
|
![]() |
||||||||||||
![]() |
This webpage is licensed under a Creative Commons Attribution-ShareAlike License. | ![]() |
||||||||||||
![]() |