Check AnalogIn and AnalogOut to make sure they are all 16 bit #14
Comments
tannewt
changed the title
jepler
added a commit
to jepler/circuitpython
that referenced
this issue
Oct 1, 2020
It was incorrect to NULL out the pointer to our heap allocated buffer in `reset`, because subsequent to framebuffer_reset, but while the heap was still active, we could call `get_bufinfo` again, leading to a fresh allocation on the heap that is about to be destroyed. Typical stack trace: ``` #1 0x0006c368 in sharpdisplay_framebuffer_get_bufinfo #2 0x0006ad6e in _refresh_display #3 0x0006b168 in framebufferio_framebufferdisplay_background #4 0x00069d22 in displayio_background adafruit#5 0x00045496 in supervisor_background_tasks adafruit#6 0x000446e8 in background_callback_run_all adafruit#7 0x00045546 in supervisor_run_background_tasks_if_tick adafruit#8 0x0005b042 in common_hal_neopixel_write adafruit#9 0x00044c4c in clear_temp_status adafruit#10 0x000497de in spi_flash_flush_keep_cache adafruit#11 0x00049a66 in supervisor_external_flash_flush adafruit#12 0x00044b22 in supervisor_flash_flush adafruit#13 0x0004490e in filesystem_flush adafruit#14 0x00043e18 in cleanup_after_vm adafruit#15 0x0004414c in run_repl adafruit#16 0x000441ce in main ``` When this happened -- which was inconsistent -- the display would keep some heap allocation across reset which is exactly what we need to avoid. NULLing the pointer in reconstruct follows what RGBMatrix does, and that code is a bit more battle-tested anyway. If I had a motivation for structuring the SharpMemory code differently, I can no longer recall it. Testing performed: Ran my complicated calculator program over multiple iterations without observing signs of heap corruption. Closes: adafruit#3473
jepler
added a commit
to jepler/circuitpython
that referenced
this issue
Oct 3, 2020
This brings in the following, and updates us to the 1.0.4 release tag: Submodule lib/protomatter 2a1ba8fa4..5f07ec618: > Bumping version for release > Merge pull request adafruit#21 from makermelissa/master > Merge pull request adafruit#20 from makermelissa/master > Merge pull request adafruit#18 from jepler/fix-cpy-3184 > Merge pull request adafruit#14 from hierophect/cpy-timer-allocator We previously had the _changes_ of jepler/fix-cpy-3184 and hierophect/cpy-timer-allocator but not their merge commits. The only other changes in protomatter were one formatting change in the core, plus several Arduino sketches. So this should make no practical difference for CPy.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The DAC object allows passing to write a value that's greater than the DAC supports, like 1024, 9999, etc. We should catch this and fail with an out of bounds error. Example:
Interestingly a write of 9999 outputs a voltage around 2.5v when the reference is 3.3v. Values within the 10-bit range (0-1023) have the expected out and are all good, so this is a minor issue.
The text was updated successfully, but these errors were encountered: