This message is from the T13 list server.
You have to seperate commands from bursts. If the 514 bytes were transferred in a burst that is the start of a command (i.e. more bytes to follow), then the device just stores then and appends the follow on bytes in the next burst to them. Reardless, the CRC calculation is always over all of the bytes the sender sent/receiver received, in this case 514 bytes. If the command was for 512 bytes, then the host made an error - it should have known better and stopped at 512. In that case there is a host logic error that the device should detect, since it should have also known the command length (i.e. 512 bytes). Once again, CRC is over the 514 bytes sent, although in this case even with good CRC the command has an error. The windows tradition you are referring to is I think the opposite case - bytes being transferred to the host. In this case the device is the sender, and so is responsible for sending the correct number of bytes. If it screws up, then the host should detect it. Deveices are wel tested n this area, but hosts sometimes are not (i.e. the software counts on the device not screwing up, and does not do an ending count check). Jim -----Original Message----- From: Pat LaVarre [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 04, 2001 11:48 AM To: [EMAIL PROTECTED] Subject: [t13] AtapiUDma design - unexpected data out This message is from the T13 list server. With UDma, vs. Pio, maybe the main thing that is really new & different - and therefore most painful - is that bytes can cross the bus that the device did not request. Suppose a write for 514 bytes goes to a device that in Pio mode would have requested 512 bytes. Suppose the last 2 bytes cross the bus after the device initiates the final terminating pause. We can now look forward to variety in how the device responds. Does the device receive these bytes into a fifo, include them in the Crc, and then quietly discard them? Wrong answer - but maybe popular? Does the device report a Crc error - either artificially or indirectly and not quite perfectly by excluding the bytes from the Crc? But there was no Crc error - all that actually happened was that the sender moved too many bytes. I wonder how often this occurs because I hear Windows has a tradition of ignoring this case, by accident because of a conscious (and wrong-headed) decision to tolerate a sender of data sending too few bytes of data in. Does an Atapi device go "unexpectedly bus free" i.e. clear BSY:DRQ = 0:0 without raising INTRQ or setting C/D I/O = x03 StatusIn? Any interrupt-driven host will see this as a hang. All evil choices, no good choices, yes? What do actual Atapi devices do? Pat LaVarre >>> "Pat LaVarre" <[EMAIL PROTECTED]> 12/04/01 10:36AM >>> ... // The Bottom Line: Standard Atapi UDma DOES count bytes as well as standard Atapi Sw/MwDma. And that's as good as merely standard Atapi Pio for any even total of bytes. Subscribe/Unsubscribe instructions can be found at www.t13.org. Subscribe/Unsubscribe instructions can be found at www.t13.org.
