Thank you very much for your reply.
> >In the function "static int bluetooth_write (...)",
> >how about to change the non-blocking write
> >FILL_BULK_URB (urb, bluetooth->dev, usb_sndbulkpipe(bluetooth->dev,
> > new_buffer, buffer_size,
> >bluetooth_write_bulk_callback, bluetooth);
> >urb->transfer_flags |= USB_QUEUE_BULK;
> >// send it down the pipe
> >status = usb_submit_urb(urb);
> >to the blocking write
> >status = usb_bulk_msg(bluetooth->dev, usb_sndbulkpipe(bluetooth->dev,
> > new_buffer, buffer_size, &actual_length, 1000);
> >The change seems to be stable
> >when I send large number of ACL packets.
> Why? Is there a problem with sending large numbers of ACL packets with
> the current non-blocking write?
Yes. The problem is that
the FTP file transfer from USB Ericcson module to Digianswer PC card
(many calls for "bluetooth_write()" are used in this case)
frequently fails because of the bluetooth USB driver's fail.
But if I change the non-blocking code to blocking code,
the FTP transfer is almost always stable.
I have another problem that
the FTP file transfer from Digianswer PC card to USB Ericcson module to Digianswer PC card
(many calls for bluetooth_read_bulk_callback() and small calls for bluetooth_int_callback() are needed in this case.)
because the first incoming byte to the user level protocol after some data trasnfers is neither 0x02 (ACL) nor 0x04 (EVENT).
I guess that the reason is a mix-up of ACL and EVENT packets
or a buffer overflow. But I am not sure.
The problems described above does not happen when using RS232.