On 03/11/2012 09:36, Stef wrote:
> On 02/11/2012 21:13, Radoslav Kolev wrote:
>> Hi,
>>
>> we are trying to get a GL846 based scanner to work - Canon Image
>> Formula Flatbed Scanner Unit 101.
>>
>> I'm new to sane and scanners, so please excuse me if I'm asking some
>> simple/stupid questions.
>> Any pointers to documentation of any sort will be appreciated.
>>
>> So, I've captured a scan under windows. The raw log can be found here:
>> http://kolev.info/files/Image-formula-101-win-scan-raw-usbsnoop.log.gz
>>
>> I have run the following utility
>> (web.media.mit.edu/~mhirsch/lide100/usbsnoop-gl847.pl) to get a more
>> human readable version, the results are here:
>> http://kolev.info/files/Image-formula-101-win-scan.log.gz
>>
>> The above log file with some note's I've written trying to figure out
>> what's happening:
>> http://kolev.info/files/Image-formula-101-win-scan-annotated.log.gz
>>
>> The usbsnoop-gl847.pl spits out a lot of "unknown8e(33) = 0x00,
>> Unknown in register value 138, Unknown out buffer value 139"
>> messages. I looked at the raw USB data and then after checking the
>> section /* USB control message values */ in genesys_low.h it seems
>> that some of these might be GPIO_READ requests, and I suspect another
>> part might be connected with talking to the FE.
>>
>> Where did the defines in the /* USB control message values */ in
>> genesys_low.h come from? It's easy to find the GL846 datasheet online,
>> but there's nothing in there about the USB protocol. Was all this
>> reverse engineered or there's some document/source I've not found yet?
>> I can see in the source that register access is handled differently
>> for GL847 vs others, but I have no idea which of these defines are
>> relevant for which chip.
>>
>> When loaded with the gl847 backend there is some communication with
>> the scanner (lamp blinks during calibration) but no motor movement.
>> From the usbsnoop logs I see that a motor phase table is loaded into
>> RAM and then the MPENB bit (Enable motor generating function which is
>> stored in memory) is set to high in register 0x08, which is not used
>> in any of the other scanners. Is this something gl846/7 specific and
>> should I try to replicate this, or there's a better approach without
>> using a phase table in RAM?
>>
>> Other things that seem interesting from the snoop log file is that a
>> lot of GPIO toggling is going on, and also in higher GPIO numbers 25,
>> 26 27.
>>
>> Also, there are some bulk writes to address 0x10014000 and 4008 which
>> I can't figure out the reason for.
>>
>> Before the actual scan begins there is a pattern of setting some
>> registers and RAM, then reading RAM contents (image data?). My current
>> guess is this may be hunting for the page start on the scanner bed.
>>
>> So, that's about as far as we are now. Any ideas, suggestions or
>> pointers to information will be greatly appreciated.
>>
>> Best regards,
>> Radoslav Kolev
>>
>
> Hello,
>
> the only public documentation from genesys logic is the register
> description you already found. Firmware functions have been reversed
> engineered. When there are many reads and writes, it could be hardware
> setting and polling and so GPIO related.
>
> The MPENB use is a new feature that I haven't implemented in the
> genesys backend, and will have to be added. Unless you create proper
> slope tables and make this model work like the others.
>
> Sometimes it is safe to drop some unidentified reads. For instance
> I have found writes that could be image watermark with the CCD sensor
> name. Sometimes you don't really find what they are for, but you have
> to implement them to get the scanner working.
>
> I have learned that a lot of experimenting and testing is needed
> to get these scanner work. For instance I was blocked by an
> undocumented register (or buggy write to a register) that was required
> to get correct scanned data.
>
> Regards,
> Stef
>
Hello,
a question comes to my mind. How did you find it is a GL846 scanner ?
Regards,
Stef
