Hi, which flag has to be monitored to be sure an spi transaction is finished,
the RX or the TX, are the same, because when you send by the spi you also
recieve, which is the difference from the program point of view?, Thanks to
all.
PD Im talking about the msp430f5438 which I know its spi has some difference
with the previous.
Spi simple question
Started by ●March 28, 2009
Reply by ●March 30, 20092009-03-30
On the MSP, the USART TX flag doesn't indicate that the transmission has
finished, it only indicates that the TX buffer is empty. There still might be
bits in the shift register that are being sent. For that matter, neither does
TXEPT flag, which indicates that the shift register is empty, because it (seams
to) sets as soon as the last bit in the shift register hits the output pin,
which is half a clock cycle before the clock edge on which the (spi) slave
capturates the data bit.
So, you need to use the RX flag, which is tricky when you try to take advantage of the "double buffering" (one byte for shifting out and another one to store the next byte) sending multiple bytes in a row. Tricky, because RX falg will set when the second last byte written to the TXBUFFER has been received by the slave. And this won't work if the function can be interrupted, because you could miss an RX flag and the function would get stuck.
I guess one could use a combination of TXEPT and reading the clock pin value. It should work, but I haven't tried it.
I any case, I haven't found a single use for TXEPT flag. I think I've asked before and gotten no answers, but if anyone has an idea of what TXEPT could be used for, please enlighten me.
I might be wrong, but I think the USCI hasn't this problem, basically because it doesn't have a transmit buffer, just a single shift register that's used for both transmitting and receiving data, in which case probably both Rx and TX flag will work the same in SPI master mode.
Regards,
Michael K.
--- In m..., "datacardio" wrote:
>
> Hi, which flag has to be monitored to be sure an spi transaction is finished, the RX or the TX, are the same, because when you send by the spi you also recieve, which is the difference from the program point of view?, Thanks to all.
>
> PD Im talking about the msp430f5438 which I know its spi has some difference with the previous.
>
So, you need to use the RX flag, which is tricky when you try to take advantage of the "double buffering" (one byte for shifting out and another one to store the next byte) sending multiple bytes in a row. Tricky, because RX falg will set when the second last byte written to the TXBUFFER has been received by the slave. And this won't work if the function can be interrupted, because you could miss an RX flag and the function would get stuck.
I guess one could use a combination of TXEPT and reading the clock pin value. It should work, but I haven't tried it.
I any case, I haven't found a single use for TXEPT flag. I think I've asked before and gotten no answers, but if anyone has an idea of what TXEPT could be used for, please enlighten me.
I might be wrong, but I think the USCI hasn't this problem, basically because it doesn't have a transmit buffer, just a single shift register that's used for both transmitting and receiving data, in which case probably both Rx and TX flag will work the same in SPI master mode.
Regards,
Michael K.
--- In m..., "datacardio" wrote:
>
> Hi, which flag has to be monitored to be sure an spi transaction is finished, the RX or the TX, are the same, because when you send by the spi you also recieve, which is the difference from the program point of view?, Thanks to all.
>
> PD Im talking about the msp430f5438 which I know its spi has some difference with the previous.
>
Reply by ●March 31, 20092009-03-31
"tintronic" :
> On the MSP, the USART TX flag doesn't indicate that the transmission has
> finished, it only indicates that the TX buffer is empty. There still
> might be bits in the shift register that are being sent. For that
> matter, neither does TXEPT flag, which indicates that the shift register
> is empty, because it (seams to) sets as soon as the last bit in the
> shift register hits the output pin, which is half a clock cycle before
> the clock edge on which the (spi) slave capturates the data bit. So, you
> need to use the RX flag, which is tricky when you try to take advantage
> of the "double buffering" (one byte for shifting out and another one to
> store the next byte) sending multiple bytes in a row. Tricky, because RX
> falg will set when the second last byte written to the TXBUFFER has been
> received by the slave. And this won't work if the function can be
> interrupted, because you could miss an RX flag and the function would
> get stuck. I guess one could use a combination of TXEPT and reading the
> clock pin value. It should work, but I haven't tried it. I any case, I
> haven't found a single use for TXEPT flag. I think I've asked before and
> gotten no answers, but if anyone has an idea of what TXEPT could be used
> for, please enlighten me.
I might be wrong but I think you are mixing the meaning of two flags. TXIFG
is set once the TXBUF is loaded into the shift register (like your
description). After that the shift register clocks 8 bits out of the TXD-Pin
and when this is finished the TXEPT is set. For SPI master TXEPT is set at
the same time as RXIFG.
I have used TXEPT to wait until the last character has shifted out
completely. Only after that it is allowed to set LPM3 (because with LPM3
the UART clock will be stopped also in some cases).
> I might be wrong, but I think the USCI hasn't this problem, basically
> because it doesn't have a transmit buffer, just a single shift register
> that's used for both transmitting and receiving data, in which case
> probably both Rx and TX flag will work the same in SPI master mode.
No. Just got USCI and DMA working and I have learned that TXIFG is set when
TXBUF is loaded into the shift register, then the 8 bits are clocked out and
(at the same time) 8 bits are clocked in and after that RXIFG is set.
In both serial engines (USART and USCI) there are always 2 registers - one
buffer for the character (TXBUF) and the (invisible) shift register. The
transfer from TXBUF to the shift register will wait, until the shift out has
been finished (double buffering).
M.
> On the MSP, the USART TX flag doesn't indicate that the transmission has
> finished, it only indicates that the TX buffer is empty. There still
> might be bits in the shift register that are being sent. For that
> matter, neither does TXEPT flag, which indicates that the shift register
> is empty, because it (seams to) sets as soon as the last bit in the
> shift register hits the output pin, which is half a clock cycle before
> the clock edge on which the (spi) slave capturates the data bit. So, you
> need to use the RX flag, which is tricky when you try to take advantage
> of the "double buffering" (one byte for shifting out and another one to
> store the next byte) sending multiple bytes in a row. Tricky, because RX
> falg will set when the second last byte written to the TXBUFFER has been
> received by the slave. And this won't work if the function can be
> interrupted, because you could miss an RX flag and the function would
> get stuck. I guess one could use a combination of TXEPT and reading the
> clock pin value. It should work, but I haven't tried it. I any case, I
> haven't found a single use for TXEPT flag. I think I've asked before and
> gotten no answers, but if anyone has an idea of what TXEPT could be used
> for, please enlighten me.
I might be wrong but I think you are mixing the meaning of two flags. TXIFG
is set once the TXBUF is loaded into the shift register (like your
description). After that the shift register clocks 8 bits out of the TXD-Pin
and when this is finished the TXEPT is set. For SPI master TXEPT is set at
the same time as RXIFG.
I have used TXEPT to wait until the last character has shifted out
completely. Only after that it is allowed to set LPM3 (because with LPM3
the UART clock will be stopped also in some cases).
> I might be wrong, but I think the USCI hasn't this problem, basically
> because it doesn't have a transmit buffer, just a single shift register
> that's used for both transmitting and receiving data, in which case
> probably both Rx and TX flag will work the same in SPI master mode.
No. Just got USCI and DMA working and I have learned that TXIFG is set when
TXBUF is loaded into the shift register, then the 8 bits are clocked out and
(at the same time) 8 bits are clocked in and after that RXIFG is set.
In both serial engines (USART and USCI) there are always 2 registers - one
buffer for the character (TXBUF) and the (invisible) shift register. The
transfer from TXBUF to the shift register will wait, until the shift out has
been finished (double buffering).
M.
Reply by ●March 31, 20092009-03-31
Matthias Weingart :
> In both serial engines (USART and USCI) there are always 2 registers -
> one buffer for the character (TXBUF) and the (invisible) shift register.
> The transfer from TXBUF to the shift register will wait, until the shift
> out has been finished (double buffering).
To correct myself: this is wrong. No real double buffering. It seems the
transfer from TXBUF to the shift register will occur with each write access
to TXBUF. You have to check TXIFG before you can write to TXBUF, otherwise
characters got lost.
M.
> In both serial engines (USART and USCI) there are always 2 registers -
> one buffer for the character (TXBUF) and the (invisible) shift register.
> The transfer from TXBUF to the shift register will wait, until the shift
> out has been finished (double buffering).
To correct myself: this is wrong. No real double buffering. It seems the
transfer from TXBUF to the shift register will occur with each write access
to TXBUF. You have to check TXIFG before you can write to TXBUF, otherwise
characters got lost.
M.
Reply by ●March 31, 20092009-03-31
Thanks Matthias for answering, as I would like to dig more into this issue.
First, I was wrong about the USCI. I was remembering a block diagram which I couldn't find now. USCI does have double buffering. And it has a UCBUSY flag which is much more useful and makes a lot more sense than the TXEPT flag, which by the way USCI doesn't have.
On the USART matter, I'm not mixing the flags, I know what each one does. BUT, TI's datasheets don't provide any diagram where you can see TX, RX and EPT flags behaviour concurrently during an SPI transfer. Actually, there is no timing of EPT whatsoever, only a brief description stating that it sets when the shift register is empty, but when exactly is that? That's where the guessing and asumptions start. Making assumptions, that's a receipe for disaster.
Have you ever used EPT flag for deselecting the SPI slave? I have done so without luck. So have other people on the forum (many more were wrongly using TX flag). They had to put a delay after EPT or the slave wouldn't recognize the last byte.
Even TI's sample codes (CC1100 for example) don't use EPT flag for deselecting the slave on SPI burst writes, instead they use the RX flag. Since I very often use more than one SPI slave on the same bus, my codes always deselect the devices after transfer completion.
And yes, I know one has to check the timing parameters of the slave to know how much time after the last SPI clock edge one has to wait before deselecting the device for it to accept the full byte. I have respected all the timing parameters (hell, the time on some devices is shorter than one 8MHz clock cycle) and still I have had to use RX flag because EPT wouldn't work.
All of the above leads me to think the EPT flag sets as soon as the last transmitted bit is present at the MOSI pin, which effectively empties the shift register, before the following clock edge which is when the slave captures the MOSI pin value. I still might be wrong, as I haven't used EPT ever again, but based on my above observations, I can't conclude anything else. I mean, why the hell wouldn't TI publish the timing diagram of TXEPT or at least include it on the timing diagram of the SPI transfer?
I've made drivers for various SPI and SPI-like devices, all using the RX flag, so any new SPI devices I just recycle code from another device. I've not dealt with EPT ever again, I've got some ideas on how to really know when EPT sets, but just haven't got the time right now to test it. It would be as simple as using an external clock source like a (filtered) push button, or a very slow SPI clock, and a couple of leds that permanently show the status of the TX, RX and EPT flags and the MOSI and CLK pins.
Best Regards,
Michael K.
--- In m..., Matthias Weingart wrote:
>
> "tintronic" :
>
> > On the MSP, the USART TX flag doesn't indicate that the transmission has
> > finished, it only indicates that the TX buffer is empty. There still
> > might be bits in the shift register that are being sent. For that
> > matter, neither does TXEPT flag, which indicates that the shift register
> > is empty, because it (seams to) sets as soon as the last bit in the
> > shift register hits the output pin, which is half a clock cycle before
> > the clock edge on which the (spi) slave capturates the data bit. So, you
> > need to use the RX flag, which is tricky when you try to take advantage
> > of the "double buffering" (one byte for shifting out and another one to
> > store the next byte) sending multiple bytes in a row. Tricky, because RX
> > falg will set when the second last byte written to the TXBUFFER has been
> > received by the slave. And this won't work if the function can be
> > interrupted, because you could miss an RX flag and the function would
> > get stuck. I guess one could use a combination of TXEPT and reading the
> > clock pin value. It should work, but I haven't tried it. I any case, I
> > haven't found a single use for TXEPT flag. I think I've asked before and
> > gotten no answers, but if anyone has an idea of what TXEPT could be used
> > for, please enlighten me.
>
> I might be wrong but I think you are mixing the meaning of two flags. TXIFG
> is set once the TXBUF is loaded into the shift register (like your
> description). After that the shift register clocks 8 bits out of the TXD-Pin
> and when this is finished the TXEPT is set. For SPI master TXEPT is set at
> the same time as RXIFG.
> I have used TXEPT to wait until the last character has shifted out
> completely. Only after that it is allowed to set LPM3 (because with LPM3
> the UART clock will be stopped also in some cases).
>
> > I might be wrong, but I think the USCI hasn't this problem, basically
> > because it doesn't have a transmit buffer, just a single shift register
> > that's used for both transmitting and receiving data, in which case
> > probably both Rx and TX flag will work the same in SPI master mode.
>
> No. Just got USCI and DMA working and I have learned that TXIFG is set when
> TXBUF is loaded into the shift register, then the 8 bits are clocked out and
> (at the same time) 8 bits are clocked in and after that RXIFG is set.
>
> In both serial engines (USART and USCI) there are always 2 registers - one
> buffer for the character (TXBUF) and the (invisible) shift register. The
> transfer from TXBUF to the shift register will wait, until the shift out has
> been finished (double buffering).
>
> M.
>
First, I was wrong about the USCI. I was remembering a block diagram which I couldn't find now. USCI does have double buffering. And it has a UCBUSY flag which is much more useful and makes a lot more sense than the TXEPT flag, which by the way USCI doesn't have.
On the USART matter, I'm not mixing the flags, I know what each one does. BUT, TI's datasheets don't provide any diagram where you can see TX, RX and EPT flags behaviour concurrently during an SPI transfer. Actually, there is no timing of EPT whatsoever, only a brief description stating that it sets when the shift register is empty, but when exactly is that? That's where the guessing and asumptions start. Making assumptions, that's a receipe for disaster.
Have you ever used EPT flag for deselecting the SPI slave? I have done so without luck. So have other people on the forum (many more were wrongly using TX flag). They had to put a delay after EPT or the slave wouldn't recognize the last byte.
Even TI's sample codes (CC1100 for example) don't use EPT flag for deselecting the slave on SPI burst writes, instead they use the RX flag. Since I very often use more than one SPI slave on the same bus, my codes always deselect the devices after transfer completion.
And yes, I know one has to check the timing parameters of the slave to know how much time after the last SPI clock edge one has to wait before deselecting the device for it to accept the full byte. I have respected all the timing parameters (hell, the time on some devices is shorter than one 8MHz clock cycle) and still I have had to use RX flag because EPT wouldn't work.
All of the above leads me to think the EPT flag sets as soon as the last transmitted bit is present at the MOSI pin, which effectively empties the shift register, before the following clock edge which is when the slave captures the MOSI pin value. I still might be wrong, as I haven't used EPT ever again, but based on my above observations, I can't conclude anything else. I mean, why the hell wouldn't TI publish the timing diagram of TXEPT or at least include it on the timing diagram of the SPI transfer?
I've made drivers for various SPI and SPI-like devices, all using the RX flag, so any new SPI devices I just recycle code from another device. I've not dealt with EPT ever again, I've got some ideas on how to really know when EPT sets, but just haven't got the time right now to test it. It would be as simple as using an external clock source like a (filtered) push button, or a very slow SPI clock, and a couple of leds that permanently show the status of the TX, RX and EPT flags and the MOSI and CLK pins.
Best Regards,
Michael K.
--- In m..., Matthias Weingart wrote:
>
> "tintronic" :
>
> > On the MSP, the USART TX flag doesn't indicate that the transmission has
> > finished, it only indicates that the TX buffer is empty. There still
> > might be bits in the shift register that are being sent. For that
> > matter, neither does TXEPT flag, which indicates that the shift register
> > is empty, because it (seams to) sets as soon as the last bit in the
> > shift register hits the output pin, which is half a clock cycle before
> > the clock edge on which the (spi) slave capturates the data bit. So, you
> > need to use the RX flag, which is tricky when you try to take advantage
> > of the "double buffering" (one byte for shifting out and another one to
> > store the next byte) sending multiple bytes in a row. Tricky, because RX
> > falg will set when the second last byte written to the TXBUFFER has been
> > received by the slave. And this won't work if the function can be
> > interrupted, because you could miss an RX flag and the function would
> > get stuck. I guess one could use a combination of TXEPT and reading the
> > clock pin value. It should work, but I haven't tried it. I any case, I
> > haven't found a single use for TXEPT flag. I think I've asked before and
> > gotten no answers, but if anyone has an idea of what TXEPT could be used
> > for, please enlighten me.
>
> I might be wrong but I think you are mixing the meaning of two flags. TXIFG
> is set once the TXBUF is loaded into the shift register (like your
> description). After that the shift register clocks 8 bits out of the TXD-Pin
> and when this is finished the TXEPT is set. For SPI master TXEPT is set at
> the same time as RXIFG.
> I have used TXEPT to wait until the last character has shifted out
> completely. Only after that it is allowed to set LPM3 (because with LPM3
> the UART clock will be stopped also in some cases).
>
> > I might be wrong, but I think the USCI hasn't this problem, basically
> > because it doesn't have a transmit buffer, just a single shift register
> > that's used for both transmitting and receiving data, in which case
> > probably both Rx and TX flag will work the same in SPI master mode.
>
> No. Just got USCI and DMA working and I have learned that TXIFG is set when
> TXBUF is loaded into the shift register, then the 8 bits are clocked out and
> (at the same time) 8 bits are clocked in and after that RXIFG is set.
>
> In both serial engines (USART and USCI) there are always 2 registers - one
> buffer for the character (TXBUF) and the (invisible) shift register. The
> transfer from TXBUF to the shift register will wait, until the shift out has
> been finished (double buffering).
>
> M.
>
Reply by ●April 1, 20092009-04-01
Hi Michael,
I have used TXEPT for RS232 asynchronous transfers only. I think using the
RXIFG for SPI is a good idea, nothing to say against this. I also use only
RXIFG for SPI. (In that case you can ignore TXIFG completely.)
M.
"tintronic" :
> Thanks Matthias for answering, as I would like to dig more into this
> issue. First, I was wrong about the USCI. I was remembering a block
> diagram which I couldn't find now. USCI does have double buffering. And
> it has a UCBUSY flag which is much more useful and makes a lot more
> sense than the TXEPT flag, which by the way USCI doesn't have.
>
> On the USART matter, I'm not mixing the flags, I know what each one
> does. BUT, TI's datasheets don't provide any diagram where you can see
> TX, RX and EPT flags behaviour concurrently during an SPI transfer.
> Actually, there is no timing of EPT whatsoever, only a brief description
> stating that it sets when the shift register is empty, but when exactly
> is that? That's where the guessing and asumptions start. Making
> assumptions, that's a receipe for disaster.
>
> Have you ever used EPT flag for deselecting the SPI slave? I have done
> so without luck. So have other people on the forum (many more were
> wrongly using TX flag). They had to put a delay after EPT or the slave
> wouldn't recognize the last byte. Even TI's sample codes (CC1100 for
> example) don't use EPT flag for deselecting the slave on SPI burst
> writes, instead they use the RX flag. Since I very often use more than
> one SPI slave on the same bus, my codes always deselect the devices
> after transfer completion.
>
> And yes, I know one has to check the timing parameters of the slave to
> know how much time after the last SPI clock edge one has to wait before
> deselecting the device for it to accept the full byte. I have respected
> all the timing parameters (hell, the time on some devices is shorter
> than one 8MHz clock cycle) and still I have had to use RX flag because
> EPT wouldn't work.
>
> All of the above leads me to think the EPT flag sets as soon as the last
> transmitted bit is present at the MOSI pin, which effectively empties
> the shift register, before the following clock edge which is when the
> slave captures the MOSI pin value. I still might be wrong, as I haven't
> used EPT ever again, but based on my above observations, I can't
> conclude anything else. I mean, why the hell wouldn't TI publish the
> timing diagram of TXEPT or at least include it on the timing diagram of
> the SPI transfer?
>
> I've made drivers for various SPI and SPI-like devices, all using the RX
> flag, so any new SPI devices I just recycle code from another device.
> I've not dealt with EPT ever again, I've got some ideas on how to really
> know when EPT sets, but just haven't got the time right now to test it.
> It would be as simple as using an external clock source like a
> (filtered) push button, or a very slow SPI clock, and a couple of leds
> that permanently show the status of the TX, RX and EPT flags and the
> MOSI and CLK pins.
>
> Best Regards,
> Michael K.
>
> --- In m..., Matthias Weingart wrote:
>>
>> "tintronic" :
>>
>> > On the MSP, the USART TX flag doesn't indicate that the transmission
>> > has finished, it only indicates that the TX buffer is empty. There
>> > still might be bits in the shift register that are being sent. For
>> > that matter, neither does TXEPT flag, which indicates that the shift
>> > register is empty, because it (seams to) sets as soon as the last bit
>> > in the shift register hits the output pin, which is half a clock
>> > cycle before the clock edge on which the (spi) slave capturates the
>> > data bit. So, you need to use the RX flag, which is tricky when you
>> > try to take advantage of the "double buffering" (one byte for
>> > shifting out and another one to store the next byte) sending multiple
>> > bytes in a row. Tricky, because RX falg will set when the second last
>> > byte written to the TXBUFFER has been received by the slave. And this
>> > won't work if the function can be interrupted, because you could miss
>> > an RX flag and the function would get stuck. I guess one could use a
>> > combination of TXEPT and reading the clock pin value. It should work,
>> > but I haven't tried it. I any case, I haven't found a single use for
>> > TXEPT flag. I think I've asked before and gotten no answers, but if
>> > anyone has an idea of what TXEPT could be used for, please enlighten
>> > me.
>>
>> I might be wrong but I think you are mixing the meaning of two flags.
>> TXIFG is set once the TXBUF is loaded into the shift register (like
>> your description). After that the shift register clocks 8 bits out of
>> the TXD-Pin and when this is finished the TXEPT is set. For SPI master
>> TXEPT is set at the same time as RXIFG.
>> I have used TXEPT to wait until the last character has shifted out
>> completely. Only after that it is allowed to set LPM3 (because with
>> LPM3 the UART clock will be stopped also in some cases).
>>
>> > I might be wrong, but I think the USCI hasn't this problem, basically
>> > because it doesn't have a transmit buffer, just a single shift
>> > register that's used for both transmitting and receiving data, in
>> > which case probably both Rx and TX flag will work the same in SPI
>> > master mode.
>>
>> No. Just got USCI and DMA working and I have learned that TXIFG is set
>> when TXBUF is loaded into the shift register, then the 8 bits are
>> clocked out and (at the same time) 8 bits are clocked in and after that
>> RXIFG is set.
>>
>> In both serial engines (USART and USCI) there are always 2 registers -
>> one buffer for the character (TXBUF) and the (invisible) shift
>> register. The transfer from TXBUF to the shift register will wait,
>> until the shift out has been finished (double buffering).
>>
>> M.
>>
>
I have used TXEPT for RS232 asynchronous transfers only. I think using the
RXIFG for SPI is a good idea, nothing to say against this. I also use only
RXIFG for SPI. (In that case you can ignore TXIFG completely.)
M.
"tintronic" :
> Thanks Matthias for answering, as I would like to dig more into this
> issue. First, I was wrong about the USCI. I was remembering a block
> diagram which I couldn't find now. USCI does have double buffering. And
> it has a UCBUSY flag which is much more useful and makes a lot more
> sense than the TXEPT flag, which by the way USCI doesn't have.
>
> On the USART matter, I'm not mixing the flags, I know what each one
> does. BUT, TI's datasheets don't provide any diagram where you can see
> TX, RX and EPT flags behaviour concurrently during an SPI transfer.
> Actually, there is no timing of EPT whatsoever, only a brief description
> stating that it sets when the shift register is empty, but when exactly
> is that? That's where the guessing and asumptions start. Making
> assumptions, that's a receipe for disaster.
>
> Have you ever used EPT flag for deselecting the SPI slave? I have done
> so without luck. So have other people on the forum (many more were
> wrongly using TX flag). They had to put a delay after EPT or the slave
> wouldn't recognize the last byte. Even TI's sample codes (CC1100 for
> example) don't use EPT flag for deselecting the slave on SPI burst
> writes, instead they use the RX flag. Since I very often use more than
> one SPI slave on the same bus, my codes always deselect the devices
> after transfer completion.
>
> And yes, I know one has to check the timing parameters of the slave to
> know how much time after the last SPI clock edge one has to wait before
> deselecting the device for it to accept the full byte. I have respected
> all the timing parameters (hell, the time on some devices is shorter
> than one 8MHz clock cycle) and still I have had to use RX flag because
> EPT wouldn't work.
>
> All of the above leads me to think the EPT flag sets as soon as the last
> transmitted bit is present at the MOSI pin, which effectively empties
> the shift register, before the following clock edge which is when the
> slave captures the MOSI pin value. I still might be wrong, as I haven't
> used EPT ever again, but based on my above observations, I can't
> conclude anything else. I mean, why the hell wouldn't TI publish the
> timing diagram of TXEPT or at least include it on the timing diagram of
> the SPI transfer?
>
> I've made drivers for various SPI and SPI-like devices, all using the RX
> flag, so any new SPI devices I just recycle code from another device.
> I've not dealt with EPT ever again, I've got some ideas on how to really
> know when EPT sets, but just haven't got the time right now to test it.
> It would be as simple as using an external clock source like a
> (filtered) push button, or a very slow SPI clock, and a couple of leds
> that permanently show the status of the TX, RX and EPT flags and the
> MOSI and CLK pins.
>
> Best Regards,
> Michael K.
>
> --- In m..., Matthias Weingart wrote:
>>
>> "tintronic" :
>>
>> > On the MSP, the USART TX flag doesn't indicate that the transmission
>> > has finished, it only indicates that the TX buffer is empty. There
>> > still might be bits in the shift register that are being sent. For
>> > that matter, neither does TXEPT flag, which indicates that the shift
>> > register is empty, because it (seams to) sets as soon as the last bit
>> > in the shift register hits the output pin, which is half a clock
>> > cycle before the clock edge on which the (spi) slave capturates the
>> > data bit. So, you need to use the RX flag, which is tricky when you
>> > try to take advantage of the "double buffering" (one byte for
>> > shifting out and another one to store the next byte) sending multiple
>> > bytes in a row. Tricky, because RX falg will set when the second last
>> > byte written to the TXBUFFER has been received by the slave. And this
>> > won't work if the function can be interrupted, because you could miss
>> > an RX flag and the function would get stuck. I guess one could use a
>> > combination of TXEPT and reading the clock pin value. It should work,
>> > but I haven't tried it. I any case, I haven't found a single use for
>> > TXEPT flag. I think I've asked before and gotten no answers, but if
>> > anyone has an idea of what TXEPT could be used for, please enlighten
>> > me.
>>
>> I might be wrong but I think you are mixing the meaning of two flags.
>> TXIFG is set once the TXBUF is loaded into the shift register (like
>> your description). After that the shift register clocks 8 bits out of
>> the TXD-Pin and when this is finished the TXEPT is set. For SPI master
>> TXEPT is set at the same time as RXIFG.
>> I have used TXEPT to wait until the last character has shifted out
>> completely. Only after that it is allowed to set LPM3 (because with
>> LPM3 the UART clock will be stopped also in some cases).
>>
>> > I might be wrong, but I think the USCI hasn't this problem, basically
>> > because it doesn't have a transmit buffer, just a single shift
>> > register that's used for both transmitting and receiving data, in
>> > which case probably both Rx and TX flag will work the same in SPI
>> > master mode.
>>
>> No. Just got USCI and DMA working and I have learned that TXIFG is set
>> when TXBUF is loaded into the shift register, then the 8 bits are
>> clocked out and (at the same time) 8 bits are clocked in and after that
>> RXIFG is set.
>>
>> In both serial engines (USART and USCI) there are always 2 registers -
>> one buffer for the character (TXBUF) and the (invisible) shift
>> register. The transfer from TXBUF to the shift register will wait,
>> until the shift out has been finished (double buffering).
>>
>> M.
>>
>
Reply by ●April 1, 20092009-04-01
Thanks for the answer , but I want to show you where there is a
problem with the spi. Im using the msp430t5438, which has some difference
with respect to the other series in employing the flags. I use this
routine to send data
while (!(UCB0IFG&UCTXIFG)); // USCI_B0 TX buffer ready?
UCB0TXBUF = value; // Send value
TI_CC_Wait(10); // ¡¡¡¡¡ this should not be here!!!!!!
TI_CC_CSn_PxOUT |= TI_CC_CSn_PIN; // /CS disable
The problem is, if I don’t use the delay, the clock and data are still running.( I saw in the oscilloscope)
when the spi is disable by the next instruction. This way it work, but I do not understand where is the problem, I have tried also using the RX flag but it is the same.
This in place of delay :
while (!(UCB0IFG&UCRXIFG));
Any ideas will be welcome, excuse my English…
________________________________
De: Matthias Weingart
Para: m...
Enviado: miércoles 1 de abril de 2009, 7:47:59
Asunto: [msp430] Re: Spi simple question
Hi Michael,
I have used TXEPT for RS232 asynchronous transfers only. I think using the
RXIFG for SPI is a good idea, nothing to say against this. I also use only
RXIFG for SPI. (In that case you can ignore TXIFG completely.)
M.
"tintronic" :
> Thanks Matthias for answering, as I would like to dig more into this
> issue. First, I was wrong about the USCI. I was remembering a block
> diagram which I couldn't find now. USCI does have double buffering. And
> it has a UCBUSY flag which is much more useful and makes a lot more
> sense than the TXEPT flag, which by the way USCI doesn't have.
>
> On the USART matter, I'm not mixing the flags, I know what each one
> does. BUT, TI's datasheets don't provide any diagram where you can see
> TX, RX and EPT flags behaviour concurrently during an SPI transfer.
> Actually, there is no timing of EPT whatsoever, only a brief description
> stating that it sets when the shift register is empty, but when exactly
> is that? That's where the guessing and asumptions start. Making
> assumptions, that's a receipe for disaster.
>
> Have you ever used EPT flag for deselecting the SPI slave? I have done
> so without luck. So have other people on the forum (many more were
> wrongly using TX flag). They had to put a delay after EPT or the slave
> wouldn't recognize the last byte. Even TI's sample codes (CC1100 for
> example) don't use EPT flag for deselecting the slave on SPI burst
> writes, instead they use the RX flag. Since I very often use more than
> one SPI slave on the same bus, my codes always deselect the devices
> after transfer completion.
>
> And yes, I know one has to check the timing parameters of the slave to
> know how much time after the last SPI clock edge one has to wait before
> deselecting the device for it to accept the full byte. I have respected
> all the timing parameters (hell, the time on some devices is shorter
> than one 8MHz clock cycle) and still I have had to use RX flag because
> EPT wouldn't work.
>
> All of the above leads me to think the EPT flag sets as soon as the last
> transmitted bit is present at the MOSI pin, which effectively empties
> the shift register, before the following clock edge which is when the
> slave captures the MOSI pin value. I still might be wrong, as I haven't
> used EPT ever again, but based on my above observations, I can't
> conclude anything else. I mean, why the hell wouldn't TI publish the
> timing diagram of TXEPT or at least include it on the timing diagram of
> the SPI transfer?
>
> I've made drivers for various SPI and SPI-like devices, all using the RX
> flag, so any new SPI devices I just recycle code from another device.
> I've not dealt with EPT ever again, I've got some ideas on how to really
> know when EPT sets, but just haven't got the time right now to test it.
> It would be as simple as using an external clock source like a
> (filtered) push button, or a very slow SPI clock, and a couple of leds
> that permanently show the status of the TX, RX and EPT flags and the
> MOSI and CLK pins.
>
> Best Regards,
> Michael K.
>
> --- In msp430@yahoogroups. com, Matthias Weingart wrote:
>>
>> "tintronic" :
>>
>> > On the MSP, the USART TX flag doesn't indicate that the transmission
>> > has finished, it only indicates that the TX buffer is empty. There
>> > still might be bits in the shift register that are being sent. For
>> > that matter, neither does TXEPT flag, which indicates that the shift
>> > register is empty, because it (seams to) sets as soon as the last bit
>> > in the shift register hits the output pin, which is half a clock
>> > cycle before the clock edge on which the (spi) slave capturates the
>> > data bit. So, you need to use the RX flag, which is tricky when you
>> > try to take advantage of the "double buffering" (one byte for
>> > shifting out and another one to store the next byte) sending multiple
>> > bytes in a row. Tricky, because RX falg will set when the second last
>> > byte written to the TXBUFFER has been received by the slave. And this
>> > won't work if the function can be interrupted, because you could miss
>> > an RX flag and the function would get stuck. I guess one could use a
>> > combination of TXEPT and reading the clock pin value. It should work,
>> > but I haven't tried it. I any case, I haven't found a single use for
>> > TXEPT flag. I think I've asked before and gotten no answers, but if
>> > anyone has an idea of what TXEPT could be used for, please enlighten
>> > me.
>>
>> I might be wrong but I think you are mixing the meaning of two flags.
>> TXIFG is set once the TXBUF is loaded into the shift register (like
>> your description) . After that the shift register clocks 8 bits out of
>> the TXD-Pin and when this is finished the TXEPT is set. For SPI master
>> TXEPT is set at the same time as RXIFG.
>> I have used TXEPT to wait until the last character has shifted out
>> completely. Only after that it is allowed to set LPM3 (because with
>> LPM3 the UART clock will be stopped also in some cases).
>>
>> > I might be wrong, but I think the USCI hasn't this problem, basically
>> > because it doesn't have a transmit buffer, just a single shift
>> > register that's used for both transmitting and receiving data, in
>> > which case probably both Rx and TX flag will work the same in SPI
>> > master mode.
>>
>> No. Just got USCI and DMA working and I have learned that TXIFG is set
>> when TXBUF is loaded into the shift register, then the 8 bits are
>> clocked out and (at the same time) 8 bits are clocked in and after that
>> RXIFG is set.
>>
>> In both serial engines (USART and USCI) there are always 2 registers -
>> one buffer for the character (TXBUF) and the (invisible) shift
>> register. The transfer from TXBUF to the shift register will wait,
>> until the shift out has been finished (double buffering).
>>
>> M.
>>
>
>
>
>
> ------------ --------- --------- ------
>
>
>
>
while (!(UCB0IFG&UCTXIFG)); // USCI_B0 TX buffer ready?
UCB0TXBUF = value; // Send value
TI_CC_Wait(10); // ¡¡¡¡¡ this should not be here!!!!!!
TI_CC_CSn_PxOUT |= TI_CC_CSn_PIN; // /CS disable
The problem is, if I don’t use the delay, the clock and data are still running.( I saw in the oscilloscope)
when the spi is disable by the next instruction. This way it work, but I do not understand where is the problem, I have tried also using the RX flag but it is the same.
This in place of delay :
while (!(UCB0IFG&UCRXIFG));
Any ideas will be welcome, excuse my English…
________________________________
De: Matthias Weingart
Para: m...
Enviado: miércoles 1 de abril de 2009, 7:47:59
Asunto: [msp430] Re: Spi simple question
Hi Michael,
I have used TXEPT for RS232 asynchronous transfers only. I think using the
RXIFG for SPI is a good idea, nothing to say against this. I also use only
RXIFG for SPI. (In that case you can ignore TXIFG completely.)
M.
"tintronic" :
> Thanks Matthias for answering, as I would like to dig more into this
> issue. First, I was wrong about the USCI. I was remembering a block
> diagram which I couldn't find now. USCI does have double buffering. And
> it has a UCBUSY flag which is much more useful and makes a lot more
> sense than the TXEPT flag, which by the way USCI doesn't have.
>
> On the USART matter, I'm not mixing the flags, I know what each one
> does. BUT, TI's datasheets don't provide any diagram where you can see
> TX, RX and EPT flags behaviour concurrently during an SPI transfer.
> Actually, there is no timing of EPT whatsoever, only a brief description
> stating that it sets when the shift register is empty, but when exactly
> is that? That's where the guessing and asumptions start. Making
> assumptions, that's a receipe for disaster.
>
> Have you ever used EPT flag for deselecting the SPI slave? I have done
> so without luck. So have other people on the forum (many more were
> wrongly using TX flag). They had to put a delay after EPT or the slave
> wouldn't recognize the last byte. Even TI's sample codes (CC1100 for
> example) don't use EPT flag for deselecting the slave on SPI burst
> writes, instead they use the RX flag. Since I very often use more than
> one SPI slave on the same bus, my codes always deselect the devices
> after transfer completion.
>
> And yes, I know one has to check the timing parameters of the slave to
> know how much time after the last SPI clock edge one has to wait before
> deselecting the device for it to accept the full byte. I have respected
> all the timing parameters (hell, the time on some devices is shorter
> than one 8MHz clock cycle) and still I have had to use RX flag because
> EPT wouldn't work.
>
> All of the above leads me to think the EPT flag sets as soon as the last
> transmitted bit is present at the MOSI pin, which effectively empties
> the shift register, before the following clock edge which is when the
> slave captures the MOSI pin value. I still might be wrong, as I haven't
> used EPT ever again, but based on my above observations, I can't
> conclude anything else. I mean, why the hell wouldn't TI publish the
> timing diagram of TXEPT or at least include it on the timing diagram of
> the SPI transfer?
>
> I've made drivers for various SPI and SPI-like devices, all using the RX
> flag, so any new SPI devices I just recycle code from another device.
> I've not dealt with EPT ever again, I've got some ideas on how to really
> know when EPT sets, but just haven't got the time right now to test it.
> It would be as simple as using an external clock source like a
> (filtered) push button, or a very slow SPI clock, and a couple of leds
> that permanently show the status of the TX, RX and EPT flags and the
> MOSI and CLK pins.
>
> Best Regards,
> Michael K.
>
> --- In msp430@yahoogroups. com, Matthias Weingart wrote:
>>
>> "tintronic" :
>>
>> > On the MSP, the USART TX flag doesn't indicate that the transmission
>> > has finished, it only indicates that the TX buffer is empty. There
>> > still might be bits in the shift register that are being sent. For
>> > that matter, neither does TXEPT flag, which indicates that the shift
>> > register is empty, because it (seams to) sets as soon as the last bit
>> > in the shift register hits the output pin, which is half a clock
>> > cycle before the clock edge on which the (spi) slave capturates the
>> > data bit. So, you need to use the RX flag, which is tricky when you
>> > try to take advantage of the "double buffering" (one byte for
>> > shifting out and another one to store the next byte) sending multiple
>> > bytes in a row. Tricky, because RX falg will set when the second last
>> > byte written to the TXBUFFER has been received by the slave. And this
>> > won't work if the function can be interrupted, because you could miss
>> > an RX flag and the function would get stuck. I guess one could use a
>> > combination of TXEPT and reading the clock pin value. It should work,
>> > but I haven't tried it. I any case, I haven't found a single use for
>> > TXEPT flag. I think I've asked before and gotten no answers, but if
>> > anyone has an idea of what TXEPT could be used for, please enlighten
>> > me.
>>
>> I might be wrong but I think you are mixing the meaning of two flags.
>> TXIFG is set once the TXBUF is loaded into the shift register (like
>> your description) . After that the shift register clocks 8 bits out of
>> the TXD-Pin and when this is finished the TXEPT is set. For SPI master
>> TXEPT is set at the same time as RXIFG.
>> I have used TXEPT to wait until the last character has shifted out
>> completely. Only after that it is allowed to set LPM3 (because with
>> LPM3 the UART clock will be stopped also in some cases).
>>
>> > I might be wrong, but I think the USCI hasn't this problem, basically
>> > because it doesn't have a transmit buffer, just a single shift
>> > register that's used for both transmitting and receiving data, in
>> > which case probably both Rx and TX flag will work the same in SPI
>> > master mode.
>>
>> No. Just got USCI and DMA working and I have learned that TXIFG is set
>> when TXBUF is loaded into the shift register, then the 8 bits are
>> clocked out and (at the same time) 8 bits are clocked in and after that
>> RXIFG is set.
>>
>> In both serial engines (USART and USCI) there are always 2 registers -
>> one buffer for the character (TXBUF) and the (invisible) shift
>> register. The transfer from TXBUF to the shift register will wait,
>> until the shift out has been finished (double buffering).
>>
>> M.
>>
>
>
>
>
> ------------ --------- --------- ------
>
>
>
>
Reply by ●April 1, 20092009-04-01
Ok, I'm not sure what your problem is, either you didn't explain it
well or you have no idea what you are doing.
Obviously, you need to wait for the byte to be transferred completely (plus the delay your slave specifies after the last SPI clock edge) before disabling the slave, right? So you can't disable #CS right after writing to the buffer, which means you can't just delete TI_CC_Wait();
Your code only writes one byte, so I'll assume that you're not trying to send more than one byte.
One way do to know if the transmission has finished is by means of the RXIFG. But you have to clear RXIFG by software before sending the byte. Then you write to TX buffer and wait for RXIFG to set, after which you wait for the appropiate time (it might be less than an MSP instruction cycle) and disable #CS.
Did you search this forum? This has been wiiiidely discussed before.
Michael K.
--- In m..., mm bb wrote:
>
> Thanks for the answer , but I want to show you where there is a problem with the spi. Im using the msp430t5438, which has some difference with respect to the other series in employing the flags. I use this routine to send data
>
>
> while (!(UCB0IFG&UCTXIFG)); // USCI_B0 TX buffer ready?
> UCB0TXBUF = value; // Send value
>
> TI_CC_Wait(10); // this should not be here!!!!!!
>
>TI_CC_CSn_PxOUT |= TI_CC_CSn_PIN;// /CS disable
>
> The problem is, if I don'tt use the delay, the clock and data are still running.( I saw in the oscilloscope)
> when the spi is disable by the next instruction. This way it work, but I do not understand where is the problem, I have tried also using the RX flag but it is the same.
> This in place of delay :
> while (!(UCB0IFG&UCRXIFG));
> Any ideas will be welcome, excuse my English#65533;
>
>
>
> ________________________________
> De: Matthias Weingart
> Para: m...
> Enviado: miércoles 1 de abril de 2009, 7:47:59
> Asunto: [msp430] Re: Spi simple question
>
>
> Hi Michael,
>
> I have used TXEPT for RS232 asynchronous transfers only. I think using the
> RXIFG for SPI is a good idea, nothing to say against this. I also use only
> RXIFG for SPI. (In that case you can ignore TXIFG completely.)
>
> M.
>
> "tintronic" :
>
> > Thanks Matthias for answering, as I would like to dig more into this
> > issue. First, I was wrong about the USCI. I was remembering a block
> > diagram which I couldn't find now. USCI does have double buffering. And
> > it has a UCBUSY flag which is much more useful and makes a lot more
> > sense than the TXEPT flag, which by the way USCI doesn't have.
> >
> > On the USART matter, I'm not mixing the flags, I know what each one
> > does. BUT, TI's datasheets don't provide any diagram where you can see
> > TX, RX and EPT flags behaviour concurrently during an SPI transfer.
> > Actually, there is no timing of EPT whatsoever, only a brief description
> > stating that it sets when the shift register is empty, but when exactly
> > is that? That's where the guessing and asumptions start. Making
> > assumptions, that's a receipe for disaster.
> >
> > Have you ever used EPT flag for deselecting the SPI slave? I have done
> > so without luck. So have other people on the forum (many more were
> > wrongly using TX flag). They had to put a delay after EPT or the slave
> > wouldn't recognize the last byte. Even TI's sample codes (CC1100 for
> > example) don't use EPT flag for deselecting the slave on SPI burst
> > writes, instead they use the RX flag. Since I very often use more than
> > one SPI slave on the same bus, my codes always deselect the devices
> > after transfer completion.
> >
> > And yes, I know one has to check the timing parameters of the slave to
> > know how much time after the last SPI clock edge one has to wait before
> > deselecting the device for it to accept the full byte. I have respected
> > all the timing parameters (hell, the time on some devices is shorter
> > than one 8MHz clock cycle) and still I have had to use RX flag because
> > EPT wouldn't work.
> >
> > All of the above leads me to think the EPT flag sets as soon as the last
> > transmitted bit is present at the MOSI pin, which effectively empties
> > the shift register, before the following clock edge which is when the
> > slave captures the MOSI pin value. I still might be wrong, as I haven't
> > used EPT ever again, but based on my above observations, I can't
> > conclude anything else. I mean, why the hell wouldn't TI publish the
> > timing diagram of TXEPT or at least include it on the timing diagram of
> > the SPI transfer?
> >
> > I've made drivers for various SPI and SPI-like devices, all using the RX
> > flag, so any new SPI devices I just recycle code from another device.
> > I've not dealt with EPT ever again, I've got some ideas on how to really
> > know when EPT sets, but just haven't got the time right now to test it.
> > It would be as simple as using an external clock source like a
> > (filtered) push button, or a very slow SPI clock, and a couple of leds
> > that permanently show the status of the TX, RX and EPT flags and the
> > MOSI and CLK pins.
> >
> > Best Regards,
> > Michael K.
> >
> > --- In msp430@yahoogroups. com, Matthias Weingart wrote:
> >>
> >> "tintronic" :
> >>
> >> > On the MSP, the USART TX flag doesn't indicate that the transmission
> >> > has finished, it only indicates that the TX buffer is empty. There
> >> > still might be bits in the shift register that are being sent. For
> >> > that matter, neither does TXEPT flag, which indicates that the shift
> >> > register is empty, because it (seams to) sets as soon as the last bit
> >> > in the shift register hits the output pin, which is half a clock
> >> > cycle before the clock edge on which the (spi) slave capturates the
> >> > data bit. So, you need to use the RX flag, which is tricky when you
> >> > try to take advantage of the "double buffering" (one byte for
> >> > shifting out and another one to store the next byte) sending multiple
> >> > bytes in a row. Tricky, because RX falg will set when the second last
> >> > byte written to the TXBUFFER has been received by the slave. And this
> >> > won't work if the function can be interrupted, because you could miss
> >> > an RX flag and the function would get stuck. I guess one could use a
> >> > combination of TXEPT and reading the clock pin value. It should work,
> >> > but I haven't tried it. I any case, I haven't found a single use for
> >> > TXEPT flag. I think I've asked before and gotten no answers, but if
> >> > anyone has an idea of what TXEPT could be used for, please enlighten
> >> > me.
> >>
> >> I might be wrong but I think you are mixing the meaning of two flags.
> >> TXIFG is set once the TXBUF is loaded into the shift register (like
> >> your description) . After that the shift register clocks 8 bits out of
> >> the TXD-Pin and when this is finished the TXEPT is set. For SPI master
> >> TXEPT is set at the same time as RXIFG.
> >> I have used TXEPT to wait until the last character has shifted out
> >> completely. Only after that it is allowed to set LPM3 (because with
> >> LPM3 the UART clock will be stopped also in some cases).
> >>
> >> > I might be wrong, but I think the USCI hasn't this problem, basically
> >> > because it doesn't have a transmit buffer, just a single shift
> >> > register that's used for both transmitting and receiving data, in
> >> > which case probably both Rx and TX flag will work the same in SPI
> >> > master mode.
> >>
> >> No. Just got USCI and DMA working and I have learned that TXIFG is set
> >> when TXBUF is loaded into the shift register, then the 8 bits are
> >> clocked out and (at the same time) 8 bits are clocked in and after that
> >> RXIFG is set.
> >>
> >> In both serial engines (USART and USCI) there are always 2 registers -
> >> one buffer for the character (TXBUF) and the (invisible) shift
> >> register. The transfer from TXBUF to the shift register will wait,
> >> until the shift out has been finished (double buffering).
> >>
> >> M.
> >>
> >
> >
> >
> >
> > ------------ --------- --------- ------
> >
> >
> >
> >
Obviously, you need to wait for the byte to be transferred completely (plus the delay your slave specifies after the last SPI clock edge) before disabling the slave, right? So you can't disable #CS right after writing to the buffer, which means you can't just delete TI_CC_Wait();
Your code only writes one byte, so I'll assume that you're not trying to send more than one byte.
One way do to know if the transmission has finished is by means of the RXIFG. But you have to clear RXIFG by software before sending the byte. Then you write to TX buffer and wait for RXIFG to set, after which you wait for the appropiate time (it might be less than an MSP instruction cycle) and disable #CS.
Did you search this forum? This has been wiiiidely discussed before.
Michael K.
--- In m..., mm bb wrote:
>
> Thanks for the answer , but I want to show you where there is a problem with the spi. Im using the msp430t5438, which has some difference with respect to the other series in employing the flags. I use this routine to send data
>
>
> while (!(UCB0IFG&UCTXIFG)); // USCI_B0 TX buffer ready?
> UCB0TXBUF = value; // Send value
>
> TI_CC_Wait(10); // this should not be here!!!!!!
>
>TI_CC_CSn_PxOUT |= TI_CC_CSn_PIN;// /CS disable
>
> The problem is, if I don'tt use the delay, the clock and data are still running.( I saw in the oscilloscope)
> when the spi is disable by the next instruction. This way it work, but I do not understand where is the problem, I have tried also using the RX flag but it is the same.
> This in place of delay :
> while (!(UCB0IFG&UCRXIFG));
> Any ideas will be welcome, excuse my English#65533;
>
>
>
> ________________________________
> De: Matthias Weingart
> Para: m...
> Enviado: miércoles 1 de abril de 2009, 7:47:59
> Asunto: [msp430] Re: Spi simple question
>
>
> Hi Michael,
>
> I have used TXEPT for RS232 asynchronous transfers only. I think using the
> RXIFG for SPI is a good idea, nothing to say against this. I also use only
> RXIFG for SPI. (In that case you can ignore TXIFG completely.)
>
> M.
>
> "tintronic" :
>
> > Thanks Matthias for answering, as I would like to dig more into this
> > issue. First, I was wrong about the USCI. I was remembering a block
> > diagram which I couldn't find now. USCI does have double buffering. And
> > it has a UCBUSY flag which is much more useful and makes a lot more
> > sense than the TXEPT flag, which by the way USCI doesn't have.
> >
> > On the USART matter, I'm not mixing the flags, I know what each one
> > does. BUT, TI's datasheets don't provide any diagram where you can see
> > TX, RX and EPT flags behaviour concurrently during an SPI transfer.
> > Actually, there is no timing of EPT whatsoever, only a brief description
> > stating that it sets when the shift register is empty, but when exactly
> > is that? That's where the guessing and asumptions start. Making
> > assumptions, that's a receipe for disaster.
> >
> > Have you ever used EPT flag for deselecting the SPI slave? I have done
> > so without luck. So have other people on the forum (many more were
> > wrongly using TX flag). They had to put a delay after EPT or the slave
> > wouldn't recognize the last byte. Even TI's sample codes (CC1100 for
> > example) don't use EPT flag for deselecting the slave on SPI burst
> > writes, instead they use the RX flag. Since I very often use more than
> > one SPI slave on the same bus, my codes always deselect the devices
> > after transfer completion.
> >
> > And yes, I know one has to check the timing parameters of the slave to
> > know how much time after the last SPI clock edge one has to wait before
> > deselecting the device for it to accept the full byte. I have respected
> > all the timing parameters (hell, the time on some devices is shorter
> > than one 8MHz clock cycle) and still I have had to use RX flag because
> > EPT wouldn't work.
> >
> > All of the above leads me to think the EPT flag sets as soon as the last
> > transmitted bit is present at the MOSI pin, which effectively empties
> > the shift register, before the following clock edge which is when the
> > slave captures the MOSI pin value. I still might be wrong, as I haven't
> > used EPT ever again, but based on my above observations, I can't
> > conclude anything else. I mean, why the hell wouldn't TI publish the
> > timing diagram of TXEPT or at least include it on the timing diagram of
> > the SPI transfer?
> >
> > I've made drivers for various SPI and SPI-like devices, all using the RX
> > flag, so any new SPI devices I just recycle code from another device.
> > I've not dealt with EPT ever again, I've got some ideas on how to really
> > know when EPT sets, but just haven't got the time right now to test it.
> > It would be as simple as using an external clock source like a
> > (filtered) push button, or a very slow SPI clock, and a couple of leds
> > that permanently show the status of the TX, RX and EPT flags and the
> > MOSI and CLK pins.
> >
> > Best Regards,
> > Michael K.
> >
> > --- In msp430@yahoogroups. com, Matthias Weingart wrote:
> >>
> >> "tintronic" :
> >>
> >> > On the MSP, the USART TX flag doesn't indicate that the transmission
> >> > has finished, it only indicates that the TX buffer is empty. There
> >> > still might be bits in the shift register that are being sent. For
> >> > that matter, neither does TXEPT flag, which indicates that the shift
> >> > register is empty, because it (seams to) sets as soon as the last bit
> >> > in the shift register hits the output pin, which is half a clock
> >> > cycle before the clock edge on which the (spi) slave capturates the
> >> > data bit. So, you need to use the RX flag, which is tricky when you
> >> > try to take advantage of the "double buffering" (one byte for
> >> > shifting out and another one to store the next byte) sending multiple
> >> > bytes in a row. Tricky, because RX falg will set when the second last
> >> > byte written to the TXBUFFER has been received by the slave. And this
> >> > won't work if the function can be interrupted, because you could miss
> >> > an RX flag and the function would get stuck. I guess one could use a
> >> > combination of TXEPT and reading the clock pin value. It should work,
> >> > but I haven't tried it. I any case, I haven't found a single use for
> >> > TXEPT flag. I think I've asked before and gotten no answers, but if
> >> > anyone has an idea of what TXEPT could be used for, please enlighten
> >> > me.
> >>
> >> I might be wrong but I think you are mixing the meaning of two flags.
> >> TXIFG is set once the TXBUF is loaded into the shift register (like
> >> your description) . After that the shift register clocks 8 bits out of
> >> the TXD-Pin and when this is finished the TXEPT is set. For SPI master
> >> TXEPT is set at the same time as RXIFG.
> >> I have used TXEPT to wait until the last character has shifted out
> >> completely. Only after that it is allowed to set LPM3 (because with
> >> LPM3 the UART clock will be stopped also in some cases).
> >>
> >> > I might be wrong, but I think the USCI hasn't this problem, basically
> >> > because it doesn't have a transmit buffer, just a single shift
> >> > register that's used for both transmitting and receiving data, in
> >> > which case probably both Rx and TX flag will work the same in SPI
> >> > master mode.
> >>
> >> No. Just got USCI and DMA working and I have learned that TXIFG is set
> >> when TXBUF is loaded into the shift register, then the 8 bits are
> >> clocked out and (at the same time) 8 bits are clocked in and after that
> >> RXIFG is set.
> >>
> >> In both serial engines (USART and USCI) there are always 2 registers -
> >> one buffer for the character (TXBUF) and the (invisible) shift
> >> register. The transfer from TXBUF to the shift register will wait,
> >> until the shift out has been finished (double buffering).
> >>
> >> M.
> >>
> >
> >
> >
> >
> > ------------ --------- --------- ------
> >
> >
> >
> >
Reply by ●April 1, 20092009-04-01
I will try to be more clear, but you get the problem, is exactly what you
undestand.
I also try this way
UCB0IFG=0;
UCB0TXBUF = value; // Send value
while (!(UCB0IFG&UCTXIFG)); // USCI_B0 TX buffer ready?
// TI_CC_Wait(10);
TI_CC_CSn_PxOUT |= TI_CC_CSn_PIN; // /CS disable
}
but it does not work, there were four clockpulses losted after the spi was disable if I look for the RX flag and only two lost if I wait for TX .
What Im missing?
In anotherserie f2 we use this scheme and works fine
while (!(IFG2&UCB0RXIFG)); // Wait for TX to finish
IFG2 &= ~UCB0RXIFG; // Clear flag
UCB0TXBUF = value; // Send data
while (!(IFG2&UCB0RXIFG)); // Wait for TX to finish
TI_CC_CSn_PxOUT |= TI_CC_CSn_PIN; // /CS disable
________________________________
De: tintronic
Para: m...
Enviado: micoles 1 de abril de 2009, 13:48:34
Asunto: [msp430] Re: Spi simple question
Ok, I'm not sure what your problem is, either you didn't explain it well or you have no idea what you are doing.
Obviously, you need to wait for the byte to be transferred completely (plus the delay your slave specifies after the last SPI clock edge) before disabling the slave, right? So you can't disable #CS right after writing to the buffer, which means you can't just delete TI_CC_Wait() ;
Your code only writes one byte, so I'll assume that you're not trying to send more than one byte.
One way do to know if the transmission has finished is by means of the RXIFG. But you have to clear RXIFG by software before sending the byte. Then you write to TX buffer and wait for RXIFG to set, after which you wait for the appropiate time (it might be less than an MSP instruction cycle) and disable #CS.
Did you search this forum? This has been wiiiidely discussed before.
Michael K.
--- In msp430@yahoogroups. com, mm bb wrote:
>
> Thanks for the answer , but I want to show you where there is a problem with the spi. Im using the msp430t5438, which has some difference with respect to the other series in employing the flags. I use this routine to send data
>
>
> while (!(UCB0IFG&UCTXIFG) ); // USCI_B0 TX buffer ready?
> UCB0TXBUF = value; // Send value
>
> TI_CC_Wait(10) ; // this should not be here!!!!!!
>
>TI_CC_CSn_PxOUT |= TI_CC_CSn_PIN; // /CS disable
>
> The problem is, if I don'tt use the delay, the clock and data are still running.( I saw in the oscilloscope)
> when the spi is disable by the next instruction. This way it work, but I do not understand where is the problem, I have tried also using the RX flag but it is the same.
> This in place of delay :
> while (!(UCB0IFG&UCRXIFG) );
> Any ideas will be welcome, excuse my English#65533;
>
>
>
> ____________ _________ _________ __
> De: Matthias Weingart
> Para: msp430@yahoogroups. com
> Enviado: miércoles 1 de abril de 2009, 7:47:59
> Asunto: [msp430] Re: Spi simple question
>
>
> Hi Michael,
>
> I have used TXEPT for RS232 asynchronous transfers only. I think using the
> RXIFG for SPI is a good idea, nothing to say against this. I also use only
> RXIFG for SPI. (In that case you can ignore TXIFG completely.)
>
> M.
>
> "tintronic" :
>
> > Thanks Matthias for answering, as I would like to dig more into this
> > issue. First, I was wrong about the USCI. I was remembering a block
> > diagram which I couldn't find now. USCI does have double buffering. And
> > it has a UCBUSY flag which is much more useful and makes a lot more
> > sense than the TXEPT flag, which by the way USCI doesn't have.
> >
> > On the USART matter, I'm not mixing the flags, I know what each one
> > does. BUT, TI's datasheets don't provide any diagram where you can see
> > TX, RX and EPT flags behaviour concurrently during an SPI transfer.
> > Actually, there is no timing of EPT whatsoever, only a brief description
> > stating that it sets when the shift register is empty, but when exactly
> > is that? That's where the guessing and asumptions start. Making
> > assumptions, that's a receipe for disaster.
> >
> > Have you ever used EPT flag for deselecting the SPI slave? I have done
> > so without luck. So have other people on the forum (many more were
> > wrongly using TX flag). They had to put a delay after EPT or the slave
> > wouldn't recognize the last byte. Even TI's sample codes (CC1100 for
> > example) don't use EPT flag for deselecting the slave on SPI burst
> > writes, instead they use the RX flag. Since I very often use more than
> > one SPI slave on the same bus, my codes always deselect the devices
> > after transfer completion.
> >
> > And yes, I know one has to check the timing parameters of the slave to
> > know how much time after the last SPI clock edge one has to wait before
> > deselecting the device for it to accept the full byte. I have respected
> > all the timing parameters (hell, the time on some devices is shorter
> > than one 8MHz clock cycle) and still I have had to use RX flag because
> > EPT wouldn't work.
> >
> > All of the above leads me to think the EPT flag sets as soon as the last
> > transmitted bit is present at the MOSI pin, which effectively empties
> > the shift register, before the following clock edge which is when the
> > slave captures the MOSI pin value. I still might be wrong, as I haven't
> > used EPT ever again, but based on my above observations, I can't
> > conclude anything else. I mean, why the hell wouldn't TI publish the
> > timing diagram of TXEPT or at least include it on the timing diagram of
> > the SPI transfer?
> >
> > I've made drivers for various SPI and SPI-like devices, all using the RX
> > flag, so any new SPI devices I just recycle code from another device.
> > I've not dealt with EPT ever again, I've got some ideas on how to really
> > know when EPT sets, but just haven't got the time right now to test it.
> > It would be as simple as using an external clock source like a
> > (filtered) push button, or a very slow SPI clock, and a couple of leds
> > that permanently show the status of the TX, RX and EPT flags and the
> > MOSI and CLK pins.
> >
> > Best Regards,
> > Michael K.
> >
> > --- In msp430@yahoogroups. com, Matthias Weingart wrote:
> >>
> >> "tintronic" :
> >>
> >> > On the MSP, the USART TX flag doesn't indicate that the transmission
> >> > has finished, it only indicates that the TX buffer is empty. There
> >> > still might be bits in the shift register that are being sent. For
> >> > that matter, neither does TXEPT flag, which indicates that the shift
> >> > register is empty, because it (seams to) sets as soon as the last bit
> >> > in the shift register hits the output pin, which is half a clock
> >> > cycle before the clock edge on which the (spi) slave capturates the
> >> > data bit. So, you need to use the RX flag, which is tricky when you
> >> > try to take advantage of the "double buffering" (one byte for
> >> > shifting out and another one to store the next byte) sending multiple
> >> > bytes in a row. Tricky, because RX falg will set when the second last
> >> > byte written to the TXBUFFER has been received by the slave. And this
> >> > won't work if the function can be interrupted, because you could miss
> >> > an RX flag and the function would get stuck. I guess one could use a
> >> > combination of TXEPT and reading the clock pin value. It should work,
> >> > but I haven't tried it. I any case, I haven't found a single use for
> >> > TXEPT flag. I think I've asked before and gotten no answers, but if
> >> > anyone has an idea of what TXEPT could be used for, please enlighten
> >> > me.
> >>
> >> I might be wrong but I think you are mixing the meaning of two flags.
> >> TXIFG is set once the TXBUF is loaded into the shift register (like
> >> your description) . After that the shift register clocks 8 bits out of
> >> the TXD-Pin and when this is finished the TXEPT is set. For SPI master
> >> TXEPT is set at the same time as RXIFG.
> >> I have used TXEPT to wait until the last character has shifted out
> >> completely. Only after that it is allowed to set LPM3 (because with
> >> LPM3 the UART clock will be stopped also in some cases).
> >>
> >> > I might be wrong, but I think the USCI hasn't this problem, basically
> >> > because it doesn't have a transmit buffer, just a single shift
> >> > register that's used for both transmitting and receiving data, in
> >> > which case probably both Rx and TX flag will work the same in SPI
> >> > master mode.
> >>
> >> No. Just got USCI and DMA working and I have learned that TXIFG is set
> >> when TXBUF is loaded into the shift register, then the 8 bits are
> >> clocked out and (at the same time) 8 bits are clocked in and after that
> >> RXIFG is set.
> >>
> >> In both serial engines (USART and USCI) there are always 2 registers -
> >> one buffer for the character (TXBUF) and the (invisible) shift
> >> register. The transfer from TXBUF to the shift register will wait,
> >> until the shift out has been finished (double buffering).
> >>
> >> M.
> >>
> >
> >
> >
> >
> > ------------ --------- --------- ------
> >
> >
> >
> >
I also try this way
UCB0IFG=0;
UCB0TXBUF = value; // Send value
while (!(UCB0IFG&UCTXIFG)); // USCI_B0 TX buffer ready?
// TI_CC_Wait(10);
TI_CC_CSn_PxOUT |= TI_CC_CSn_PIN; // /CS disable
}
but it does not work, there were four clockpulses losted after the spi was disable if I look for the RX flag and only two lost if I wait for TX .
What Im missing?
In anotherserie f2 we use this scheme and works fine
while (!(IFG2&UCB0RXIFG)); // Wait for TX to finish
IFG2 &= ~UCB0RXIFG; // Clear flag
UCB0TXBUF = value; // Send data
while (!(IFG2&UCB0RXIFG)); // Wait for TX to finish
TI_CC_CSn_PxOUT |= TI_CC_CSn_PIN; // /CS disable
________________________________
De: tintronic
Para: m...
Enviado: micoles 1 de abril de 2009, 13:48:34
Asunto: [msp430] Re: Spi simple question
Ok, I'm not sure what your problem is, either you didn't explain it well or you have no idea what you are doing.
Obviously, you need to wait for the byte to be transferred completely (plus the delay your slave specifies after the last SPI clock edge) before disabling the slave, right? So you can't disable #CS right after writing to the buffer, which means you can't just delete TI_CC_Wait() ;
Your code only writes one byte, so I'll assume that you're not trying to send more than one byte.
One way do to know if the transmission has finished is by means of the RXIFG. But you have to clear RXIFG by software before sending the byte. Then you write to TX buffer and wait for RXIFG to set, after which you wait for the appropiate time (it might be less than an MSP instruction cycle) and disable #CS.
Did you search this forum? This has been wiiiidely discussed before.
Michael K.
--- In msp430@yahoogroups. com, mm bb wrote:
>
> Thanks for the answer , but I want to show you where there is a problem with the spi. Im using the msp430t5438, which has some difference with respect to the other series in employing the flags. I use this routine to send data
>
>
> while (!(UCB0IFG&UCTXIFG) ); // USCI_B0 TX buffer ready?
> UCB0TXBUF = value; // Send value
>
> TI_CC_Wait(10) ; // this should not be here!!!!!!
>
>TI_CC_CSn_PxOUT |= TI_CC_CSn_PIN; // /CS disable
>
> The problem is, if I don'tt use the delay, the clock and data are still running.( I saw in the oscilloscope)
> when the spi is disable by the next instruction. This way it work, but I do not understand where is the problem, I have tried also using the RX flag but it is the same.
> This in place of delay :
> while (!(UCB0IFG&UCRXIFG) );
> Any ideas will be welcome, excuse my English#65533;
>
>
>
> ____________ _________ _________ __
> De: Matthias Weingart
> Para: msp430@yahoogroups. com
> Enviado: miércoles 1 de abril de 2009, 7:47:59
> Asunto: [msp430] Re: Spi simple question
>
>
> Hi Michael,
>
> I have used TXEPT for RS232 asynchronous transfers only. I think using the
> RXIFG for SPI is a good idea, nothing to say against this. I also use only
> RXIFG for SPI. (In that case you can ignore TXIFG completely.)
>
> M.
>
> "tintronic" :
>
> > Thanks Matthias for answering, as I would like to dig more into this
> > issue. First, I was wrong about the USCI. I was remembering a block
> > diagram which I couldn't find now. USCI does have double buffering. And
> > it has a UCBUSY flag which is much more useful and makes a lot more
> > sense than the TXEPT flag, which by the way USCI doesn't have.
> >
> > On the USART matter, I'm not mixing the flags, I know what each one
> > does. BUT, TI's datasheets don't provide any diagram where you can see
> > TX, RX and EPT flags behaviour concurrently during an SPI transfer.
> > Actually, there is no timing of EPT whatsoever, only a brief description
> > stating that it sets when the shift register is empty, but when exactly
> > is that? That's where the guessing and asumptions start. Making
> > assumptions, that's a receipe for disaster.
> >
> > Have you ever used EPT flag for deselecting the SPI slave? I have done
> > so without luck. So have other people on the forum (many more were
> > wrongly using TX flag). They had to put a delay after EPT or the slave
> > wouldn't recognize the last byte. Even TI's sample codes (CC1100 for
> > example) don't use EPT flag for deselecting the slave on SPI burst
> > writes, instead they use the RX flag. Since I very often use more than
> > one SPI slave on the same bus, my codes always deselect the devices
> > after transfer completion.
> >
> > And yes, I know one has to check the timing parameters of the slave to
> > know how much time after the last SPI clock edge one has to wait before
> > deselecting the device for it to accept the full byte. I have respected
> > all the timing parameters (hell, the time on some devices is shorter
> > than one 8MHz clock cycle) and still I have had to use RX flag because
> > EPT wouldn't work.
> >
> > All of the above leads me to think the EPT flag sets as soon as the last
> > transmitted bit is present at the MOSI pin, which effectively empties
> > the shift register, before the following clock edge which is when the
> > slave captures the MOSI pin value. I still might be wrong, as I haven't
> > used EPT ever again, but based on my above observations, I can't
> > conclude anything else. I mean, why the hell wouldn't TI publish the
> > timing diagram of TXEPT or at least include it on the timing diagram of
> > the SPI transfer?
> >
> > I've made drivers for various SPI and SPI-like devices, all using the RX
> > flag, so any new SPI devices I just recycle code from another device.
> > I've not dealt with EPT ever again, I've got some ideas on how to really
> > know when EPT sets, but just haven't got the time right now to test it.
> > It would be as simple as using an external clock source like a
> > (filtered) push button, or a very slow SPI clock, and a couple of leds
> > that permanently show the status of the TX, RX and EPT flags and the
> > MOSI and CLK pins.
> >
> > Best Regards,
> > Michael K.
> >
> > --- In msp430@yahoogroups. com, Matthias Weingart wrote:
> >>
> >> "tintronic" :
> >>
> >> > On the MSP, the USART TX flag doesn't indicate that the transmission
> >> > has finished, it only indicates that the TX buffer is empty. There
> >> > still might be bits in the shift register that are being sent. For
> >> > that matter, neither does TXEPT flag, which indicates that the shift
> >> > register is empty, because it (seams to) sets as soon as the last bit
> >> > in the shift register hits the output pin, which is half a clock
> >> > cycle before the clock edge on which the (spi) slave capturates the
> >> > data bit. So, you need to use the RX flag, which is tricky when you
> >> > try to take advantage of the "double buffering" (one byte for
> >> > shifting out and another one to store the next byte) sending multiple
> >> > bytes in a row. Tricky, because RX falg will set when the second last
> >> > byte written to the TXBUFFER has been received by the slave. And this
> >> > won't work if the function can be interrupted, because you could miss
> >> > an RX flag and the function would get stuck. I guess one could use a
> >> > combination of TXEPT and reading the clock pin value. It should work,
> >> > but I haven't tried it. I any case, I haven't found a single use for
> >> > TXEPT flag. I think I've asked before and gotten no answers, but if
> >> > anyone has an idea of what TXEPT could be used for, please enlighten
> >> > me.
> >>
> >> I might be wrong but I think you are mixing the meaning of two flags.
> >> TXIFG is set once the TXBUF is loaded into the shift register (like
> >> your description) . After that the shift register clocks 8 bits out of
> >> the TXD-Pin and when this is finished the TXEPT is set. For SPI master
> >> TXEPT is set at the same time as RXIFG.
> >> I have used TXEPT to wait until the last character has shifted out
> >> completely. Only after that it is allowed to set LPM3 (because with
> >> LPM3 the UART clock will be stopped also in some cases).
> >>
> >> > I might be wrong, but I think the USCI hasn't this problem, basically
> >> > because it doesn't have a transmit buffer, just a single shift
> >> > register that's used for both transmitting and receiving data, in
> >> > which case probably both Rx and TX flag will work the same in SPI
> >> > master mode.
> >>
> >> No. Just got USCI and DMA working and I have learned that TXIFG is set
> >> when TXBUF is loaded into the shift register, then the 8 bits are
> >> clocked out and (at the same time) 8 bits are clocked in and after that
> >> RXIFG is set.
> >>
> >> In both serial engines (USART and USCI) there are always 2 registers -
> >> one buffer for the character (TXBUF) and the (invisible) shift
> >> register. The transfer from TXBUF to the shift register will wait,
> >> until the shift out has been finished (double buffering).
> >>
> >> M.
> >>
> >
> >
> >
> >
> > ------------ --------- --------- ------
> >
> >
> >
> >
Reply by ●April 1, 20092009-04-01
The first problem is it seams you don't understand what the TX flag
indicates:
0: means the TX buffer is full
1: means the TX buffer is empty. There may still be data in the shift register.
You need to check for the RX flag to know if the byte transmission has finished, not the TX flag. But that will only work for 1 byte.
The TX falg goes from 0 to 1 when the byte is transferred to the shift register. After that the SPI clock starts and the byte is shifted out. You are deselecting the slave right after the shift register has been loaded with the byte from TXBUF and is starting to be shifted out.
Seriously, changing RX for TX and hoping it will somehow work is not the answer.
I think the problem is that you're not posting the complete routine. Since RX should have worked, I'm guessing a transfer is already in progress when you write 'value' into UCBOTXBUF. So, when you see UCRXIFG going up to one, it is because the previous byte has been sent and not the last one. Try the following, just to see if that is the reason. And please don't ever use register=0 to clear a single flag, or else you're asking for headaches.
* while (!(UCB0STAT&UCBUSY));
* UCB0IFG &= ~UCRXIFG;
> UCB0TXBUF = value; // Send value
> while (!(UCB0IFG&UCRXIFG)); // USCI_B0 TX buffer ready?
>
> // TI_CC_Wait(10);
> TI_CC_CSn_PxOUT |= TI_CC_CSn_PIN; // /CS disable
But anyway, you're using the USCI module, right? The why don't you use the UCBUSY flag to know when the SPI has finished all transmissions? That is what you should look at before deselecting #CS.
The RX flag is only used in the USART module because there is no flag that indicates if the SPI has finished transmission (TXEPT flag seams to have been a failed attempt at that).
Let us know how it goes.
Michael K.
--- In m..., mm bb wrote:
>
> I will try to be more clear, but you get the problem, is exactly what you undestand.
> I also try this way
>
> UCB0IFG=0;
> UCB0TXBUF = value; // Send value
> while (!(UCB0IFG&UCTXIFG)); // USCI_B0 TX buffer ready?
>
> // TI_CC_Wait(10);
> TI_CC_CSn_PxOUT |= TI_CC_CSn_PIN; // /CS disable
> }
>
> but it does not work, there were four clockpulses losted after the spi was disable if I look for the RX flag and only two lost if I wait for TX .
> What Im missing?
>
> In anotherserie f2 we use this scheme and works fine
>
> while (!(IFG2&UCB0RXIFG)); // Wait for TX to finish
> IFG2 &= ~UCB0RXIFG; // Clear flag
> UCB0TXBUF = value; // Send data
> while (!(IFG2&UCB0RXIFG)); // Wait for TX to finish
>
> TI_CC_CSn_PxOUT |= TI_CC_CSn_PIN; // /CS disable
>
>
>
>
>
> ________________________________
> De: tintronic
> Para: m...
> Enviado: micoles 1 de abril de 2009, 13:48:34
> Asunto: [msp430] Re: Spi simple question
>
>
> Ok, I'm not sure what your problem is, either you didn't explain it well or you have no idea what you are doing.
> Obviously, you need to wait for the byte to be transferred completely (plus the delay your slave specifies after the last SPI clock edge) before disabling the slave, right? So you can't disable #CS right after writing to the buffer, which means you can't just delete TI_CC_Wait() ;
>
> Your code only writes one byte, so I'll assume that you're not trying to send more than one byte.
> One way do to know if the transmission has finished is by means of the RXIFG. But you have to clear RXIFG by software before sending the byte. Then you write to TX buffer and wait for RXIFG to set, after which you wait for the appropiate time (it might be less than an MSP instruction cycle) and disable #CS.
>
> Did you search this forum? This has been wiiiidely discussed before.
>
> Michael K.
>
> --- In msp430@yahoogroups. com, mm bb wrote:
> >
> > Thanks for the answer , but I want to show you where there is a problem with the spi. Im using the msp430t5438, which has some difference with respect to the other series in employing the flags. I use this routine to send data
> >
> >
> > while (!(UCB0IFG&UCTXIFG) ); // USCI_B0 TX buffer ready?
> > UCB0TXBUF = value; // Send value
> >
> > TI_CC_Wait(10) ; // this should not be here!!!!!!
> >
> >TI_CC_CSn_PxOUT |= TI_CC_CSn_PIN; // /CS disable
> >
> > The problem is, if I don'tt use the delay, the clock and data are still running.( I saw in the oscilloscope)
> > when the spi is disable by the next instruction. This way it work, but I do not understand where is the problem, I have tried also using the RX flag but it is the same.
> > This in place of delay :
> > while (!(UCB0IFG&UCRXIFG) );
> > Any ideas will be welcome, excuse my English#65533;
> >
> >
> >
> > ____________ _________ _________ __
> > De: Matthias Weingart
> > Para: msp430@yahoogroups. com
> > Enviado: miércoles 1 de abril de 2009, 7:47:59
> > Asunto: [msp430] Re: Spi simple question
> >
> >
> > Hi Michael,
> >
> > I have used TXEPT for RS232 asynchronous transfers only. I think using the
> > RXIFG for SPI is a good idea, nothing to say against this. I also use only
> > RXIFG for SPI. (In that case you can ignore TXIFG completely.)
> >
> > M.
> >
> > "tintronic" :
> >
> > > Thanks Matthias for answering, as I would like to dig more into this
> > > issue. First, I was wrong about the USCI. I was remembering a block
> > > diagram which I couldn't find now. USCI does have double buffering. And
> > > it has a UCBUSY flag which is much more useful and makes a lot more
> > > sense than the TXEPT flag, which by the way USCI doesn't have.
> > >
> > > On the USART matter, I'm not mixing the flags, I know what each one
> > > does. BUT, TI's datasheets don't provide any diagram where you can see
> > > TX, RX and EPT flags behaviour concurrently during an SPI transfer.
> > > Actually, there is no timing of EPT whatsoever, only a brief description
> > > stating that it sets when the shift register is empty, but when exactly
> > > is that? That's where the guessing and asumptions start. Making
> > > assumptions, that's a receipe for disaster.
> > >
> > > Have you ever used EPT flag for deselecting the SPI slave? I have done
> > > so without luck. So have other people on the forum (many more were
> > > wrongly using TX flag). They had to put a delay after EPT or the slave
> > > wouldn't recognize the last byte. Even TI's sample codes (CC1100 for
> > > example) don't use EPT flag for deselecting the slave on SPI burst
> > > writes, instead they use the RX flag. Since I very often use more than
> > > one SPI slave on the same bus, my codes always deselect the devices
> > > after transfer completion.
> > >
> > > And yes, I know one has to check the timing parameters of the slave to
> > > know how much time after the last SPI clock edge one has to wait before
> > > deselecting the device for it to accept the full byte. I have respected
> > > all the timing parameters (hell, the time on some devices is shorter
> > > than one 8MHz clock cycle) and still I have had to use RX flag because
> > > EPT wouldn't work.
> > >
> > > All of the above leads me to think the EPT flag sets as soon as the last
> > > transmitted bit is present at the MOSI pin, which effectively empties
> > > the shift register, before the following clock edge which is when the
> > > slave captures the MOSI pin value. I still might be wrong, as I haven't
> > > used EPT ever again, but based on my above observations, I can't
> > > conclude anything else. I mean, why the hell wouldn't TI publish the
> > > timing diagram of TXEPT or at least include it on the timing diagram of
> > > the SPI transfer?
> > >
> > > I've made drivers for various SPI and SPI-like devices, all using the RX
> > > flag, so any new SPI devices I just recycle code from another device.
> > > I've not dealt with EPT ever again, I've got some ideas on how to really
> > > know when EPT sets, but just haven't got the time right now to test it.
> > > It would be as simple as using an external clock source like a
> > > (filtered) push button, or a very slow SPI clock, and a couple of leds
> > > that permanently show the status of the TX, RX and EPT flags and the
> > > MOSI and CLK pins.
> > >
> > > Best Regards,
> > > Michael K.
> > >
> > > --- In msp430@yahoogroups. com, Matthias Weingart wrote:
> > >>
> > >> "tintronic" :
> > >>
> > >> > On the MSP, the USART TX flag doesn't indicate that the transmission
> > >> > has finished, it only indicates that the TX buffer is empty. There
> > >> > still might be bits in the shift register that are being sent. For
> > >> > that matter, neither does TXEPT flag, which indicates that the shift
> > >> > register is empty, because it (seams to) sets as soon as the last bit
> > >> > in the shift register hits the output pin, which is half a clock
> > >> > cycle before the clock edge on which the (spi) slave capturates the
> > >> > data bit. So, you need to use the RX flag, which is tricky when you
> > >> > try to take advantage of the "double buffering" (one byte for
> > >> > shifting out and another one to store the next byte) sending multiple
> > >> > bytes in a row. Tricky, because RX falg will set when the second last
> > >> > byte written to the TXBUFFER has been received by the slave. And this
> > >> > won't work if the function can be interrupted, because you could miss
> > >> > an RX flag and the function would get stuck. I guess one could use a
> > >> > combination of TXEPT and reading the clock pin value. It should work,
> > >> > but I haven't tried it. I any case, I haven't found a single use for
> > >> > TXEPT flag. I think I've asked before and gotten no answers, but if
> > >> > anyone has an idea of what TXEPT could be used for, please enlighten
> > >> > me.
> > >>
> > >> I might be wrong but I think you are mixing the meaning of two flags.
> > >> TXIFG is set once the TXBUF is loaded into the shift register (like
> > >> your description) . After that the shift register clocks 8 bits out of
> > >> the TXD-Pin and when this is finished the TXEPT is set. For SPI master
> > >> TXEPT is set at the same time as RXIFG.
> > >> I have used TXEPT to wait until the last character has shifted out
> > >> completely. Only after that it is allowed to set LPM3 (because with
> > >> LPM3 the UART clock will be stopped also in some cases).
> > >>
> > >> > I might be wrong, but I think the USCI hasn't this problem, basically
> > >> > because it doesn't have a transmit buffer, just a single shift
> > >> > register that's used for both transmitting and receiving data, in
> > >> > which case probably both Rx and TX flag will work the same in SPI
> > >> > master mode.
> > >>
> > >> No. Just got USCI and DMA working and I have learned that TXIFG is set
> > >> when TXBUF is loaded into the shift register, then the 8 bits are
> > >> clocked out and (at the same time) 8 bits are clocked in and after that
> > >> RXIFG is set.
> > >>
> > >> In both serial engines (USART and USCI) there are always 2 registers -
> > >> one buffer for the character (TXBUF) and the (invisible) shift
> > >> register. The transfer from TXBUF to the shift register will wait,
> > >> until the shift out has been finished (double buffering).
> > >>
> > >> M.
> > >>
> > >
> > >
> > >
> > >
> > > ------------ --------- --------- ------
> > >
> > >
> > >
> > >
0: means the TX buffer is full
1: means the TX buffer is empty. There may still be data in the shift register.
You need to check for the RX flag to know if the byte transmission has finished, not the TX flag. But that will only work for 1 byte.
The TX falg goes from 0 to 1 when the byte is transferred to the shift register. After that the SPI clock starts and the byte is shifted out. You are deselecting the slave right after the shift register has been loaded with the byte from TXBUF and is starting to be shifted out.
Seriously, changing RX for TX and hoping it will somehow work is not the answer.
I think the problem is that you're not posting the complete routine. Since RX should have worked, I'm guessing a transfer is already in progress when you write 'value' into UCBOTXBUF. So, when you see UCRXIFG going up to one, it is because the previous byte has been sent and not the last one. Try the following, just to see if that is the reason. And please don't ever use register=0 to clear a single flag, or else you're asking for headaches.
* while (!(UCB0STAT&UCBUSY));
* UCB0IFG &= ~UCRXIFG;
> UCB0TXBUF = value; // Send value
> while (!(UCB0IFG&UCRXIFG)); // USCI_B0 TX buffer ready?
>
> // TI_CC_Wait(10);
> TI_CC_CSn_PxOUT |= TI_CC_CSn_PIN; // /CS disable
But anyway, you're using the USCI module, right? The why don't you use the UCBUSY flag to know when the SPI has finished all transmissions? That is what you should look at before deselecting #CS.
The RX flag is only used in the USART module because there is no flag that indicates if the SPI has finished transmission (TXEPT flag seams to have been a failed attempt at that).
Let us know how it goes.
Michael K.
--- In m..., mm bb wrote:
>
> I will try to be more clear, but you get the problem, is exactly what you undestand.
> I also try this way
>
> UCB0IFG=0;
> UCB0TXBUF = value; // Send value
> while (!(UCB0IFG&UCTXIFG)); // USCI_B0 TX buffer ready?
>
> // TI_CC_Wait(10);
> TI_CC_CSn_PxOUT |= TI_CC_CSn_PIN; // /CS disable
> }
>
> but it does not work, there were four clockpulses losted after the spi was disable if I look for the RX flag and only two lost if I wait for TX .
> What Im missing?
>
> In anotherserie f2 we use this scheme and works fine
>
> while (!(IFG2&UCB0RXIFG)); // Wait for TX to finish
> IFG2 &= ~UCB0RXIFG; // Clear flag
> UCB0TXBUF = value; // Send data
> while (!(IFG2&UCB0RXIFG)); // Wait for TX to finish
>
> TI_CC_CSn_PxOUT |= TI_CC_CSn_PIN; // /CS disable
>
>
>
>
>
> ________________________________
> De: tintronic
> Para: m...
> Enviado: micoles 1 de abril de 2009, 13:48:34
> Asunto: [msp430] Re: Spi simple question
>
>
> Ok, I'm not sure what your problem is, either you didn't explain it well or you have no idea what you are doing.
> Obviously, you need to wait for the byte to be transferred completely (plus the delay your slave specifies after the last SPI clock edge) before disabling the slave, right? So you can't disable #CS right after writing to the buffer, which means you can't just delete TI_CC_Wait() ;
>
> Your code only writes one byte, so I'll assume that you're not trying to send more than one byte.
> One way do to know if the transmission has finished is by means of the RXIFG. But you have to clear RXIFG by software before sending the byte. Then you write to TX buffer and wait for RXIFG to set, after which you wait for the appropiate time (it might be less than an MSP instruction cycle) and disable #CS.
>
> Did you search this forum? This has been wiiiidely discussed before.
>
> Michael K.
>
> --- In msp430@yahoogroups. com, mm bb wrote:
> >
> > Thanks for the answer , but I want to show you where there is a problem with the spi. Im using the msp430t5438, which has some difference with respect to the other series in employing the flags. I use this routine to send data
> >
> >
> > while (!(UCB0IFG&UCTXIFG) ); // USCI_B0 TX buffer ready?
> > UCB0TXBUF = value; // Send value
> >
> > TI_CC_Wait(10) ; // this should not be here!!!!!!
> >
> >TI_CC_CSn_PxOUT |= TI_CC_CSn_PIN; // /CS disable
> >
> > The problem is, if I don'tt use the delay, the clock and data are still running.( I saw in the oscilloscope)
> > when the spi is disable by the next instruction. This way it work, but I do not understand where is the problem, I have tried also using the RX flag but it is the same.
> > This in place of delay :
> > while (!(UCB0IFG&UCRXIFG) );
> > Any ideas will be welcome, excuse my English#65533;
> >
> >
> >
> > ____________ _________ _________ __
> > De: Matthias Weingart
> > Para: msp430@yahoogroups. com
> > Enviado: miércoles 1 de abril de 2009, 7:47:59
> > Asunto: [msp430] Re: Spi simple question
> >
> >
> > Hi Michael,
> >
> > I have used TXEPT for RS232 asynchronous transfers only. I think using the
> > RXIFG for SPI is a good idea, nothing to say against this. I also use only
> > RXIFG for SPI. (In that case you can ignore TXIFG completely.)
> >
> > M.
> >
> > "tintronic" :
> >
> > > Thanks Matthias for answering, as I would like to dig more into this
> > > issue. First, I was wrong about the USCI. I was remembering a block
> > > diagram which I couldn't find now. USCI does have double buffering. And
> > > it has a UCBUSY flag which is much more useful and makes a lot more
> > > sense than the TXEPT flag, which by the way USCI doesn't have.
> > >
> > > On the USART matter, I'm not mixing the flags, I know what each one
> > > does. BUT, TI's datasheets don't provide any diagram where you can see
> > > TX, RX and EPT flags behaviour concurrently during an SPI transfer.
> > > Actually, there is no timing of EPT whatsoever, only a brief description
> > > stating that it sets when the shift register is empty, but when exactly
> > > is that? That's where the guessing and asumptions start. Making
> > > assumptions, that's a receipe for disaster.
> > >
> > > Have you ever used EPT flag for deselecting the SPI slave? I have done
> > > so without luck. So have other people on the forum (many more were
> > > wrongly using TX flag). They had to put a delay after EPT or the slave
> > > wouldn't recognize the last byte. Even TI's sample codes (CC1100 for
> > > example) don't use EPT flag for deselecting the slave on SPI burst
> > > writes, instead they use the RX flag. Since I very often use more than
> > > one SPI slave on the same bus, my codes always deselect the devices
> > > after transfer completion.
> > >
> > > And yes, I know one has to check the timing parameters of the slave to
> > > know how much time after the last SPI clock edge one has to wait before
> > > deselecting the device for it to accept the full byte. I have respected
> > > all the timing parameters (hell, the time on some devices is shorter
> > > than one 8MHz clock cycle) and still I have had to use RX flag because
> > > EPT wouldn't work.
> > >
> > > All of the above leads me to think the EPT flag sets as soon as the last
> > > transmitted bit is present at the MOSI pin, which effectively empties
> > > the shift register, before the following clock edge which is when the
> > > slave captures the MOSI pin value. I still might be wrong, as I haven't
> > > used EPT ever again, but based on my above observations, I can't
> > > conclude anything else. I mean, why the hell wouldn't TI publish the
> > > timing diagram of TXEPT or at least include it on the timing diagram of
> > > the SPI transfer?
> > >
> > > I've made drivers for various SPI and SPI-like devices, all using the RX
> > > flag, so any new SPI devices I just recycle code from another device.
> > > I've not dealt with EPT ever again, I've got some ideas on how to really
> > > know when EPT sets, but just haven't got the time right now to test it.
> > > It would be as simple as using an external clock source like a
> > > (filtered) push button, or a very slow SPI clock, and a couple of leds
> > > that permanently show the status of the TX, RX and EPT flags and the
> > > MOSI and CLK pins.
> > >
> > > Best Regards,
> > > Michael K.
> > >
> > > --- In msp430@yahoogroups. com, Matthias Weingart wrote:
> > >>
> > >> "tintronic" :
> > >>
> > >> > On the MSP, the USART TX flag doesn't indicate that the transmission
> > >> > has finished, it only indicates that the TX buffer is empty. There
> > >> > still might be bits in the shift register that are being sent. For
> > >> > that matter, neither does TXEPT flag, which indicates that the shift
> > >> > register is empty, because it (seams to) sets as soon as the last bit
> > >> > in the shift register hits the output pin, which is half a clock
> > >> > cycle before the clock edge on which the (spi) slave capturates the
> > >> > data bit. So, you need to use the RX flag, which is tricky when you
> > >> > try to take advantage of the "double buffering" (one byte for
> > >> > shifting out and another one to store the next byte) sending multiple
> > >> > bytes in a row. Tricky, because RX falg will set when the second last
> > >> > byte written to the TXBUFFER has been received by the slave. And this
> > >> > won't work if the function can be interrupted, because you could miss
> > >> > an RX flag and the function would get stuck. I guess one could use a
> > >> > combination of TXEPT and reading the clock pin value. It should work,
> > >> > but I haven't tried it. I any case, I haven't found a single use for
> > >> > TXEPT flag. I think I've asked before and gotten no answers, but if
> > >> > anyone has an idea of what TXEPT could be used for, please enlighten
> > >> > me.
> > >>
> > >> I might be wrong but I think you are mixing the meaning of two flags.
> > >> TXIFG is set once the TXBUF is loaded into the shift register (like
> > >> your description) . After that the shift register clocks 8 bits out of
> > >> the TXD-Pin and when this is finished the TXEPT is set. For SPI master
> > >> TXEPT is set at the same time as RXIFG.
> > >> I have used TXEPT to wait until the last character has shifted out
> > >> completely. Only after that it is allowed to set LPM3 (because with
> > >> LPM3 the UART clock will be stopped also in some cases).
> > >>
> > >> > I might be wrong, but I think the USCI hasn't this problem, basically
> > >> > because it doesn't have a transmit buffer, just a single shift
> > >> > register that's used for both transmitting and receiving data, in
> > >> > which case probably both Rx and TX flag will work the same in SPI
> > >> > master mode.
> > >>
> > >> No. Just got USCI and DMA working and I have learned that TXIFG is set
> > >> when TXBUF is loaded into the shift register, then the 8 bits are
> > >> clocked out and (at the same time) 8 bits are clocked in and after that
> > >> RXIFG is set.
> > >>
> > >> In both serial engines (USART and USCI) there are always 2 registers -
> > >> one buffer for the character (TXBUF) and the (invisible) shift
> > >> register. The transfer from TXBUF to the shift register will wait,
> > >> until the shift out has been finished (double buffering).
> > >>
> > >> M.
> > >>
> > >
> > >
> > >
> > >
> > > ------------ --------- --------- ------
> > >
> > >
> > >
> > >
