Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Switching between SPI modes on one port #106

Closed
jspeiser opened this issue Sep 25, 2018 · 6 comments
Closed

Switching between SPI modes on one port #106

jspeiser opened this issue Sep 25, 2018 · 6 comments

Comments

@jspeiser
Copy link

I'm trying to use an FT232H to control a device that uses SPI mode 3 for writes and mode 1 for reads (both with the same chip select). Is there any existing way to do this with pyftdi? Looking at the code, it seem like I could change this line to check for chip select/mode combinations, but I'd like to avoid spinning a custom version of pyftdi if possible.

@eblot
Copy link
Owner

eblot commented Sep 25, 2018

Hi,

I've never heard about an asymmetric-mode SPI slave up to now, but SPI being all but normalised, this is just another awkward combination :-)

PyFtdi/SPI does not support this for now.

I would avoid tweaking this line - if I get it right your idea is to create two SpiPort, one for each direction?. It would not work with multithreaded app and could create subtile issues.

I guess PyFtdi could be modified to change the clock/polarity between two data transfers...

What kind of slave do you need to use?

@jspeiser
Copy link
Author

Yeah, using two SpiPorts was the idea. I don't think my application will ever be multithreaded, but it's a good point, especially if the change ends up in the mainstream code.

Are you suggesting that a method be added to SpiPort to change the mode?

Could you explain what you mean by "what kind of slave" I need? I wasn't aware there were different types of slaves outside of their modes.

@eblot
Copy link
Owner

eblot commented Sep 27, 2018

Are you suggesting that a method be added to SpiPort to change the mode?

Yes, it could be an option.

But if CPOL change depending on the direction, and if /CS is also inverted it would likely be easier to add two HW inverters and drive the former with a FTDI GPIO, as it seems your HW is very specific...

Sorry, by "kind of slave" I meant which HW slave are you using, I'd be interested to know if this is a very specific/custom device or some kind of devices is easily available on the market - in other words, is it a publicly available device?

@eblot
Copy link
Owner

eblot commented Sep 27, 2018

See also #86, as this is a long lasting ticket I've not been able to test yet, but it might help you.

@jspeiser
Copy link
Author

jspeiser commented Sep 27, 2018

Actually, the device supports two different SPI protocols and we changed our minds about which one we'll use, so the chip select is no longer inverted (though there is still the different polarities for reads and writes). One of my coworkers controlled a related device in the past by switching modes between reads and writes (he used the python-periphery library which supports that), so I do think that's probably still the best option.

The device is an RF synthesizer by Hittite (part number HMC833LP6GE; I linked to the datasheet in my original post). It is technically publicly available, but it's only used in niche embedded systems. Normally you wouldn't use something like an FTDI chip to control it, but this is just a prototype and using python to control it is easier than using a microcontroller.

I've made what I believe are all the necessary changes to switch modes (basically just move some stuff from SpiPort's __init__ into a method), but since we don't have our board yet I can't test it. Is this a change you'd consider accepting a pull request for, once I've tested it?

@eblot
Copy link
Owner

eblot commented Nov 21, 2019

Implemented as abe7eb6

@eblot eblot closed this as completed Nov 21, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants