Hi,
Am Mittwoch, 8. November 2006 00:38 schrieb David Brownell:
You might mention that the new AVR Dragon can also be used to program
the atTiny45; it's a bit less expensive than an STK500, especially if you
Oh, didn't know that one. I'll add a pointer to that as well.
DebugWire (maybe not
Hi,
Am Mittwoch, 8. November 2006 23:10 schrieb Alan Stern:
There are no official explanations of this; it isn't part of the USB spec
(or any other spec). It's just the way the usbfs stack in Linux works.
The only documentation is the kernel's source code.
Hmm, but that makes such a solution
On Wed, 8 Nov 2006, Till Harbaum wrote:
But i still have a question regarding your remarks about class vs. vendor
requests etc. Actually i tried to find information about this in some usb
book i have at work as well as in the usb spec. I didn't find any explanation
about differences in
Hi,
Am Samstag, 4. November 2006 23:12 schrieb David Brownell:
If you associate those with e.g. interface #0 then only your kernel
driver will be able to issue those control requests though ... the
point being not to use the _unrestricted_ request types, instead
use USB_RECIP_INTERFACE in the
On Mon, 6 Nov 2006, Till Harbaum wrote:
Hi,
Am Samstag, 4. November 2006 23:12 schrieb David Brownell:
If you associate those with e.g. interface #0 then only your kernel
driver will be able to issue those control requests though ... the
point being not to use the _unrestricted_ request
Hi,
On Monday 06 November 2006 16:12, Alan Stern wrote:
But i am confused that my libusb based client can just omit to claim the
device and then send the commands anyway ...
If USB_TYPE_VENDOR is set in bRequestType then the request will always be
allowed, regardless of the recipient
Till,
On Saturday 04 November 2006 10:24 am, Till Harbaum wrote:
My device does all its communication via its control endpoint. Is
this already a bad idea?
Yes, it is. I have to maintain a driver which is doing control transfers
during normal operation, and it is a major cause of problems:
-
Hi,
Am Samstag, 4. November 2006 23:12 schrieb David Brownell:
If you associate those with e.g. interface #0 then only your kernel
driver will be able to issue those control requests though ... the
point being not to use the _unrestricted_ request types, instead
use USB_RECIP_INTERFACE in the
On Sun, 5 Nov 2006, Till Harbaum wrote:
Ok, i now basically got two different advises:
- Use restricted control transfers
- Use interrupt transfers
The latter has the disadvantage to not reliably work with 2.4 kernels
i have been told here.
As i am not a usb guru i'd prefer an answer
Hi,
Am Sonntag, 5. November 2006 23:50 schrieb Alan Stern:
Interrupt endpoints have a specific purpose in USB: They are meant for
data transfers that require a bounded latency. The host guarantees that
Hmm, actually i don't need a specific latency.
With control endpoints the guarantee is a
On Fri, 3 Nov 2006, Greg KH wrote:
On Sat, Nov 04, 2006 at 12:38:39AM +0100, Till Harbaum (Lists) wrote:
Hi,
i am writing a driver for a usb to i2c bridge. The driver is working nicely
but i can still use my libusb based demo app to access the hardware
directly while at the same
On Saturday 04 November 2006 9:04 am, Alan Stern wrote:
[libusb can send control messages with appropriate USB_RECIP_* values]
There is no way to prevent libusb from being used to send these kinds of
messages. If they interfere with the proper operation of the device,
that's an indication
Hi,
Am Samstag, 4. November 2006 18:51 schrieb David Brownell:
On Saturday 04 November 2006 9:04 am, Alan Stern wrote:
[libusb can send control messages with appropriate USB_RECIP_* values]
There is no way to prevent libusb from being used to send these kinds of
messages. If they
On Sat, Nov 04, 2006 at 07:24:14PM +0100, Till Harbaum wrote:
Hi,
Am Samstag, 4. November 2006 18:51 schrieb David Brownell:
On Saturday 04 November 2006 9:04 am, Alan Stern wrote:
[libusb can send control messages with appropriate USB_RECIP_* values]
There is no way to prevent
On Saturday 04 November 2006 10:24 am, Till Harbaum wrote:
Hi,
Am Samstag, 4. November 2006 18:51 schrieb David Brownell:
On Saturday 04 November 2006 9:04 am, Alan Stern wrote:
[libusb can send control messages with appropriate USB_RECIP_* values]
There is no way to prevent libusb
Hi,
Am Samstag, 4. November 2006 21:38 schrieb David Brownell:
If you've designed it so that the unrestricted requests can change
device state, that's the design problem. Classic examples include
I am doing exactly that ... ok, bad idea.
And if you're using _only_ control requests it should
On Saturday 04 November 2006 1:23 pm, Till Harbaum wrote:
Hi,
Am Samstag, 4. November 2006 21:38 schrieb David Brownell:
If you've designed it so that the unrestricted requests can change
device state, that's the design problem. Classic examples include
I am doing exactly that ... ok,
Hi,
i am writing a driver for a usb to i2c bridge. The driver is working nicely
but i can still use my libusb based demo app to access the hardware
directly while at the same time the kernel driver is active resulting in
some confusion in both drivers. Since libusb accesses go unnoticed by my
On Sat, Nov 04, 2006 at 12:38:39AM +0100, Till Harbaum (Lists) wrote:
Hi,
i am writing a driver for a usb to i2c bridge. The driver is working nicely
but i can still use my libusb based demo app to access the hardware
directly while at the same time the kernel driver is active resulting in
19 matches
Mail list logo
