• AVR Freaks

Bare Minimum Isochronous Transfer using SPP

Page: 12 > Showing page 1 of 2
Author
vloki
Jo, alla!
  • Total Posts : 6801
  • Reward points : 0
  • Joined: 2007/10/15 00:51:49
  • Location: Germany
  • Status: offline
2008/10/07 02:08:31 (permalink)
0

Bare Minimum Isochronous Transfer using SPP

I'm interested in using the Streaming-Parallel-Port for reading data from an USB device.

Like xiaofan said in his thread: Bare Minimum Isochronous Transfer Generic USB Device Example
ORIGINAL: xiaofan
I've searched the forum for a generic isoc transfer based example code but to no avail.

I've done a bare minimum Isochronous Transfer Generic USB device port for PICKit 2 modified from the Microchip generic USB example.

I have not yet fully understood the frame code yet so I choose the simplest method without using Ping-Pong buffer. So it is not really useful at all but just a step in the long learning process.

The same to me. gringringrin
(not fully understand ...)
Regardless of that, I tried to setup a minimum SPP mode and post the results (so far) here.
Maybe there are some of you out there, don't know how to start and also don't find any examples.



I used the MCHP USB framework 2.3 for the firmware, and the project should be located like the original
demos of that framework. ("USB Device - ISO_SPP" or like this)

The project is configured for a PIC18F4550 on an old PICDEM USB demo board
(the really old one made for PIC16C7x5 controllers)



The test software on PC side is based on xiaofan's console example and requires the libusb driver.



Hopefully this is useful for anybody and at best there will come in some improvements grin
(((
why we need Sleep() in the test loops ?,
some documentation for "libusb" i.e. the 32640 bytes limit for usb_submit_async(...)
...
)))

<edit> typos
<edit2> Please use attachments found at
post #16 (reading continuous without delays)

post edited by vloki - 2011/03/07 08:08:41

Attached Image(s)


Uffbasse !
#1

21 Replies Related Threads

    vloki
    Jo, alla!
    • Total Posts : 6801
    • Reward points : 0
    • Joined: 2007/10/15 00:51:49
    • Location: Germany
    • Status: offline
    RE: Bare Minimum Isochronous Transfer using SPP 2008/10/09 05:34:23 (permalink)
    0
    The test software running on PC from my first post was using the libusb driver.

    The communication to isochronous usb device was possible,
    but there have been a few issues.

    1st and biggest problem:

       I was not able to read data continuously without a pause of about 300ms
       between two data requests !


    So i decided to switch over to mchp driver even if I read some comments
    from xiaofan, that isochronous is possibly not doable with mchp driver.

    I modified my "minimum PDFSUSBdemo" for use to read and write the EP1 pipes.
    (see attachment if interested)


    [&:][:@] SADLY THE RESULT IS THE SAME [&:][:@][&:][:@]

    I'm not really able to read or write continuously.
    The only thing I can counton is the "Invalid Handle" error.

    Some of my thoughts about that:

    1.
    It seems to depend on the number of requested bytes as well as of time between the calls.
    I do not really understand why some combinations run well and others not at all.
    Requests for some numbers of data are not possible even not at first time.

    2.
    If I understand (a little bit wink) the USB2.0 specification, the packet size
    in the endpoint descriptor is primary used to reserve bandwith on the bus
    and to determine how many bytes the device buffers can handle in one transaction.
    Correct ?

    3.
    Watching my scope, I recognized that there may be more than one packet
    transfered in a 1ms frame, if big amount of data has to be transfered.

    i.e. The time for a transfer does not increase further if transfers are bigger than 32kB.
    (partially two packets are transfered in 1ms then)

    4.
    When the communication breaks, it seems that it happens on PC side
    (I usually still can see the read clocks at the Streaming-Parallel-Port)


    5.
    How to initiate a (fast) continuous data stream ? pinkpinkpink


    Anybody has got some ideas ???






    Attached Image(s)


    Uffbasse !
    #2
    crevars
    Starting Member
    • Total Posts : 50
    • Reward points : 0
    • Joined: 2005/10/06 07:44:56
    • Location: Odyssee-systemes, France
    • Status: offline
    RE: Bare Minimum Isochronous Transfer using SPP 2008/10/09 10:37:53 (permalink)
    0
      I was not able to read data continuously without a pause of about 300ms
    between two data requests !


    Hi, I don't know how the libusb driver handles the isochronous reads.

    However, in general, if you want to have one isochronous transaction on every single frame, you have to ask the driver to read a pretty big amount of data (let's says 20 times the isochronous endpoint buffer size) and you need to be sure that the driver will get a new read request as soon as the previous one is finished (by sending a read request before the previous one if the driver is able to handle pending io requests).

    I did this in a previous project using usbsamp (a demo driver included in the WDK). You can also read this: http://forum.microchip.com/tm.aspx?m=295708&mpage=1

    I hope this will help you.

    Regards,
    Franck.
    post edited by crevars - 2008/10/09 10:48:41
    #3
    stefanopod
    Super Member
    • Total Posts : 1285
    • Reward points : 0
    • Joined: 2007/06/25 02:33:59
    • Location: Bologna,Italy
    • Status: offline
    RE: Bare Minimum Isochronous Transfer using SPP 2008/10/09 13:14:44 (permalink)
    0
    In my project of isochronous sample/recording I employed both cyusb and usbsamp drivers (the idea of having another struggle with libusb is too scaring for me).
     
    The differences between my project and yours are only the source/sink of data (ADC vs SPP) and the different driver, but from your posts I see you have resolved the SPP issue.
     
    In your case (reading) the problem is much alike my sampling.
     
    On PIC side I had problems only about synchronizing data producing and data transmitting, but that is another story. The packet trasmission is accomplished sending continously a packet( setting address, toggling UOWN )if SIE is not busy.
     
    On PC side (omitting the problem of threading and havig a non blocking streaming) I had at least 2 buffers with overlapped I/O on each of them, and requests tipically of 8 packets for each request. (Cbuilder and c#)
     
    At last everything worked fine with modest speeds (50 kHz), the bottleneck being the sampling/recording routine duration and not USB speed.
     
    I had weird problems, never resolved, in loopback tests (ok on a PC, ko on another, OK on a hub,KO on another,ok with cyusb, bad with usbsamp).
     
    If you outline a bit your system with more detail,I'll try to be of more help.
     
     Anyway trying ubsamp with crevars modifications would be a good idea.
     
    And about isochronous Tsuneo is *the* source since when he navigated far from Microchip forum.
    #4
    xiaofan
    Super Member
    • Total Posts : 6247
    • Reward points : 0
    • Joined: 2005/04/14 07:05:25
    • Location: Singapore
    • Status: offline
    RE: Bare Minimum Isochronous Transfer using SPP 2008/10/09 15:54:19 (permalink)
    0
    From what I read, cyusb is a very good driver and you may want to try it. You can also try usbsamp. There are very few examples with libusb-win32 and isochronous transfer and I actually do not quite understand how it works (asynchronous I/O). Last time I posted the question in the mailing list and nobody answered me.

    If you have access to Linux, then you may want to try out libusb 1.0. It is supposed to support isochronous transfer well. The old libusb-0.1 under Linux does not support isochronous transfer.

    When I have sometime, I will try out your project.

      USB_Links and libusb
    #5
    xiaofan
    Super Member
    • Total Posts : 6247
    • Reward points : 0
    • Joined: 2005/04/14 07:05:25
    • Location: Singapore
    • Status: offline
    RE: Bare Minimum Isochronous Transfer using SPP 2008/10/09 16:01:37 (permalink)
    0
    By the way, you seem to use Visual C++ with libusb-win32. I've heard people having problem with it. You might give MinGW a try, it works well with libusb-win32 and I always use it with libusb-win32.

      USB_Links and libusb
    #6
    vloki
    Jo, alla!
    • Total Posts : 6801
    • Reward points : 0
    • Joined: 2007/10/15 00:51:49
    • Location: Germany
    • Status: offline
    RE: Bare Minimum Isochronous Transfer using SPP 2008/10/10 02:51:57 (permalink)
    0
    Frank, Stefano & Xiaofan,

    many thanks for your suggestions.

    Before I switch to another driver again I decided to try finding out whats
    going wrong exactly.
    The  usb sniffer software (demo) I used in the past was a expired and I had
    to find a new one. (Now use open source SniffUSB wink)



    The first issue I figured out is the USBD_STATUS_BUFFER_OVERRUN error.

    Because I use the SPP the PIC always seems to read or write complete packages.
    (I can see it, monitoring the RD and WR clocks of SPP)
    If the request does not fit to this size, naturally a buffer overrun occurs  grin

    A bit strange is that this error does not end up with an error at the application mandatory.
    If the request is less than packet size, the pipe handle always gets lost.
    If the request is more than x*packet size, the handle keeps ok and the application seems
    to get the requested number of data. [8D]

    Below I post the sniffer protocol for a 129 byte in transfer at an endpoint size of 128:


    [4832887 ms] UsbSnoop - FilterDispatchAny(b676bfd2) : IRP_MJ_INTERNAL_DEVICE_CONTROL
    [4832887 ms] UsbSnoop - FdoHookDispatchInternalIoctl(b676c1ea) : fdo=86858598, Irp=86904508, IRQL=0
    [4832888 ms]  >>>  URB 39 going down  >>>
    -- URB_FUNCTION_ISOCH_TRANSFER:
      PipeHandle           = 8730a604 [endpoint 0x00000081]
      TransferFlags        = 00000007 (USBD_TRANSFER_DIRECTION_IN, USBD_SHORT_TRANSFER_OK, USBD_START_ISO_TRANSFER_ASAP
      TransferBufferLength = 00000081
      TransferBuffer       = 00000000
      TransferBufferMDL    = 868f6988
      StartFrame           = 00000000
      NumberOfPackets      = 00000002
      IsoPacket[0].Offset = 0
      IsoPacket[0].Length = 0
      IsoPacket[1].Offset = 128
      IsoPacket[1].Length = 0
      UrbLink              = 00000000
    [4832894 ms] UsbSnoop - MyInternalIOCTLCompletion(b676c126) : fido=86979020, Irp=86904508, Context=868eebc8, IRQL=2
    [4832895 ms]  <<<  URB 39 coming back  <<<
    -- URB_FUNCTION_ISOCH_TRANSFER:
      PipeHandle           = 8730a604 [endpoint 0x00000081]
      TransferFlags        = 00000007 (USBD_TRANSFER_DIRECTION_IN, USBD_SHORT_TRANSFER_OK, USBD_START_ISO_TRANSFER_ASAP
      TransferBufferLength = 00000081
      TransferBuffer       = 00000000
      TransferBufferMDL    = 868f6988
      StartFrame           = 0049ce88
      NumberOfPackets      = 00000002
      ErrorCount           = 00000001
      IsoPacket[0].Offset = 0
      IsoPacket[0].Length = 128
      IsoPacket[0].Status = 00000000
        00000000: 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04
        00000010: 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04
        00000020: 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04
        00000030: 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04
        00000040: 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04
        00000050: 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04
        00000060: 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04
        00000070: 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04
      IsoPacket[1].Offset = 128
      IsoPacket[1].Length = 1
      IsoPacket[1].Status = c000000c
        00000000: 04
      UrbLink              = 00000000

    Seems to be easy to omit this issue using always fitting numbers Smile



    The next error I will try to analyze will be: USBD_STATUS_BAD_START_FRAME



    Uffbasse !
    #7
    vloki
    Jo, alla!
    • Total Posts : 6801
    • Reward points : 0
    • Joined: 2007/10/15 00:51:49
    • Location: Germany
    • Status: offline
    RE: Bare Minimum Isochronous Transfer using SPP 2008/10/10 03:14:02 (permalink)
    0
    Still try to figure out things about this "+/-USBD_ISO_START_FRAME_RANGE"

    In the meanwhile post the protocol for a "USBD_STATUS_BAD_START_FRAME"

    Maybe one of you already could point me to the problem Smile

    [10216755 ms] UsbSnoop - FilterDispatchAny(b676bfd2) : IRP_MJ_INTERNAL_DEVICE_CONTROL
    [10216755 ms] UsbSnoop - FdoHookDispatchInternalIoctl(b676c1ea) : fdo=86858598, Irp=86830008, IRQL=0
    [10216755 ms]  >>>  URB 54 going down  >>>
    -- URB_FUNCTION_ISOCH_TRANSFER:
      PipeHandle           = 8730a604 [endpoint 0x00000081]
      TransferFlags        = 00000007 (USBD_TRANSFER_DIRECTION_IN, USBD_SHORT_TRANSFER_OK, USBD_START_ISO_TRANSFER_ASAP
      TransferBufferLength = 00000080
      TransferBuffer       = 00000000
      TransferBufferMDL    = 866fc3d8
      StartFrame           = 00000000
      NumberOfPackets      = 00000001
      IsoPacket[0].Offset = 0
      IsoPacket[0].Length = 0
      UrbLink              = 00000000
    [10216761 ms] UsbSnoop - MyInternalIOCTLCompletion(b676c126) : fido=86979020, Irp=86830008, Context=868eebc8, IRQL=2
    [10216761 ms]  <<<  URB 54 coming back  <<<
    -- URB_FUNCTION_ISOCH_TRANSFER:
      PipeHandle           = 8730a604 [endpoint 0x00000081]
      TransferFlags        = 00000007 (USBD_TRANSFER_DIRECTION_IN, USBD_SHORT_TRANSFER_OK, USBD_START_ISO_TRANSFER_ASAP
      TransferBufferLength = 00000080
      TransferBuffer       = 00000000
      TransferBufferMDL    = 866fc3d8
      StartFrame           = 009bf915
      NumberOfPackets      = 00000001
      ErrorCount           = 00000000
      IsoPacket[0].Offset = 0
      IsoPacket[0].Length = 128
      IsoPacket[0].Status = 00000000
        00000000: 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04
        00000010: 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04
        00000020: 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04
        00000030: 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04
        00000040: 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04
        00000050: 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04
        00000060: 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04
        00000070: 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04
      UrbLink              = 00000000
    [10216771 ms] UsbSnoop - FilterDispatchAny(b676bfd2) : IRP_MJ_INTERNAL_DEVICE_CONTROL
    [10216771 ms] UsbSnoop - FdoHookDispatchInternalIoctl(b676c1ea) : fdo=86858598, Irp=86830008, IRQL=0
    [10216771 ms]  >>>  URB 55 going down  >>>
    -- URB_FUNCTION_ISOCH_TRANSFER:
      PipeHandle           = 8730a604 [endpoint 0x00000081]
      TransferFlags        = 00000007 (USBD_TRANSFER_DIRECTION_IN, USBD_SHORT_TRANSFER_OK, USBD_START_ISO_TRANSFER_ASAP
      TransferBufferLength = 00000080
      TransferBuffer       = 00000000
      TransferBufferMDL    = 866fc3d8
      StartFrame           = 00000000
      NumberOfPackets      = 00000001
      IsoPacket[0].Offset = 0
      IsoPacket[0].Length = 0
      UrbLink              = 00000000
    [10216771 ms] UsbSnoop - MyInternalIOCTLCompletion(b676c126) : fido=86979020, Irp=86830008, Context=868eebc8, IRQL=2
    [10216771 ms]  <<<  URB 55 coming back  <<<
    -- URB_FUNCTION_ISOCH_TRANSFER:
      PipeHandle           = 8730a604 [endpoint 0x00000081]
      TransferFlags        = 00000007 (USBD_TRANSFER_DIRECTION_IN, USBD_SHORT_TRANSFER_OK, USBD_START_ISO_TRANSFER_ASAP
      TransferBufferLength = 00000000
      TransferBuffer       = 00000000
      TransferBufferMDL    = 866fc3d8
      StartFrame           = 009bf916
      NumberOfPackets      = 00000001
      ErrorCount           = 00000001
      IsoPacket[0].Offset = 0
      IsoPacket[0].Length = 0
      IsoPacket[0].Status = c0000a00
      UrbLink              = 00000000
    [10220236 ms] UsbSnoop - FilterDispatchAny(b676bfd2) : IRP_MJ_INTERNAL_DEVICE_CONTROL
    [10220236 ms] UsbSnoop - FdoHookDispatchInternalIoctl(b676c1ea) : fdo=86858598, Irp=87123888, IRQL=0

    Uffbasse !
    #8
    vloki
    Jo, alla!
    • Total Posts : 6801
    • Reward points : 0
    • Joined: 2007/10/15 00:51:49
    • Location: Germany
    • Status: offline
    RE: Bare Minimum Isochronous Transfer using SPP 2008/10/10 05:21:18 (permalink)
    0
    I think the issue with the "USBD_STATUS_BAD_START_FRAME"

    is described in MS presentation

    USBdrv-tips2.ppt


    Uffbasse !
    #9
    chinzei
    Super Member
    • Total Posts : 2250
    • Reward points : 0
    • Joined: 2003/11/07 12:39:02
    • Location: Tokyo, Japan
    • Status: offline
    RE: Bare Minimum Isochronous Transfer using SPP 2008/10/10 06:56:05 (permalink)
    0
    USBD_STATUS_BUFFER_OVERRUN (0xc000000c)

    Not just for isoc, for all types of IN transfers, USBDI requires a buffer of "expected size" at each IN request call (URB: USB Request Block). When the incoming bytes from device exceed this expected size, USBD_STATUS_BUFFER_OVERRUN occurs.

    For isoc transfer, you can specify multiple packets at a single URB. USBDI checks each packet size for buffer overrun, not the entire size. Then, if you take variable packet-size approach to represent fractional sampling rate, you have to specify possible max packet size to the URB.

    "USB Isochronous Transfer" on MSDN
    http://msdn.microsoft.com/en-us/library/ms790482.aspx


    USBD_STATUS_BAD_START_FRAME (0xc0000a00)

    I think the issue with the "USBD_STATUS_BAD_START_FRAME"
    is described in MS presentation

    Umm... The MS presentation is related to the error at the point that both cases are caused by USBD_START_ISO_TRANSFER_ASAP flag. As the presentation shows, MS suddenly changed (or fixed) the operation of USBD_START_ISO_TRANSFER_ASAP flag on XP. Walter Oney (the author of famous "Windows Driver Model") explains about the history, the status on XP and workaround on this topic.

    "Anomalous behavior of USBD_START_ISO_TRANSFER_ASAP flag in XP" on microsoft.public.development.device.drivers
    http://groups.google.com/group/microsoft.public.development.device.drivers/browse_thread/thread/394f5f24e6dfbfe0/1237cd0aafd50423?hl=en

    Tsuneo
    #10
    chinzei
    Super Member
    • Total Posts : 2250
    • Reward points : 0
    • Joined: 2003/11/07 12:39:02
    • Location: Tokyo, Japan
    • Status: offline
    RE: Bare Minimum Isochronous Transfer using SPP 2008/10/10 22:51:00 (permalink)
    0
    For USBD_START_ISO_TRANSFER_ASAP problem, it may be better to explain briefly the background of this issue.

    For continuous data streaming over USB (on either isoc or bulk), we have to put Read/Write call repeatedly on our host app. In this case, multiple OVERLAPPED Read/Write calls are issued simultaneously, to ensure gapless transfer. These multiple calls are stored to the device request queue, executed by the device driver one by one sequentially. When a call completes, the host app fills up another call, to keep the device queue populated. In this way, seamless transfer is maintained.

    Before XP, USBD_START_ISO_TRANSFER_ASAP flag works when the device request is executed; it fills the start frame automatically to the next frame of the last device request.

    After XP, USBD_START_ISO_TRANSFER_ASAP flag works when the device request is queued; it fills the start frame to the current one when the request is issued.

    As most of isoc applications have depended to the former function of USBD_START_ISO_TRANSFER_ASAP, many applications were forced update on XP. Some apps aren't updated yet.

    Tsuneo
    #11
    vloki
    Jo, alla!
    • Total Posts : 6801
    • Reward points : 0
    • Joined: 2007/10/15 00:51:49
    • Location: Germany
    • Status: offline
    RE: Bare Minimum Isochronous Transfer using SPP 2008/10/13 02:12:02 (permalink)
    0
    chinzei,

    thanks a lot for your assistance !

    Unfortunately I'm not a skilled windows programmer.
    If I hear about drivers or threads, dll's and such things,
    I run away grin grin grin.
    Usually I write small applications to test the hardware only.
    (The "real" application must must be written by someone else [&:])
     

    Working on the current issue is based more on intuition rather than
    knowledge. But, maybe I found a solution. [8D]

    I tried the "workaround" described in USBdrv-tips2.ppt

    Potential Workarounds
    reset the pipe before sending every URB
    ...


    The libUSB driver provides a function to reset an endpoint that seems to work:
    int usb_resetep(usb_dev_handle *dev, unsigned int ep);

    Hope that my first impression will persist during a few tests wink

    Uffbasse !
    #12
    vloki
    Jo, alla!
    • Total Posts : 6801
    • Reward points : 0
    • Joined: 2007/10/15 00:51:49
    • Location: Germany
    • Status: offline
    RE: Bare Minimum Isochronous Transfer using SPP 2008/10/13 04:49:24 (permalink)
    0

    I'm an idiot

    After doing some more tests, it is clear now that no endpoint reset is needed.

    If I never did change xiaofans example test code I would have had less trouble.
    I didn't understand the conceptwith the multiple context and multiple URBs
    and destroyed the sequence with my modifications. [:@][:@][:@]

    Thanks again chinzei and crevars,
    even if i did not understand your explanations from the beginning,
    at the end they pointed me the right way.



    Uffbasse !
    #13
    xiaofan
    Super Member
    • Total Posts : 6247
    • Reward points : 0
    • Joined: 2005/04/14 07:05:25
    • Location: Singapore
    • Status: offline
    RE: Bare Minimum Isochronous Transfer using SPP 2008/10/13 06:15:21 (permalink)
    0
    Is it working now? If yes, maybe you want to attach the working code. Thanks.

      USB_Links and libusb
    #14
    vloki
    Jo, alla!
    • Total Posts : 6801
    • Reward points : 0
    • Joined: 2007/10/15 00:51:49
    • Location: Germany
    • Status: offline
    RE: Bare Minimum Isochronous Transfer using SPP 2008/10/13 06:21:41 (permalink)
    0
    ORIGINAL: xiaofan

    Is it working now? If yes, maybe you want to attach the working code. Thanks.
    I'm still playing gringringrin

    Uffbasse !
    #15
    vloki
    Jo, alla!
    • Total Posts : 6801
    • Reward points : 0
    • Joined: 2007/10/15 00:51:49
    • Location: Germany
    • Status: offline
    RE: Bare Minimum Isochronous Transfer using SPP 2008/10/13 23:38:00 (permalink)
    0
    OK, here are new versions of firmware an test code (libUSB)

    <edit> please change in "usb_descriptors.c"

        ISO_EP_SIZE,0x01,                //size
    >>
        ISO_EP_SIZE,                //size
        ISO_EP_SIZE/256,            //size


    post edited by vloki - 2008/10/13 23:56:50

    Uffbasse !
    #16
    stefanopod
    Super Member
    • Total Posts : 1285
    • Reward points : 0
    • Joined: 2007/06/25 02:33:59
    • Location: Bologna,Italy
    • Status: offline
    RE: Bare Minimum Isochronous Transfer using SPP 2009/01/14 04:17:29 (permalink)
    0
    Hi vloki, I downloaded your code and I met this remark:
    do not add time edacious functions !!!
    I couldn't find "edacious" in any english dictionary.
    My only clue is "edere" in latin for eating, that is edacious=hungry.
    I know you are a professor, but your speech has to be easy; you aren't a professor for professors, I guess.
    This point omitted, your experiment is very interesting.

    provando e riprovando
    #17
    vloki
    Jo, alla!
    • Total Posts : 6801
    • Reward points : 0
    • Joined: 2007/10/15 00:51:49
    • Location: Germany
    • Status: offline
    RE: Bare Minimum Isochronous Transfer using SPP 2009/01/14 05:06:04 (permalink)
    0
    gringringrin

    1. my English dictionary (the one I got "edacious" from wink)
    gave me 4 translations for this word.

    edacious  adj. rare

    gierig - avido
    gefräßig - vorace
    verzehrend - edace adj. anche  [fig.raro
    unersättlich - insaziabile

    2. I'm not a professor - staff engineer only gringringringringringringringrin.
      (therefore sometimes pick improper words from dictionaries )


    <edit> ... just noticed the "rare"  Smile

    Galleries HardWare|SoftWare|PIC USB related web sites

    post edited by vloki - 2010/07/11 05:45:04

    Uffbasse !
    #18
    stefanopod
    Super Member
    • Total Posts : 1285
    • Reward points : 0
    • Joined: 2007/06/25 02:33:59
    • Location: Bologna,Italy
    • Status: offline
    RE: Bare Minimum Isochronous Transfer using SPP 2009/01/14 07:23:39 (permalink)
    0
    My translation wasn't so bad. But my dictionaries are poor.
    I was wrong about your being a professor. I apologize.
    I was impressed from your discussions with Mr.Muzhd (he *is* a professor, don't say he isn't);  where has he gone? Probably he's busy in his academical duties.

    provando e riprovando
    #19
    DarioG
    Allmächtig.
    • Total Posts : 54081
    • Reward points : 0
    • Joined: 2006/02/25 08:58:22
    • Location: Oesterreich
    • Status: offline
    RE: Bare Minimum Isochronous Transfer using SPP 2009/01/14 14:24:51 (permalink)
    0
    wonderful gringrin

    GENOVA :D :D ! GODO
    #20
    Page: 12 > Showing page 1 of 2
    Jump to:
    © 2019 APG vNext Commercial Version 4.5