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.
- Can someone on the list explain the different flow control options?
- What is the RTS?
Eliyahu - אליהו
serial_test.c (6K) Download Attachment
2014-05-09 1:27 GMT+03:00 E.S. Rosenberg <[hidden email]>:
I meant to also add a link to the other thread:
The device I am using is a USB-COM485-Plus4
I can't comment on the DMX issue but here's a handy page for the flow control signals:
RTS/CTS and DTR/DSR are harware signals where as XON/XOFF usually fall under 'software' flow control. I have only used RTS/CTS on the FT23R to date. I don't know if there's a particular reason to use DTR/DSR vs RTS/CTS unless you're interfacing with some legacy hardware that uses it.
On 5/8/2014 5:29 PM, E.S. Rosenberg wrote:
2014-05-09 7:28 GMT+03:00 Ryan Tennill <[hidden email]>:
Thanks, that was very useful!
I am communicating using EIA-485 as physical layer but DMX-512A has no concept of flowcontrol so setting it to off and RTS to off seems to be the correct thing.
I started looking at the stream reading example figuring that maybe that way I'd do the Break/MAB detection on the host but it seems the FT4232HQ doesn't support synchronous FIFO mode....
Either way the break/MAB do seem to be detected properly since as far as I can tell they don't add data (gibberish) to the captured data, it's just that I lack a way of reading instantly the moment a break is reached (and consequentially a whole packet is in the buffer).
Thanks so far,
In reply to this post by E.S. Rosenberg
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.
I didn't research enough to figure out where the problem lies (libusb, libftdi, etc) due to time constraints.
On 05/08/2014 11:29 PM, E.S. Rosenberg wrote:
2014-05-09 12:25 GMT+03:00 Rui Barreiros <[hidden email]>:
Thanks for the response! I asked on the OLA IRC channel if someone had your details but this also works :)
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...
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...
2014-05-09 13:27 GMT+03:00 E.S. Rosenberg <[hidden email]>:
Thanks for the help & input,
Or am I bending a standard to something it is not....?
Has anyone ever played with the interrupt transfer instead of bulk transfers?
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 libusb_fill_interrupt_transfer() for interrupt transfers (http://www.beyondlogic.org/usbnutshell/usb4.shtml)
- 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.
- The device will copy the contents of the readbuffer to the computer when the line state changes (BREAK) or when the buffer is full.
I have been doing some reading of libftdi source, libusb docs, usb primer and FTDI docs and I gathered the following:FTDI :
2014-05-10 20:53 GMT+03:00 E.S. Rosenberg <[hidden email]>:
|Free forum by Nabble||Edit this page|