Allow basic support for libFTDI1.3

[mcprat]

Between libFTDI versions 1.2 and 1.3. The largest difference is a simple syntax difference on one function, where they removed one of the three arguments. Simply try the one for <=1.2, and if that throws a TypeError, try the syntax for 1.3+

here is a screenshot: https://www.dropbox.com/s/m7a1ybx3ss2jotg/Screenshot%202019-03-11%2021.30.17.png?dl=0

This change is present in another commit #66 , but with other changes. I am hoping that this simpler commit can be accepted easily...

Signed-off-by: Michael Pratt mpratt51@gmail.com

[mcprat]

@ladyada @tdicola Its also worth noting how extremely annoying this error is. In order to fix it, the .egg has to be deleted, this change has to be made, and then the entire library reinstalled

[ladyada]

thanks @mpratt14 ! we are looking to redo this library as part of Adafruit-Blinka, which will let all our new drivers work with FT232H - any volunteers are welcome as we are very slow going :)

[mcprat]

@ladyada I understand this library is seen as deprecated, but I disagree and I don't see a "redo" as necessary. If you mean simply fixing this library and then merging it with another, then sure why not. Except for whatever reason so many people on Mac are having issues, I have had little to no issues with this library on Windows with the FT232H. In fact, I would attribute most of my issues to hardware limits. I'm going to post an issue and another pull request soon and expand on that...

Otherwise, I'd like to be a part of development, but not sure how much I can contribute. My only use case so far is programming SPI flash chips for routers. I have a bunch of example code id like to share as well. Maybe we can open a folder in the root directory for "examples"

[ladyada]

a 'redo' to some extent is necessary if we want people to be able to connect a wide range of I2C and SPI devices - right now all our python drivers are py3 and written for the circuitpython API (which is what Blinka implements). the underlying stuff isn't so different, but how we expose the API will change - but for the better :)

[peci1]

Great, thanks for the fix. Is there gonna be a release to pypi soon?

[ladyada]

ahh - i have to figure out how to do that - our other repos are setup to use travis for releases (yay) but this one is ancient

@caternuson @kattni @siddacious are any of y'all skilled up in the magic of manual pypi deploys?

[peci1]

Thanks for trying... That would help us keep our setup as automated as possible.

[ladyada]

yeah sorry this repo is in a sad state :D

[mcprat]

@ladyada I understand this repo still needs a lot of work, but I still don't quite get it...

When you say "be able to connect to a wide range of I2C and SPI devices", do you mean adding support for more 'Master' devices, other than the FT232H, or making it easier to work with more 'Slave' devices, which you would use the FT232H to talk with?

I can work on the SPI capabilities until they are flawless, the rest is up to the script that the user writes, but I have no way to test I2C....

I'm actually getting ready to put another pull request of my own code

[kattni]

@ladyada I am not.

[siddacious]

@ladyada I am not currently but I could certainly look into it

[siddacious]

Seems fairly straightforward: https://packaging.python.org/tutorials/packaging-projects/

[ladyada]

@siddacious we could do that or we could apply the current travis packaging here, either way! ill let you attack it :)

[caternuson]

late to the party......but also no on manual pypi. @siddacious you going to tackle this?

[siddacious]

@caternuson I was going to but if you're ready and willing by all means go ahead

[caternuson]

not really - just checking to see who's on it. looks like you kindly offered first. please, have at it. or attack it! :)

[peci1]

@siddacious Friendly ping on the release.

[siddacious]

@peci1 Oh man, my bad this totally slipped through the cracks. I'll do it now