Hi, On Mon, Mar 25, 2013 at 03:31:04AM -0300, Werner Almesberger wrote: > Alexander Aring wrote: > > I work on the atusb driver too and make some change on this driver. > > Oh dear, another one ! This must be the device with the largest > choice of drivers per user :-) > > > I tried to understand why this driver need this WRITE_SYNC and I don't > > understand it really. > > The idea is that we could have an interrupt from a reception already > on the way from the device. Without synchronization, it would be > misinterpreted as the end of the transmission, which would > > - cause the driver to switch the transceiver back to RX (which > should be okay, since we're allowed to send the RX_ON while > still in BUSY_TX) > > - make the driver interpret the next TRX_END (signaling the end > of the transmission) as a reception. This could cause > embarrassment. > Ok, thanks for this information.
> > I don't alloc a new interrupt to the system, I use a tasklet and the only > > thing which the at86rf230 driver sets is the tasklet schedule work > > functionpointer. The creation of tasklet is inside atusb. > > I like the tasklet. But since you're not doing anything with it > (enable/disable, etc.) in at86rf230.c, why not just a callback ? > Yeah, since Sascha drop these enable and disable irq, we can use just a callback. But a driver get some information from platform data and don't set some information, but a callback is a nice idea. > > 3. > > Some usb improvements in USB_MATCH_TABLE to remove these checks on dfu > > interface in probe function. > > Ah, good. That check was quite clumsy. > > > 4. > > I evaluate the commands for a at86rf230. Your driver to the same on > > checking if the len == 2(reg write/read) or len < 2(frame write/read). > > It's actually request structure (one or two transfers) and length. > Yes, tricky :-) > > > I am not finished with the driver yet. > > Hmm, but your driver still has the fundamental problem of tx/rx > doing all these USB transfers that get paced at one per USB frame, > i.e., 1 ms. Are you sure you want to continue along that path ? > Yes... I tested with a change firmware to tx/rx 16 bit values. I put tx to wValue/wIndex and receive in the receive buffer. But it is too slow, I think. What about to add a new bulk transfer and do something like linux. This bulk transfer uses a struct with a tx and rx buffer to send and receive at the same time. On the linux side we decode tx and rx buffer and put it into linux rx and tx spi buf. Alex ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar _______________________________________________ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
