I have been doing some reading of libftdi source, libusb docs, usb primer and FTDI docs and I gathered the following: FTDI : - The device will copy the contents of the readbuffer to the computer when the line state changes (BREAK) or when the buffer is full. libftdi: - uses libusb_fill_bulk_transfer() or libusb_bulk_transfer_submit(), both will start trying to fullfill the data request regardless of the 'stage' of reception and will continue until the length requested is fullfilled, again regardless of actual packet length. libusb: - has libusb_fill_interrupt_transfer() for interrupt transfers ( http://www.beyondlogic.org/usbnutshell/usb4.shtml)
I may be wrong but it sounds to me like for this case interrupt transfers would be ideal since they should happen whenever a brake comes along regardless of whether or not the broadcasting party was sending a 513 byte packet or just a 25 byte packet. Has anyone ever played with the interrupt transfer instead of bulk transfers? Or am I bending a standard to something it is not....? Thanks for the help & input, Eli 2014-05-10 20:53 GMT+03:00 E.S. Rosenberg < [email protected]>: > When I have time I would like to see what causes this problem (bug?), but > I have no experience with this type of debugging so I would very much > appreciate it if people with more experience on this list can give pointers. > > Currently I assume I will download FTD2XX and compile against it and run > both libftdi and FTD2XX through gdb and try to find differences (hoping > that they haven't obfuscated/optimized out the needed debug info), but if > there are better methods... > > Thanks, > Eli > > > 2014-05-09 13:27 GMT+03:00 E.S. Rosenberg < > [email protected]>: > > 2014-05-09 12:25 GMT+03:00 Rui Barreiros <[email protected]>: >> >> Hi, >>> >>> I was never able to solve that issue, I just gave up on reading DMX with >>> any FTDI device using software and went the MCU path by using AVR (that >>> particular project was an ATMega8). >>> >>> The problem was not chip specific in my case, because in windows using >>> FTDI D2XX direct driver implementation over windows I managed to properly >>> parse the DMX signal and read it without any complication, but since I >>> needed it to work under linux I had to abandon it and go the MCU route. >>> >> Hi Rui, >> Thanks for the response! I asked on the OLA IRC channel if someone had >> your details but this also works :) >> >>> >>> I didn't research enough to figure out where the problem lies (libusb, >>> libftdi, etc) due to time constraints. >>> >> What you say here at least already helps a lot because it means it's >> something in libftdi/libusb/linux and that it's something we can fix... >> >>> >>> Good luck. >>> >> Thanks! >> Eli >> >>> >>> >>> On 05/08/2014 11:29 PM, E.S. Rosenberg wrote: >>> >>> >>> 2014-05-09 1:27 GMT+03:00 E.S. Rosenberg < >>> [email protected]>: >>> >>>> Hi all, >>>> >>>> Several years ago Rui Barreiros already posted a question on the >>>> subject which at the time doesn't seem to have been resolved and I am >>>> running into the same problem more or less: >>>> >>>> The DMX packet is read but ends up shifted over different amounts of >>>> bit every read. >>>> >>>> I currently suspect that this is all dependent on when the OS issues >>>> the ftdi_read_data() call, I suspect this because when I ran my test >>>> program using gdb the shifts were a lot more extreme (almost 0.5 packet) >>>> then when it was running directly. >>>> >>>> The packet itself is basically: >>>> 1. BREAK (>= 88us of LOW) >>>> 2. MAB (>= 8us HIGH) >>>> 3. 25-513 data slots (1b start HIGH, 8b data, 2b STOP HIGH each) >>>> >>>> So my question is: Is there any way to 'allign' the reads to the >>>> break+mab? >>>> >>>> attached is my modified version of the serial_test.c example. >>>> >>>> Side questions: >>>> - Can someone on the list explain the different flow control options? >>>> - What is the RTS? >>>> >>>> Thanks, >>>> Eliyahu - אליהו >>>> >>> >>> I meant to also add a link to the other thread: >>> >>> http://developer.intra2net.com/mailarchive/html/libftdi/2012/msg00171.html >>> >>> The device I am using is a USB-COM485-Plus4 >>> >>> Thanks, >>> Eli >>> >>> ------------------------------ >>> >>> *libftdi* - see http://www.intra2net.com/en/developer/libftdi for >>> details. >>> To unsubscribe send a mail to >>> [email protected] >>> >>> >>> >>> -- >>> >>> *Rui Barreiros* >>> [email protected] >>> Tlm: +351 962 356 020 >>> >>> Rua Alminhas das Cais, 950 >>> 4410-497 Serzedo VNG >>> Portugal >>> NIF: 506 107 523 >>> Tlm: +351 968 015 215 >>> Tlf: +351 227 625 805 >>> Fax: +351 227 534 304 >>> [email protected] >>> >>> >>> >>> ------------------------------ >>> >>> *libftdi* - see http://www.intra2net.com/en/developer/libftdi for >>> details. >>> To unsubscribe send a mail to >>> [email protected] >>> >>> >> > -- libftdi - see http://www.intra2net.com/en/developer/libftdi for details. To unsubscribe send a mail to [email protected]
