SPI Communication with S12x (Slave), any hardware flags showing that transmission  has finished?

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 
已解决

SPI Communication with S12x (Slave), any hardware flags showing that transmission  has finished?

跳至解决方案
1,497 次查看
tomnai
Contributor I

Hello,
I am working on an SPI communication between an S12X (as slave) and an embedded PC as master.

The master sends a 3-byte command to the slave and first  receives the number of data bytes to read. Then the master sends the corresponding number of dummy bytes on MOSI /receives the data bytes on MISO.
Between two consecutive datablocks (sized limited to 1000 bytes) I need  to reset counters, buffers etc. Thats why  I need  to  know when all data bytes were sent.  

So far I used the number of the sent bytes returned by the SPI - Sendblock-routine (automatically generated by  codewarrior 5.9 /ProcessorExpert), but this doesn't really  tell when send-block has finished the data transfer.
When  I set the data receive counter (RxCharCounter) to zero,  often the transmission hasn't finished by then. Then  the receive counter, starting from zero counts the bytes from the unfinished transmission.
This causes errors in the interpretation of the following command bytes.
 
My questions is:

  • How do I know for certain, that the SPI data transfer  (from the microcontroller to the embedded PC - via Sendblock ) has  finished? In principle I could wait for long enough, but since the master is not a realtime system there is a big variability in the duration of the transmission, this is not a really good option.
  • Important: I need to know when the hardware has finished the data transfer (and not when all data has been copied to the transmit-buffer).
  • Is there a hardware flag showing that the transmission is complete?


Best regards

Tom

标签 (1)
标记 (1)
0 项奖励
回复
1 解答
1,111 次查看
bigmac
Specialist III

Hello Tom,

 

If you were using your own SPI code, rather than PE code, you should already be aware when the final byte of the sequence was written to the SPI hardware buffer SPIDR, and when the transmission of this byte actually commenced (SPISR_SPTEF == 1).  When the master has then sent all bits of the corressponding dummy byte, SPISR_SPIF will become set, to indicate the completion of the final both-way transfer.  Usually the master will raise the /SS signal a short while after this occurs.

 

If PE function is not capable of detecting the occurrence of this sequence, perhaps you should consider modifying the code generated by PE.  You might rename the modified function and/or ISR, to prevent PE from further messing it (and potentially erasing it).

 

Regards,

Mac

 

在原帖中查看解决方案

0 项奖励
回复
2 回复数
1,112 次查看
bigmac
Specialist III

Hello Tom,

 

If you were using your own SPI code, rather than PE code, you should already be aware when the final byte of the sequence was written to the SPI hardware buffer SPIDR, and when the transmission of this byte actually commenced (SPISR_SPTEF == 1).  When the master has then sent all bits of the corressponding dummy byte, SPISR_SPIF will become set, to indicate the completion of the final both-way transfer.  Usually the master will raise the /SS signal a short while after this occurs.

 

If PE function is not capable of detecting the occurrence of this sequence, perhaps you should consider modifying the code generated by PE.  You might rename the modified function and/or ISR, to prevent PE from further messing it (and potentially erasing it).

 

Regards,

Mac

 

0 项奖励
回复
1,111 次查看
tomnai
Contributor I

Hello Mac,

thanks, we are currently focusing on the slave select signal, so this might be right approach.

Regards,

Tom

0 项奖励
回复