8-bit MicrocontrollersのトピックRe: HCS08 SPI Double Buffered Receiver?

HCS08 SPI Double Buffered Receiver?

Sany — Tue, 26 Sep 2006 05:56:03 GMT

Can anyone explain more on this new feature? Or any datasheet explain more about this feature? How can I use this double buffered receiver? Without the overrun flag, I having problem in the transition from HC08 to HCS08. Thank you.

Re: HCS08 SPI Double Buffered Receiver?

Pingu — Fri, 29 Sep 2006 17:52:08 GMT

http://www.freescale.com/files/microcontrollers/doc/app_note/AN2717.pdf

AN2717 may be more helpful than the databook description.

Re: HCS08 SPI Double Buffered Receiver?

bigmac — Sun, 01 Oct 2006 22:05:04 GMT

Hello,

According to AN2717 "M68HC08 to HCS08 Transition", one of the enhancements of the HCS08 SPI is

• The HCS08 has a double-buffered receiver; the M68HC08 does not.

This statement seems to have been made to justify that the overrun flag has been eliminated in the later device.

• The M68HC08 Family has an interruptible error flag for receiver overruns (when a new byte is received before the previous byte has been read). The HCS08 Family has a double-buffered receiver and therefore does not require a flag or interrupt for this condition.

However, AN2717 does not attempt to explain any details, but relies on reference to individual data sheets.

Examination of relevant data sheets leads me to believe that the first statement is misleading, or wrong, with respect to the HC08. I can see little difference between the SPI buffer arrangements of the two devices. The data sheets I have used for comparison are those for the MC9S08QG8 and the MC908QB8.

MC908QB8 -

Paragraph 15.2 refers to "Double-buffered operation with separate transmit and receive registers". This is supported by Fig. 15.2, which shows transmit data register, shift register, and receive data register blocks. This would meet my understanding of the term "double buffering", with the shift register being the primary buffer, and the other registers the secondary buffers.

MC9S08QG8 -

Paragraph 15.1.1 refers to "Double-buffered transmit and receive", and Fig. 15.3 shows Tx buffer, SPI shift register, and Rx buffer blocks. This is remarkably similar to the other device. Of course the Rx buffer might actually be a two-level FIFO (which I would consider to provide "triple-buffering"), but I don't think this is the case. Section 15.4 of the data sheet provides the following explanation -

Because the transmitter and receiver are double buffered, a second byte, in addition to the byte currently being shifted out, can be queued into the transmit data buffer, and a previously received character can be in the receive data buffer while a new character is being shifted in. The SPTEF flag indicates when the transmit buffer has room for a new character. The SPRF flag indicates when a received character is available in the receive data buffer. The received character must be read out of the receive buffer (read SPID) before the next transfer is finished or a receive overrun error results.

In the case of a receive overrun, the new data is lost because the receive buffer still held the previous character and was not ready to accept the new data. There is no indication for such an overrun condition so the application system designer must ensure that previous data has been read from the receive buffer before a new transfer is initiated.

The final paragraph would seem very good advice to prevent receive overrun, and loss of data, for either MCU type, even where an overrun flag is provided. Of course, this will apply to the SPI master only, but would be valid whether polling or using receive interrupt, and for all SPI clock rates. The method of handling a SPI data transaction should not need to differ between the two types, so it would seem.

However, if two bytes ever need to be sequentially loaded into the transmit buffer for any reason, there is potential for the second returned byte to be lost due to receive buffer overrun, unless the following situations can apply -

There is no interest in any returned data - for a send only requirement, or
Use polling of the SPRF flag, rather than interrupt operation, unless the SPI clock rate is very low. If polling is used, mask all interrupts from prior to the second byte entering the transmit buffer, until the first returned byte is read from the receive buffer.
If SPI interrupt operation must be used for the received data, the clock rate would need to be reduced so that the total bus cycles needed to enter the receive ISR, read the receive buffer and clear the interrupt flag, plus the maximum ISR cycles for all other interrupts that may potentially delay processing of the receive interrupt, must not exceed the bus cycles required for the SPI send process for a single byte.

I would be interested to hear if others agree or disagree with my analysis, and whether I have correctly interpreted the data sheet information.

Regards,
Mac

Re: HCS08 SPI Double Buffered Receiver?

rocco — Mon, 02 Oct 2006 03:34:28 GMT

Hi, Mac:

Thanks for the analysis. I thought it was just me.

When I first noticed the "double-buffered" discrepancy, about a year ago, I attributed it to Freescale having forgotten to update the data-sheet. I did not notice the elimination of the overflow flag.

We have not attempted to migrate to any S08 members yet, due to the lack of an ICE, so I have not ported any SPI code. But I know that our code depends on the overflow flag when transaction get hot and heavy.

The double-buffered "enhancement" appears like whitehouse spin for an oversight.

Re: HCS08 SPI Double Buffered Receiver?

peg — Mon, 02 Oct 2006 08:16:25 GMT

Hi,

The HC08 and S08 SPI is essentially the same in this regard.

The first doc quote in blue by Mac shows the writer does not know the product.

(Are there any non double buffered SPI's in HC08's? Because most are.)

The second quote shows that he/she does not have even a basic understanding of the concepts involved.

(I am sure there are lots of people in lots of different communication fields would love to know how adding a one byte buffer eliminates any chance of overrun on a reciever.)

So the facts:

1. There is no double buffer enhancement of the SPI reciever. (It was already there)

2. The lack of reciever overflow is a deficiency in the S08's SPI which is not overcome by any of the improvements.

Regards

David

Re: HCS08 SPI Double Buffered Receiver?

peg — Mon, 02 Oct 2006 18:23:22 GMT

Hi again,

If we go back even further the HC05 (esp C8) has a double buffer on the recieve only and not the transmit side. It also has no recieve overflow.

But it is actually the double buffering of the transmit side that brings about the greater necessity to have a recieve overflow indicator.

Having no tx buffer means that you deal with the SPI "byte at a time" this means you may as well read in the recieved byte straight after you load the next tx byte and you won't ever overflow.

However when you take advantage of the tx double buffer and stack it up this (as Mac pointed out) is when you an get into trouble. You need to read that first recieved byte out before the second last bit of the next one comes in! Of course this is for the master where you have total control, in the slave it is far more important to have the overflow indication.

Regards

David

Re: HCS08 SPI Double Buffered Receiver?

Alban — Mon, 02 Oct 2006 20:30:01 GMT

Hello,

I highlighted this point and the AN2717 is being reviewed as well as the S08QG8 datasheet.
It is possible a mistake from the datasheet propagated to AN2717 as everything is based on the product datasheet.

The Designer of the module might have been over excited by his realisation...

You have the double buffer in Tx as you can write to the data register when a transmission is in progress, but it's not a new feature at all.
About the reception, I don't see where the first data would go and the documentation confirms the user should be aware of buffer over-run.

Having the overflow is not really a solution anyway as the error blocks the transmission and further data is lost.
Without, the transmission can still provide info even if a block is overwritten.
It's really arguable which one is best and really depends on the software designer implementation.
Furthermore buffer overrun is not supposed to happen in a system as if you're not able to deal with the traffic at one point you are likely to get an overflow again and again....
The time spent in the Interrupt Sub-Rouitne is supposed to take into account the throughput of the SPI and other interrupt occurences.

Alban.

Re: HCS08 SPI Double Buffered Receiver?

bigmac — Tue, 03 Oct 2006 00:16:08 GMT

Hello Alban,

I actually didn't see any inconsistency in the S08QG8 data sheet, only within AN2717.

In fact, as you have pointed out, it is the data sheet that suggests that the double Tx buffering should not actually be utilised in order to prevent Rx overrun for the master - and I totally agree, and cannot see any particular operational disadvantage to this limitation. Since a received data byte cannot be held in the SPI shift register without the overrun condition occuring (even though no further byte is sent to overwrite the shift register), the receive process would need to be triple-buffered in order to cope with the double-buffered send, without risk of overrun.

As Peg has already stated, the greatest potential for Rx overrun is for SPI slave operation. When the MCU is required to operate as a slave, the solution to a potential receive overrun problem could be either a slower SPI clock rate from the master, or for the master to allow adequate delay between the sending of consecutive bytes. Another possible solution might be for the slave MCU to provide a "ready" handshake signal to the master MCU, in response to /SS being asserted. While somewhat more complex, this may be the most reliable method when there are lengthy or highly variable ISR processes associated with the slave firmware.

Regards,

Mac