CircuitPython - a Python implementation for teaching coding with microcontrollers https://git.suspectdevices.com/suspect-devices/circuitpython/atom?h=3.0.1 2018-08-21T01:26:07+00:00 2018-08-21T01:26:07+00:00 Scott Shawcroft scott@tannewt.org 2018-08-21T01:26:07+00:00 urn:sha1:182a8d71206356a118c82ced9d6d7098c5a8ce75 Support Hallowing in 3.x 2018-08-21T01:04:35+00:00 Scott Shawcroft scott@tannewt.org 2018-08-21T01:04:35+00:00 urn:sha1:2b6b0ffcd249e2aaa2b5bef03d8bb67f0ba42245 2018-08-21T00:43:42+00:00 Scott Shawcroft scott@tannewt.org 2018-08-21T00:43:42+00:00 urn:sha1:4a8dd7e96d55306742bb410772dd9d411cf34864 Speed up zero neopixel pulses. 2018-08-21T00:04:46+00:00 Scott Shawcroft scott@tannewt.org 2018-08-21T00:04:46+00:00 urn:sha1:44de3d49a8d25f51b98aef8643dc500c32df2cf2 SK6812 on 5v is pickier than WS2812 on 5v. Hopefully fixes #1083. 2018-08-20T17:52:33+00:00 ladyada limor@ladyada.net 2018-08-14T17:04:33+00:00 urn:sha1:aeeb40e02c7f970fdbb7a04c89e02f5aee01b7c7 2018-08-20T17:52:24+00:00 Dan Halbert halbert@halwitz.org 2018-07-29T00:50:35+00:00 urn:sha1:1768057e874fdcfad7949f53ea5be4837e49a3a6 2018-08-09T04:36:33+00:00 Scott Shawcroft scott@tannewt.org 2018-08-09T04:36:33+00:00 urn:sha1:cac760aa6f9ea5ddb6dba019dc9c3482bb3f4a79 UART: Always allocate UART objects in the long-lived pool 2018-08-09T00:21:57+00:00 Jeff Epler jepler@unpythonic.net 2018-08-02T01:21:20+00:00 urn:sha1:b0e33f6a116ac75c6a26216224182529db78e0a3 This is not strictly needed in order for #1056 to be resolved, because the "make long-lived" machinery is unaware of this pointer. However, as UARTs are assumed to be long-lived, this change is beneficial because it moves the long-lived buffer into the upper memory area with other long-lived objects, instead of remaining in the low heap. 2018-08-09T00:21:57+00:00 Jeff Epler jepler@gmail.com 2018-07-31T01:49:20+00:00 urn:sha1:e1b4e9b7c7cdd7a022a5ab113b68c8fa6be2c74d Particularly when they have buffers that are written via IRQ or DMA, UART objects do not relocate gracefully. If such an object is relocated to the long-lived pool after its original creation, the IRQ or DMA will write to an unexpected location within the Python heap, leading to a variety of symptoms. The most frequent symptom is inability to read from the UART. Consider the particular case of atmel-samd: usart_uart_obj_t contains a usart_async_descriptor contains a _usart_async_device. In _sercom_init_irq_param the address of this contained _usart_async_device is assigned to a global array sercom_to_sercom_dev which is later used from the interrupt context _sercom_usart_interrupt_handler to store the received data in the right ring buffer. When the UART object is relocated to the long-lived heap, there's no mechanism to re-point these internal pointers, so instead take the cowardly way and allocate the UART object as long-lived. Happily, almost all UART objects are likely to be long-lived, so this is unlikely to have a negative effect on memory usage or heap fragmentation. Closes: #1056 2018-08-08T01:33:12+00:00 Dan Halbert halbert@halwitz.org 2018-08-08T01:33:12+00:00 urn:sha1:2e80f37709c9fd7b168b684452ec436c24651973 Retune neopixel timings on SAMD51. They were too slow.