[sane-devel] Re: FW: canon630u's gl640 forked for CanoScan3000 and others?

Bertrik Sikken bertrik@zonnet.nl
Tue, 31 May 2005 20:04:30 +0200


amth@suomi24.fi wrote:
>> --Alkuperäinen viesti-- From: Gerhard Jaeger <gerhard@gjaeger.de>
>> To: amth@suomi24.fi, sane-devel@lists.alioth.debian.org Subject:
>> [sane-devel] Re: FW: canon630u's gl640 forked for CanoScan3000
>
> and
>
>> others? Date: Tue, 31 May 2005 09:08:01 +0200
>
>
>>>> Hi,
>>>>
>>>> I have been looking into CanoScan 3000(F) sane backend
>>>> creation, and
>>>>
>>>> so my question is that would it be possible to either simply
>>>> cut'n'paste some gl640-specific parts of the sources to be
>>>> included to genesys-backend or to a independent backend?
>>>>
>>>> Or better yet, canon630u backend might move all gl640 sources
>>>> to genesys and then just .h include them on the canon630u
>>>> backend (that is an LM9830-based anyway)?
>>
>> to be honest, I'm not sure what to answer. On one hand, I see, that
>> the
>
> original
>
>> genesys sources are for the UMAX 4500 and therefore they should
>> somehow
>
> work
>
>> with the CanoScan 3000 (work means, the communication should work),
>> one
>
> the
>
>> other hand, it seems, that there are some diffs. I didn't follow
>> the latest discussions about that on sane-devel, but I'd like to
>> hear from the genesys-experts
>
> out
>
>> there. It would be also a good idea to check the USB logs...
>
>
> I have the normal usbsnoop-3000f-plugin.log,
> usbsnoop-3000f-preview.log and few extra-small-scan-logs parsed with
> both experimental/usbsnoop/parseusbsnoop.awk and
> experimental/usbsnoop/spike4.pl so been comparing them with gl640 and
>  there seem to be some strange reg address offsets, I'll try to
> include a quick (possibly not even accurate) hash of the docs as far
> as I can see (based on genesys's public .pdf files).
>
> And it's kinda funny that both canon630u and niash have HP ScanJet
> 3300C backend at least partly defined, which one is the actually
> working one, or both? :-)

The niash backend works, it was specifically written to support the
HP3300c.

> At least gl640/gl660 should be separated (and shared by backends
> mentioned above) so it would make it simpler to just #include
> necessary interface chip communication protocols, perfect example
> being lm9830.h (part of canon630u funnily enough) and niash_xfer.h
> that seems to be a partial GL640 implementation compared to
> canon630u-common.c or u12-io.c...

lm9830.h? Seems highly scanner specific to me....
I agree that it would be nice to have common code for the parallel-
usb bridges.

BTW, the HP3300c has a NIPEDC0804, not a GL640.
It has two rows of 20 pins along bottom and top edge. It has a 12.000
MHz crystal mounted close to it. This chip was mentioned as an
'interface' chip on an electronics web page.

When I initially wrote the niash backend, I wanted to mimic the
windows driver as good as possible, so I implemented its exact
behaviour. There seem to be some minor (but important) differences
between parallel-USB bridges. For example the 8-byte sequence that
is used to initiate a bulk transfer is a little different between
the HP3300c and HP3400c.

> As far as I can see (up to looking into GL660's pins 24 and 26 to see
> it's hardwired to IEEE-1284 mode) that why CanoScan 3000 and some of
> the others do report themself's slightly differently is because they
> simply have slightly differently offsetted registers. ;-)

What do you mean by offsetted registers? Which registers are they?

I think that the functionality to talk to the USB-parallel bridge
should be strictly separated from any scanner specific functions,
otherwise I foresee an #ifdef jungle.. :)

Kind regards,
Bertrik

> Trying to make a proof-of-concept of recognizing the CanoScan's chips
> correctly (configuring the EPP-part and bulk write-read cycles to
> different memory locations on the scanner-side, just like on
> ct_D646U.c, ct-backend (canonscanner.sf.net)) I'm making some very
> rough hacks to canon630c-backend as it seems to have the closest usb
> logs I have gotten my hands on.
>
>
> -- amth