Thanks, Chris. I'll check it out. Paul
Paul E Ourada Principal/Owner BluSkai Systems, LLC [email protected] (m) 303-396-2872 ________________________________ From: Chris Morgan <[email protected]> Sent: Tuesday, February 19, 2019 11:03 AM To: Paul E Ourada Cc: [email protected] Subject: Re: libftdi bitbang events? Hi Paul. On Feb 19, 2019, at 12:20 PM, Paul E Ourada <[email protected]<mailto:[email protected]>> wrote: ________________________________ From: Chris Morgan <[email protected]<mailto:[email protected]>> Sent: Friday, February 15, 2019 6:02 PM To: [email protected]<mailto:[email protected]> Subject: Re: libftdi bitbang events? Hi Paul. Usb is host driven, which means that the host is continually polling the device to see if it has data, you can make it event driven on the application side. Huh. I wonder how I missed this factoid. I guess I just assumed that since devices are discovered automagically by the OS, there must be some event driven mechanism. In our case we had a complex mpsse sequence that was waiting for a signal to transition and then we would issue several i2c read operations (until there was no data left to read or we ran out of read operations) and send the data back as a group. If I remember correctly we ended up using the usb handle directly at times. We were pulling touch events from an i2c touch controller and while we had some initial response latency due to usb polling rates we had really good performance with this approach. Are you looking to identify a signal transition? You could make use of mpsse as we did (if you have an FTDI with an mpsse engine available). Then you could wait until the usb operation completed in your code rather than polling. Some considerations: - What is your desired latency? - Do you expect multiple signal transitions to occur? If sp, how often? This could be workable. We are using the 4232H device, which has mpsse functionality. Essentially, there is a momentary switch closure which we'd like to detect a leading edge transition. The switch input is used to turn on WiFi for a short period of time, which timeout will be handled in the software. Another similar momentary switch is to be used to tell the Rpi to configure itself in some known default application state. So to answer your question, I don't think that latency is too terribly important. Nor do I think that we expect to need to handle multiple transitions since both of these operations are essentially one-shot. So, if you are willing and/or able to share more details about how you set this up, I'd be a rapt listener. :D Thanks, Paul Ahh gotcha, the momentary switch could be an issue depending on your polling time so edge triggered makes the most sense. We got there through a bit of a route. First there is the FTDI documentation for mpsse, https://www.ftdichip.com/Support/Documents/AppNotes/AN_108_Command_Processor_for_MPSSE_and_MCU_Host_Bus_Emulation_Modes.pdf. Then we looked at how the commands were built and sent from libmpsse, I think based on this library, https://github.com/devttys0/libmpsse/blob/master/src/mpsse.c It looks like you’d want a WAIT on io high or low command, and then maybe a a read data bits high or low command after that. It wasn’t the most elegant to build. What we want to do, and we never did build it, was a library that would build up a sequence of commands in a more natural way. The libmpsse library, if this is the same one, issued the mpsse command immediately. What we wanted was to build a command stream and then execute it. It may be there are libraries that do this today. For your use it may be easy enough to build the command by hand, as its only two op codes, and look at how libmpsse sends them to the FTDI. I wish I could recall more of the details or show code, it was done for a closed source effort a handful of years ago. Chris -- libftdi - see http://www.intra2net.com/en/developer/libftdi for details. To unsubscribe send a mail to [email protected]
