Had a type in the email address so I'm sending this again to
the linux-irda list. -BEL
This email is a an analysis of FIR and the Kodak DC-265.
for you IrDA types reading this, my FIR is:
NSC,PC87338,11.2,0x398,0x2f8,0x2f8,3,-1,1,0,1
The crux of this article is that simple commands such as
status and gettime work fine, while the all important download
function dies. Download works using the SIR mode driver.
And I'm running Linux 2.2.15pre17 these days.
On Fri, Apr 07, 2000 at 09:19:38AM +0300, Viljo Hakala wrote:
> How does picture download fail ? Does the command return an error code in
> the very beginning, or does it begin processing the download, and sends
> some chunks, and possibly fails a moment later ?
Here is a debug log from ks on a download:
top# ./ks -d /dev/ircomm1 download
irda port opened
------------------------
device = </dev/ircomm1>
no devtype specified
no bitrate specified
opt_devtype = 0
opt_serial = 0
opt_usb = 0
opt_irda = 1
rate = 9600 *** this isn't used
------------------------
Executing command: download
irda writing 16 bytes.
irda write wrote 16:
00000000 | 00 00 00 0c 00 00 00 00 00 40 00 00 00 00 00 01 |.........@......|
irda_receive_message: entering
irda_receive_message: entering
irda receive read 376:
00000000 | 00 00 01 74 00 00 03 00 ff bf 00 00 00 00 00 06 |...t............|
00000010 | 00 00 00 02 44 43 32 36 35 5f 30 31 2f 00 00 00 |....DC265_01/...|
00000020 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000030 | 00 00 00 00 50 30 30 30 30 35 34 37 2e 4a 50 47 |....P0000547.JPG|
00000040 | 00 00 00 00 00 07 ab 43 a4 00 00 00 00 00 00 02 |.......C........|
00000050 | 44 43 32 36 35 5f 30 31 2f 00 00 00 00 00 00 00 |DC265_01/.......|
00000060 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000070 | 50 30 30 30 30 35 34 38 2e 4a 50 47 00 00 00 00 |P0000548.JPG....|
00000080 | 00 06 e4 92 a4 00 00 00 00 00 00 02 44 43 32 36 |............DC26|
00000090 | 35 5f 30 31 2f 00 00 00 00 00 00 00 00 00 00 00 |5_01/...........|
000000a0 | 00 00 00 00 00 00 00 00 00 00 00 00 50 30 30 30 |............P000|
000000b0 | 30 35 34 39 2e 4a 50 47 00 00 00 00 00 05 02 0e |0549.JPG........|
000000c0 | a4 00 00 00 00 00 00 02 44 43 32 36 35 5f 30 31 |........DC265_01|
000000d0 | 2f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |/...............|
000000e0 | 00 00 00 00 00 00 00 00 50 30 30 30 30 35 35 30 |........P0000550|
000000f0 | 2e 4a 50 47 00 00 00 00 00 05 11 79 a4 00 00 00 |.JPG.......y....|
00000100 | 00 00 00 02 44 43 32 36 35 5f 30 31 2f 00 00 00 |....DC265_01/...|
00000110 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000120 | 00 00 00 00 50 30 30 30 30 35 35 31 2e 4a 50 47 |....P0000551.JPG|
00000130 | 00 00 00 00 00 06 b4 3b a4 00 00 00 00 00 00 02 |.......;........|
00000140 | 44 43 32 36 35 5f 30 31 2f 00 00 00 00 00 00 00 |DC265_01/.......|
00000150 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000160 | 50 30 30 30 30 35 35 32 2e 4a 50 47 00 00 00 00 |P0000552.JPG....|
00000170 | 00 05 7b 24 a4 00 00 00 |..{$.... |
irda_receive_message: size = 376, already read = 376
irda_receive_message: returning normally
6 files in camera...
p0000547.jpg: size = 502595 odsGetFileData --
odsGetFileData: partial length is 20000 bytes.
irda writing 80 bytes.
irda write wrote 80:
00000000 | 00 00 00 4c 00 00 00 00 00 42 00 00 00 00 00 02 |...L.....B......|
00000010 | 44 43 32 36 35 5f 30 31 2f 00 00 00 00 00 00 00 |DC265_01/.......|
00000020 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000030 | 50 30 30 30 30 35 34 37 2e 4a 50 47 00 00 00 00 |P0000547.JPG....|
00000040 | 00 00 00 00 00 00 00 00 00 00 4e 20 00 00 00 00 |..........N ....|
irda_receive_message: entering
irda receive read 0:
xodsGetFileData --
odsGetFileData: partial length is 20000 bytes.
irda writing 80 bytes.
irda write wrote -1:
irda_receive_message: entering
In the irdadump log one finds:
07:28:50.023096 rr:rsp < ca=8c pf=1 nr=3 (2)
07:28:50.519938 rr:cmd > ca=8c pf=1 nr=0 (2)
07:28:50.522134 i:rsp < ca=8c pf=1 nr=3 ns=0 LM slsap=03 dlsap=13 TTP credits=0 (382)
07:28:51.019945 rr:cmd > ca=8c pf=1 nr=1 (2)
07:28:51.021416 rr:rsp < ca=8c pf=1 nr=3 (2)
07:28:51.075987 i:cmd > ca=8c pf=1 nr=1 ns=3 LM slsap=13 dlsap=03 TTP credits=1 (86)
07:28:51.077659 i:rsp < ca=8c pf=1 nr=4 ns=1 LM slsap=03 dlsap=13 TTP credits=1 (5)
* at this point one only sees command going out and no responses coming back.
* this goes on until some part of the IrDA protocol gives up and closes the
* circuit.
07:28:51.569936 rr:cmd > ca=8c pf=1 nr=2 (2)
07:28:52.069948 rr:cmd > ca=8c pf=1 nr=2 (2)
07:28:52.569945 rr:cmd > ca=8c pf=1 nr=2 (2)
07:28:53.069958 rr:cmd > ca=8c pf=1 nr=2 (2)
...
The FIR driver is a different driver than the SIR driver, so their could
certainly be a problem in it.
I got debug mode turned on in the FIR driver, but its too much info for me
to digest.
Here is the log from the nsc-ircc (FIR) driver:
IrCOMM protocol (Dag Brattli)
ircomm_tty_attach_cable()
ircomm_tty_ias_register()
irlmp_state_u_connect(), Unknown event LM_LAP_DISCOVERY_CONFIRM
irlap_change_speed(), setting speed to 4000000
nsc_ircc_change_speed(), handling baud of 4000000
ircomm_param_service_type(), services in common=06
ircomm_param_service_type(), resulting service type=0x04
* this is where everything happens, and then you get the
* 07:28:51.569936 rr:cmd > ca=8c pf=1 nr=2 (2) from above
* and then...
IrLAP, no activity on link!
ircomm_tty_close()
ircomm_tty_shutdown()
ircomm_tty_detach_cable()
ircomm_close()
irlap_change_speed(), setting speed to 9600
I've been using my much simplier test programs. Basically an
open(/dev/ircomm1)
write (1,buf);
read (0,result);
close
I have a gettime version and a getload version.
Gettime does:
char buf2[] = { 0,0,0,8, 0,0,0,0, 0,0x70,0,0 };
write(fd,buf2,12);
n = read(fd,buf,20);
mydump(buf,n);
Getload does:
char buf2[] = {
0x00, 0x00, 0x00, 0x4c, 0x00, 0x00, 0x00, 0x00,
0x00, 0x42, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02,
0x44, 0x43, 0x32, 0x36, 0x35, 0x5f, 0x30, 0x31,
0x2f, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x50, 0x30, 0x30, 0x30, 0x30, 0x35, 0x34, 0x37,
0x2e, 0x4a, 0x50, 0x47, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x4e, 0x20, 0x00, 0x00, 0x00, 0x00
};
write(fd,buf2,80);
n = read(fd,buf,sizeof(buf));
mydump(buf,n);
Gettime works fine. Getload hangs in the read (terminates eventually
with IrDA shutdown the link). Getload will not work for you (people
other than me) because it has data specific to my camera in it.
However, you can create a version of it using DEBUG with ks and trying a
download.
I reset everything (irda subsystem and camera) between attempts of
the different programs. It is acting like the camera isn't seeing
the getload 80 byte command. You'd think at least an error response
would show up.
Running
% ./gettime (works ok)
% ./getload (fails)
% ./gettime (works ok)
So the IrDA subsystem itself it not messed up by getload.
If it was a standard serial port, I'd think I wasn't in raw
mode and one of the characters in the stream was messing something
up.
I modified getload such that the command (0x00 0x42) was invalid.
Just made it (0x42 0x00) and the camera echoed right back that
the command was invalid.
I modified getload so it refered to a non-existant picture. The
camera echoed the non-existant file error right back.
Let's blame the IrDA people. Must be a protocol error in the FIR driver.
8-)
--
Brian Litzinger <[EMAIL PROTECTED]>
_______________________________________________
Linux-IrDA mailing list - [EMAIL PROTECTED]
http://www4.pasta.cs.UiT.No/mailman/listinfo/linux-irda
