A couple of speedups #48
Merged
Conversation
This file contains hidden or 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
|
👋 Thanks for this pull request! Unfortunately, it looks like the automated continuous integration (CI) test(s) failed. These can be tricky to fix so we've written a guide on how to fix them locally. It has pages about running pre-commit locally and another about building the docs locally with sphinx. Thanks for contributing to CircuitPython! If you have more questions, feel free to join the Adafruit Discord and post in #circuitpython-dev. |
ladyada
approved these changes
Mar 22, 2022
|
Hey @PaintYourDragon I already merged this, but I realize it would be really helpful if you could create an example file of using this new functionality, particularly the |
adafruit-adabot
added a commit
to adafruit/Adafruit_CircuitPython_Bundle
that referenced
this pull request
Mar 29, 2022
Updating https://github.com/adafruit/Adafruit_CircuitPython_BluefruitSPI to 1.1.9 from 1.1.8: > Merge pull request adafruit/Adafruit_CircuitPython_BluefruitSPI#23 from Neradoc/fix-documentation-params > Fixed readthedocs build > Consolidate Documentation sections of README Updating https://github.com/adafruit/Adafruit_CircuitPython_CircuitPlayground to 5.0.4 from 5.0.3: > Renamed advanced_examples/ to circuitplayground_advanced_examples > Fixed readthedocs build > Consolidate Documentation sections of README Updating https://github.com/adafruit/Adafruit_CircuitPython_CLUE to 3.0.4 from 3.0.3: > Renamed advanced_examples/ to clue_advanced_examples/ > Fixed readthedocs build > Consolidate Documentation sections of README Updating https://github.com/adafruit/Adafruit_CircuitPython_FONA to 2.1.6 from 2.1.5: > Merge pull request adafruit/Adafruit_CircuitPython_FONA#16 from tekktrik/doc/add-typing > Fixed readthedocs build > Consolidate Documentation sections of README Updating https://github.com/adafruit/Adafruit_CircuitPython_IS31FL3731 to 3.2.3 from 3.2.2: > Merge pull request adafruit/Adafruit_CircuitPython_IS31FL3731#48 from adafruit/pb-cm > Fixed readthedocs build > Consolidate Documentation sections of README Updating https://github.com/adafruit/Adafruit_CircuitPython_OV5640 to 1.1.0 from 1.0.5: > Merge pull request adafruit/Adafruit_CircuitPython_OV5640#14 from adafruit/seesawify > Fixed readthedocs build Updating https://github.com/adafruit/Adafruit_CircuitPython_RPLIDAR to 1.2.5 from 1.2.4: > Merge pull request adafruit/Adafruit_CircuitPython_RPLIDAR#24 from adafruit/adabotify Updating https://github.com/adafruit/Adafruit_CircuitPython_SD to 3.3.8 from 3.3.7: > Merge pull request adafruit/Adafruit_CircuitPython_SD#46 from Neradoc/fix-documentation-params > Fixed readthedocs build > Consolidate Documentation sections of README Updating https://github.com/adafruit/Adafruit_CircuitPython_STMPE610 to 1.3.2 from 1.3.1: > Rename stmpe610_touch_calibrator_.py to stmpe610_touch_calibrator.py > Update and rename touch_calibrator_stmpe610.py to stmpe610_touch_calibrator_.py > Fixed readthedocs build > Consolidate Documentation sections of README Updating https://github.com/adafruit/Adafruit_CircuitPython_TFmini to 1.2.8 from 1.2.7: > Merge pull request adafruit/Adafruit_CircuitPython_TFmini#11 from Neradoc/fix-documentation > Fixed readthedocs build > Consolidate Documentation sections of README Updating https://github.com/adafruit/Adafruit_CircuitPython_GC_IOT_Core to 3.1.2 from 3.1.1: > Merge pull request adafruit/Adafruit_CircuitPython_GC_IOT_Core#22 from Neradoc/fix-documentation-params-and-code-blocks Updating https://github.com/adafruit/Adafruit_CircuitPython_AdafruitIO to 5.6.4 from 5.6.2: > Merge pull request adafruit/Adafruit_CircuitPython_AdafruitIO#86 from Neradoc/fix-documentation-params-and-code-blocks > Merge pull request adafruit/Adafruit_CircuitPython_AdafruitIO#85 from tekktrik/dev/fix-missing-minimqtt-req Updating https://github.com/adafruit/Adafruit_CircuitPython_AzureIoT to 2.5.2 from 2.5.1: > Merge pull request adafruit/Adafruit_CircuitPython_AzureIoT#41 from adafruit/adabotify > Consolidate Documentation sections of README Updating https://github.com/adafruit/Adafruit_CircuitPython_binascii to 1.2.9 from 1.2.8: > Merge pull request adafruit/Adafruit_CircuitPython_binascii#14 from tekktrik/dev/fix-typing-to-bytes > Fixed readthedocs build > Consolidate Documentation sections of README Updating https://github.com/adafruit/Adafruit_CircuitPython_BLE to 8.2.3 from 8.2.2: > Changed capitalization to satisfy adabot Updating https://github.com/adafruit/Adafruit_CircuitPython_Dash_Dis to 1.1.3 from 1.1.2: > Renamed client_examples subdir > Fixed readthedocs build > Post-patch cleanup > Consolidate Documentation sections of README Updating https://github.com/adafruit/Adafruit_CircuitPython_MotorKit to 1.6.5 from 1.6.4: > Merge pull request adafruit/Adafruit_CircuitPython_MotorKit#43 from tekktrik/doc/add-typing > Fixed readthedocs build > Consolidate Documentation sections of README Updating https://github.com/adafruit/Adafruit_CircuitPython_PIOASM to 0.6.2 from 0.6.1: > Rename rotaryencoder.py to pioasm_rotaryencoder.py > Merge pull request adafruit/Adafruit_CircuitPython_PIOASM#39 from adafruit/adabotify > Fixed readthedocs build > Consolidate Documentation sections of README Updating https://github.com/adafruit/Adafruit_CircuitPython_PortalBase to 1.11.4 from 1.11.3: > Renamed adafruit_portalbase_simpletest.py to portalbase_simpletest.py > Moved example directory to examples
|
What’s it typically take for new releases to trickle through the system? pip3 on Raspberry Pi is still installing 3.2.2. |
|
Ah, nev mind, piwheels.org seems to be down and I think that has something to do with it. Will retry later. |
|
Hey @PaintYourDragon, looks like PyPI has it listed. You should be able to install it using pip. The latest latest version may require you to upgrade to Python 3.7+, but the changes made in this PR should be available regardless! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
A current project requires high-speed (full-frame animated) updates on 8 matrices on Raspberry Pi, split across two buses, but currently only manages less than 2 FPS. Since “soft” I2C on Pi is limited to about 200 KHz max, we can’t just crank up the frequency to compensate, so instead this PR proposes a couple of speed improvements:
Applicable to all devices: _init() takes a direct approach to initializing all registers, rather than going through things like the fill() function. Additionally, this now accepts an optional frames= kwarg, which can reduce the initialization to only those frames an application anticipates using (e.g. if doing double-buffered animation, one might only need frames 0 and 1). The changes yield about a 2X speedup if all 8 frames are initialized, or 9X if using just 2 (e.g. frames=(0,1)). This might seem unnecessary, but across 8 matrices it really adds up. This change does require a couple dozen extra bytes, but I’d call it inconsequential, this is only on startup before the application really gets to business.
Applicable to the Matrix class only: image() similarly takes some direct action, rather than iterating through pixel() every time. Yields about a 6X speedup, getting a bit over 10 FPS across 8 matrices, just adequate to be considered animation. This does require a couple hundred bytes extra…but…since image() implies the use of PIL, it’s by definition not running on a RAM-constrained microcontroller, and might likewise be considered inconsequential.