Re: One Ultra320 drive and SCSI scanner - Controller?

Folkert Rienstra wrote:

Michael Baeuerle wrote:

Folkert Rienstra wrote:

[...]
A very large image of 2.5MB

??? 2.5MByte is a really small image. If I want to scan a picture of 10cm * 10cm
with 600dpi at 16Bit colour (a photo or something) that results in:

2Byte * (600dpi * 3.94in)^2 = 11MiByte

Let the resulting JPEG files be much smaller, that is the uncompressed
size that must be transferred over the SCSI bus (with no interpolation

Yes, you are correct there, my mistake.
Forgot that JPEGs are usually compressed also.

and without own compression) ...

Which you'll probably use. Have no idea though how much difference that makes.

In theory the scanner can transfer compressed data - if this is no
lossless compression your calculation of the data size would be
acceptable.
But compression require enough local processor ressources to do that
"on-the-fly" or the sensor element must stop in regular intervals.
Additionally most compression algorithms are based on blocks, that mean
you also need additional local RAM to temporarily store them. Finally
the SCSI interface should be faster because the data must be transferred
in bursts to quickly free the memory for the next block.

I assume (but not know) that all the cheap scanners don't compress the
data because the required local hardware ressources would be too
expensive.

[...]
No, even without disconnect/reconnect a SCSI transfer can only be so long
before a new command has to be issued at which time the faster device get's
control again. It's devices that keep the bus longer than necessary without
transferring anything that are ill behaved.

I disagree, the scanner have to place his deadtimes somewhere if it cannot disconnect.

Depends on whether commands are immediate or not, eg for commands that don't trans-
fer data. Unfortunately it doesn't say in the SCSI spec or it depends per scanner.
I'm also not clear on how the various commands -such as position, read and scan-
are used, eg what the difference is between scan and read image.

Ignoring the standard SCSI commands for all device classes there remain
only two mandatory commands for scanners: SET WINDOW and READ. The SCAN
command is optional because some scanners have a button to start
scanning manually. I think all scanners that can work without manual
intervention (as all cheap PC scanners can do) must implement it.

After the selection from the host, the scanner takes control of the SCSI
bus and fetch messages and the command from the host. If it is a command
that requests image data, the scanner must place his sensor element first

That asumes that it is a single command, which I doubt.
So what would the sequence of commands be here?

Good question, I think it may work like this:
- SET WINDOW (define areas to scan)
The parameter list can contain multiple window descriptors.
For each window descriptor:
The "Auto" bit must always be 0 if the GET WINDOW command is not
implemented. The "Window identifier" field is used to distinguish
the windows from each other.
- SCAN (Start scanning of requested areas)
The parameter list contains one or multiple window descriptors.
This command transfers no data to the host (because scanners are
allowed to use a button instead of this optional command).
- READ (Transfer data to the host)
With "Data type code" 0x00 the host can request the scanned image
data. The method of selecting the window if SCAN was used with
multiple window descriptors seems to be vendor specific.

The question is what the scanner should do with the SCAN command if its
local memory is too small to hold the data for at least one window (this
should be the case for all cheap scanners) ...

(which can take several seconds) before it can start data transfer.

If this is the position command and it would be immediate then that would
not be the case.

If disconnect/reselect is not implemented, it _must_not_ release the SCSI
bus within that time.

Unless that command is immediate.

There is no "Immed" bit defined, neither in the window parameter header
nor in the SCAN command (nowhere in the scanner command set to be
precise) ... so I thought that this was not intended. But I agree with
you that this would make sense here because of the memory problem stated
above. Probably it is assumed that the operations should always be
immediate, but there is no note about this (in my SCSI2 draft from
T10.org).

If I should have to implement a scanner firmware I would try it like
this:
- The SET WINDOW command only store the window descriptors but
trigger no mechanical actions.
- The SCAN command only places the sensor element to the start
of the first window and report status GOOD immediately (at
least for scanners without large local memory).
- The first READ command starts the physical scan process.
The data will be transferred over the bus at scan speed, not
interface speed.

It is the same as for a CDROM: Without disconnect the seek time will be
dead bus time.

Sure but CD seek is part of a data request command. It is also possible
to do the seek first and then read the data, thereby skipping the latency.
More over reding data from a CD may be random access (involving many
seeks where data from a scanner is sequential

For the scanner example above, this will only work if the SCAN command
is used with a single window descriptor. If there are multiple windows
in the list (and this is explicit specified to be legal), all further
positioning must be done within the READ commands ... blocking the bus
again.

But you convinced me that it will be feasible because scanners cannot be
used with generic drivers like e.g. disks (there are too much "vendor
specific" things in the spec for this to work). If the scanner cannot
disconnect, the firmware can be implemented as above and the driver can
be written in a way that there is only one active window at any time.
But if I want to use the additional functionality that is specified by
SCSI, I have to implement disconnect/reselect - or accept dead time on
the bus.


Micha
--
http:/micha.freeshell.org
.