-
Notifications
You must be signed in to change notification settings - Fork 76
CS Assertion polarity - any support for active high devices? #71
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
Comments
@tannewt any thoughts? there are some chips having inverted-polarity even tho its quite rare. |
I would do it as |
Sounds like a plan - but I'm 100% less confident about a PR against the shared binding stuff. I can take a swing at it, but I'll need to review the contribution guidance first and understand how / if I should link the PRs between the two repositories??? |
Does this look like what you were expecting @tannewt?
and
|
Reference adafruit#71 Missed the self.cs_active_value
Reference adafruit/Adafruit_CircuitPython_BusDevice#71 Also update the enum and call to the constructor
I've forked both |
I'm in the process of building circuitpython under Ubuntu on RaspberryPi (my target platform will be Raspberry Pi OS but I took the guidance on the learn site at face value).
Sorry if these are dumb questions, but this is all still rather new to me... |
The search path looks at the root folder before looking at the "frozen" folder, so if you put you new version in the root folder "/" on the CIRCIUTPY drive, it will be used instead of the "frozen" version. |
ah -- but I forgot, then there is now a "core module" for bus_device and I am not sure how you override that , someone more familiar with that my be able to help. Sorry for any confusion. You may need to disable CIRCUITPY_BUSDEVICE in your build so it uses the Python Module instead fo the Core Module. |
Reference adafruit/Adafruit_CircuitPython_BusDevice#71 Also update the enum and call to the constructor MIssed the .h file update the shared module also. Argh
Reference adafruit/Adafruit_CircuitPython_BusDevice#71 Add a new parameter cs_active_value for devices that require CS to use "active high" logic.
Thanks @jeryneedell. I'm wondering if I need to follow the build instructions, but then after pulling the submodules in from the default location, I remove the Adafruit_CircuitPython_BusDevice directory and clone from my repo with the patches (before compiling)? |
Reference adafruit#71 Enables SPIDevice to be used for things like the Sitronix ST7920 LCD display which requires CS to be pulled high during commands or data transfers. Adds a new attribute (cs_active_value) to set the preferred logic for the CS line. Default false (active low).
I've opened a PR against this repo and also adafruit/circuitpython for the corresponding shared module / shared binding code. Treat me gently as I'm struggling to test the code - while I was able to compile cleanly for a RP2040 board, I'm baffled as to how I actually take the compiled circuitpython code and test it on my target platform (Raspberry Pi 3B+)? |
Reference adafruit#71 Enables SPIDevice to be used for things like the Sitronix ST7920 LCD display which requires CS to be pulled high during commands or data transfers. Adds a new attribute (cs_active_value) to set the preferred logic for the CS line. Default false (active low). Argh
Reference adafruit#71 Enables SPIDevice to be used for things like the Sitronix ST7920 LCD display which requires CS to be pulled high during commands or data transfers. Adds a new attribute (cs_active_value) to set the preferred logic for the CS line. Default false (active low).
Reference adafruit/Adafruit_CircuitPython_BusDevice#71 Add a new parameter cs_active_value for devices that require CS to use "active high" logic. Update mpconfigboard.mk to disable pyb_nano_v2 from core build as its flash is too small now.
Reference adafruit#71 Enables SPIDevice to be used for things like the Sitronix ST7920 LCD display which requires CS to be pulled high during commands or data transfers. Adds a new attribute (cs_active_value) to set the preferred logic for the CS line. Default false (active low). Make examples use f-strings to resolve build failure in unrelated code
Reference adafruit#71 Enables SPIDevice to be used for things like the Sitronix ST7920 LCD display which requires CS to be pulled high during commands or data transfers. Adds a new attribute (cs_active_value) to set the preferred logic for the CS line. Default false (active low). Make examples use f-strings to resolve build failure in unrelated code
Reference adafruit#71 Enables SPIDevice to be used for things like the Sitronix ST7920 LCD display which requires CS to be pulled high during commands or data transfers. Adds a new attribute (cs_active_value) to set the preferred logic for the CS line. Default false (active low). Make examples use f-strings to resolve build failure in unrelated code
Reference adafruit#71 Enables SPIDevice to be used for things like the Sitronix ST7920 LCD display which requires CS to be pulled high during commands or data transfers. Adds a new attribute (cs_active_value) to set the preferred logic for the CS line. Default false (active low). Make examples use f-strings to resolve build failure in unrelated code
Reference adafruit#71 Enables SPIDevice to be used for things like the Sitronix ST7920 LCD display which requires CS to be pulled high during commands or data transfers. Adds a new attribute (cs_active_value) to set the preferred logic for the CS line. Default false (active low).
There was discussion in the comments for #1 about adding the ability to support CS lines that require active high, understandably in the minority so deferred. I'm currently trying to build an SPIDevice to talk to an ST7920 graphic LCD panel, and have code that adapts the venerable https://github.com/JMW95/pyST7920, but fails for (I'm assuming) this reason.
Is there any appetite for a PR that implements an additional parameter, and inverts the logic in
__enter__()
and__leave__()
when requested?I'm thinking about something like:
and then in
__enter__()
and
__leave__()
Of course the alternative of inverting the signal in hardware remains an option, however unappealing, if this is a permanently closed topic?
The text was updated successfully, but these errors were encountered: