unhd (Roger Gonzalez ) (01/09/90)
I'm writing a SCSI driver for a optical WORM drive (I know, reinventing the wheel..). My development/test environment is UNIX, and I then download the code to target boards running pSOS. I am using an Ironics IV-3273 System Controller card, which has a NCR-5380 SCSI chip on it. My questions: In the SCSI spec, they say that the target controls the C/D, MSG, and I/O bits. Fine. In this case, why is there a "target control register" on the chip, which in the code examples I have, is used by the initiator to "Assert C/D, I/O, or MSG". Isn't this a contradiction? If it is, how am I supposed to get the bus into (for example) Command phase so that I can send a command to the target? In the spec, they say things like "wait one bus settle delay". Does this kind of picky solder-jockey timing become an issue for me as a programmer? Does this code just lend itself to ugly inelegant programming, or am I just losing my touch? Do you get forced to program like a raw-meat-eating Real Programmer whenever you talk to chips directly? What's up? Thanks, Roger -- UUCP: ..!uunet!unhd!rg | USPS: Marine Systems Engineering Laboratory BITNET: r_gonzalez at unhh | University of New Hampshire PHONE: (603) 862-4600 | 242 SERB FAX: (603) 862-4399 | Durham, NH 03824-3525
wpayne@digi.UUCP (William Payne) (01/12/90)
The 5380 will work in initiator and target roles and can be dynamically used in both roles depending on your system design. -- Later...
chris@mimsy.umd.edu (Chris Torek) (01/13/90)
In article <1990Jan8.180709.3440@uunet!unhd> rg@uunet!unhd (Roger Gonzalez) writes: >In the SCSI spec, they say that the target controls the C/D, MSG, and >I/O bits. Fine. In this case, why is there a "target control register" >on the chip, which in the code examples I have, is used by the initiator >to "Assert C/D, I/O, or MSG". As someone else pointed out, this is because the 5380 can act as either initiator or target. >In the spec, they say things like "wait one bus settle delay". Does >this kind of picky solder-jockey timing become an issue for me as a >programmer? This depends on the chip (and sometimes on the glue logic connecting it to its bus). With cheap hardware, you have to delay in software. This is not so bad if the delays are short. It becomes a real problem when you have to write foodev->foo_csr = FOO_SETUP; DELAY(12000); /* wait ~12 milliseconds */ foodev->foo_csr = FOO_SETUP | FOO_GO; DELAY(1000); /* another millisecond */ foodev->foo_csr = FOO_GO; This is when you wish whoever built the thing had handled the `set up and go' case directly. . . . -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris