This repository was archived by the owner on Sep 30, 2019. It is now read-only.
fix unwanted SPI cs assert during startup #53
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
First set the chipselect to high then change the pin to output. By fixing the order the pin does not go low and then high for a short time.
mcprat
pushed a commit
to mcprat/Adafruit_Python_GPIO
that referenced
this pull request
Apr 3, 2019
This is a more direct fix of adafruit#53 I have tested the change from adafruit#53 and it is true that Chip Select currently drops LOW during setup() method. I realized, however, that it starts out HIGH before that (when you first power on the FT232H, aka idle state), so instead of using the set_high() method to make sure it's HIGH, there must be a way to keep it in that state while it is being set as an output pin.... related reading: general idea in section 4.5 of AN_135: MPSSE Basics https://www.ftdichip.com/Support/Documents/AppNotes/AN_135_MPSSE_Basics.pdf commands described in section 3.6 of AN_108: Command Processor for MPSSE https://www.ftdichip.com/Support/Documents/AppNotes/AN_108_Command_Processor_for_MPSSE_and_MCU_Host_Bus_Emulation_Modes.pdf In fact, the idle state of pins on the board is from 2.1V to 2.7V for idle HIGH and right after the GPIO assignment command passes, it jumps to either -0.02V for active LOW or 2.9V for active HIGH. In a debug session you see this occur right after ftd1.write_data(*args), from FT232H.write() The setup method leads to the mpsse_gpio method which writes direction and level state to the FTDI. That method sets every GPIO at the same time using two commands 0x80: describes the values of pins, and direction in or out, for those pins to be set to low 0x82: describes the values of pins, and direction in or out, for those pins to be set to high Bottom line: we shouldn't need two separate methods to simply keep the default state of the CS pin to high So when looking at the code that develops this command and arguments into a single string, it looks like there's a line missing, which to me would be the proper fix. After this change, all GPIO pins set to output are HIGH by default. This allows the line with method set_high() to no longer be necessary for the __init__ method for SPI. So again, adding this line prevents CS from jumping to LOW and then HIGH during the __init__method of SPI. I am assuming that there is no reason that output GPIOs should not default to HIGH in any other use case. After all, if a pin is being used by another use case, that would also have its own methods to further take control of the pins.... I don't know if there is a reason for this, but there is a missing line to define the default state of Output pins. This behavior matches exactly with the power-up or idle of the FT232H before it is accessed by the library at all, where all pins are originally set to HIGH Tested on my own FT232H breakout with Python 2.7, using debug to step into the SPI instantiation line of one of my scripts. Signed-off-by: Michael Pratt <mpratt51@gmail.com>
mcprat
pushed a commit
to mcprat/Adafruit_Python_GPIO
that referenced
this pull request
Apr 3, 2019
This is a more direct fix of adafruit#53 I have tested the change from adafruit#53 and it is true that Chip Select currently drops LOW during setup() method. I realized, however, that it starts out HIGH before that (when you first power on the FT232H, aka idle state), so instead of using the set_high() method to make sure it's HIGH, there must be a way to keep it in that state while it is being set as an output pin.... related reading: general idea in section 4.5 of AN_135: MPSSE Basics https://www.ftdichip.com/Support/Documents/AppNotes/AN_135_MPSSE_Basics.pdf commands described in section 3.6 of AN_108: Command Processor for MPSSE https://www.ftdichip.com/Support/Documents/AppNotes/AN_108_Command_Processor_for_MPSSE_and_MCU_Host_Bus_Emulation_Modes.pdf In fact, the idle state of pins on the board is from 2.1V to 2.7V for idle HIGH and right after the GPIO assignment command passes, it jumps to either -0.02V for active LOW or 2.9V for active HIGH. In a debug session you see this occur right after ftd1.write_data(*args), from FT232H.write() The setup method leads to the mpsse_gpio method which writes direction and level state to the FTDI. That method sets every GPIO at the same time using two commands 0x80: describes the values of pins, and direction in or out, for those pins to be set to low 0x82: describes the values of pins, and direction in or out, for those pins to be set to high Bottom line: we shouldn't need two separate methods to simply keep the default state of the CS pin to high So when looking at the code that develops this command and arguments into a single string, it looks like there's a line missing, which to me would be the proper fix. After this change, all GPIO pins set to output are HIGH by default. This allows the line with method set_high() to no longer be necessary for the __init__ method for SPI. So again, adding this line prevents CS from jumping to LOW and then HIGH during the __init__method of SPI. I am assuming that there is no reason that output GPIOs should not default to HIGH in any other use case. After all, if a pin is being used by another use case, that would also have its own methods to further take control of the pins.... I don't know if there is a reason for this, but there is a missing line to define the default state of Output pins. This behavior matches exactly with the power-up or idle of the FT232H before it is accessed by the library at all, where all pins are originally set to HIGH Tested on my own FT232H breakout with Python 2.7, using debug to step into the SPI instantiation line of one of my scripts. Signed-off-by: Michael Pratt <mpratt51@gmail.com>
|
@frankalicious See #103 This is an alternative way to fix the same problem and cleaner code, unless there is a reason the line I added is missing... |
ladyada
approved these changes
Apr 4, 2019
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
First set the chipselect to high then change the pin to output.
By fixing the order the pin does not go low and then high for a short
time.