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]
