2019-01-13 23:51:13 -05:00
|
|
|
/*
|
2021-05-06 09:22:35 -04:00
|
|
|
* This file is part of the CircuitPython project, https://github.com/adafruit/circuitpython
|
2019-01-13 23:51:13 -05:00
|
|
|
*
|
|
|
|
* The MIT License (MIT)
|
|
|
|
*
|
2021-07-08 17:31:10 -04:00
|
|
|
* Copyright (c) 2018 Rose Hooper
|
2019-01-13 23:51:13 -05:00
|
|
|
*
|
|
|
|
* Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
|
|
* of this software and associated documentation files (the "Software"), to deal
|
|
|
|
* in the Software without restriction, including without limitation the rights
|
|
|
|
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
|
|
* copies of the Software, and to permit persons to whom the Software is
|
|
|
|
* furnished to do so, subject to the following conditions:
|
|
|
|
*
|
|
|
|
* The above copyright notice and this permission notice shall be included in
|
|
|
|
* all copies or substantial portions of the Software.
|
|
|
|
*
|
|
|
|
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
|
|
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
|
|
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
|
|
|
* AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
|
|
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
|
|
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
|
|
|
|
* THE SOFTWARE.
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
|
|
#include "py/obj.h"
|
2020-01-24 21:23:07 -05:00
|
|
|
#include "py/objstr.h"
|
|
|
|
#include "py/objtype.h"
|
2019-01-13 23:51:13 -05:00
|
|
|
#include "py/runtime.h"
|
2021-07-16 13:31:40 -04:00
|
|
|
#include "shared-bindings/adafruit_pixelbuf/PixelBuf.h"
|
2019-01-13 23:51:13 -05:00
|
|
|
#include <string.h>
|
_pixelbuf: Increase performance of brightness-scaling
On the Pico, this increases the "fill rate" of
pixels[:] = newvalues
considerably. On a strip of 240 RGB LEDs, auto_write=False, the timings
are:
|| Brightness || Before || After || Improvement ||
|| 1.0 || 117 kpix/s || 307 kpix/s || 2.62x ||
|| 0.07 || 117 kpix/s || 273 kpix/s || 2.33x ||
It's worth noting that even the "before" rate is fast compared to the
time to transmit a single neopixel, but any time we can gain back
in the whole pipeline will let marginal animations work a little better.
To set all the pixels in this way and then show() gives a pleasant bump
to the framerate, from about 108Hz to 124Hz (1.15x)
The main source of speed-up is using integer math instead of floating
point math for the calculation of the post-scaled pixel values. A slight
secondary gain is achieved by avoiding the scaling altogether when
the scale factor is 1.0.
Because the math is not exactly the same, some scaled pixel values may
change by +- 1 RGBW "step". In practice, this is unlikely to matter.
The gains are bigger on the Pico and other M0 microcontrollers than M4
microcontrollers with floating point math in the hardware.
Happily, flash size is also improved a bit on the Pico build I did,
going from
> 542552 bytes used, 506024 bytes free in flash firmware space out of 1048576 bytes (1024.0kB).
to
> 542376 bytes used, 506200 bytes free in flash firmware space out of 1048576 bytes (1024.0kB).
2021-02-24 10:29:59 -05:00
|
|
|
#include <math.h>
|
2019-01-13 23:51:13 -05:00
|
|
|
|
2020-01-24 21:23:07 -05:00
|
|
|
// Helper to ensure we have the native super class instead of a subclass.
|
2021-03-15 09:57:36 -04:00
|
|
|
static pixelbuf_pixelbuf_obj_t *native_pixelbuf(mp_obj_t pixelbuf_obj) {
|
2021-05-05 20:51:52 -04:00
|
|
|
mp_obj_t native_pixelbuf = mp_obj_cast_to_native_base(pixelbuf_obj, &pixelbuf_pixelbuf_type);
|
2020-01-24 21:23:07 -05:00
|
|
|
mp_obj_assert_native_inited(native_pixelbuf);
|
|
|
|
return MP_OBJ_TO_PTR(native_pixelbuf);
|
|
|
|
}
|
|
|
|
|
2021-07-16 14:08:39 -04:00
|
|
|
void common_hal_adafruit_pixelbuf_pixelbuf_construct(pixelbuf_pixelbuf_obj_t *self, size_t n,
|
2021-03-15 09:57:36 -04:00
|
|
|
pixelbuf_byteorder_details_t *byteorder, mp_float_t brightness, bool auto_write,
|
|
|
|
uint8_t *header, size_t header_len, uint8_t *trailer, size_t trailer_len) {
|
2020-01-24 21:23:07 -05:00
|
|
|
|
|
|
|
self->pixel_count = n;
|
|
|
|
self->byteorder = *byteorder; // Copied because we modify for dotstar
|
|
|
|
self->bytes_per_pixel = byteorder->is_dotstar ? 4 : byteorder->bpp;
|
|
|
|
self->auto_write = false;
|
|
|
|
|
|
|
|
size_t pixel_len = self->pixel_count * self->bytes_per_pixel;
|
|
|
|
self->transmit_buffer_obj = mp_obj_new_bytes_of_zeros(header_len + pixel_len + trailer_len);
|
|
|
|
mp_obj_str_t *o = MP_OBJ_TO_PTR(self->transmit_buffer_obj);
|
|
|
|
|
|
|
|
// Abuse the bytes object a bit by mutating it's data by dropping the const. If the user's
|
|
|
|
// Python code holds onto it, they'll find out that it changes. At least this way it isn't
|
|
|
|
// mutable by the code itself.
|
2021-03-15 09:57:36 -04:00
|
|
|
uint8_t *transmit_buffer = (uint8_t *)o->data;
|
2020-01-24 21:23:07 -05:00
|
|
|
memcpy(transmit_buffer, header, header_len);
|
|
|
|
memcpy(transmit_buffer + header_len + pixel_len, trailer, trailer_len);
|
|
|
|
self->post_brightness_buffer = transmit_buffer + header_len;
|
|
|
|
|
|
|
|
if (self->byteorder.is_dotstar) {
|
|
|
|
// Initialize the buffer with the dotstar start bytes.
|
|
|
|
// Note: Header and end must be setup by caller
|
|
|
|
for (uint i = 0; i < self->pixel_count * 4; i += 4) {
|
|
|
|
self->post_brightness_buffer[i] = DOTSTAR_LED_START_FULL_BRIGHT;
|
2019-08-04 11:02:33 -04:00
|
|
|
}
|
2020-01-24 21:23:07 -05:00
|
|
|
}
|
|
|
|
// Call set_brightness so that it can allocate a second buffer if needed.
|
2020-01-27 18:10:32 -05:00
|
|
|
self->brightness = 1.0;
|
_pixelbuf: Increase performance of brightness-scaling
On the Pico, this increases the "fill rate" of
pixels[:] = newvalues
considerably. On a strip of 240 RGB LEDs, auto_write=False, the timings
are:
|| Brightness || Before || After || Improvement ||
|| 1.0 || 117 kpix/s || 307 kpix/s || 2.62x ||
|| 0.07 || 117 kpix/s || 273 kpix/s || 2.33x ||
It's worth noting that even the "before" rate is fast compared to the
time to transmit a single neopixel, but any time we can gain back
in the whole pipeline will let marginal animations work a little better.
To set all the pixels in this way and then show() gives a pleasant bump
to the framerate, from about 108Hz to 124Hz (1.15x)
The main source of speed-up is using integer math instead of floating
point math for the calculation of the post-scaled pixel values. A slight
secondary gain is achieved by avoiding the scaling altogether when
the scale factor is 1.0.
Because the math is not exactly the same, some scaled pixel values may
change by +- 1 RGBW "step". In practice, this is unlikely to matter.
The gains are bigger on the Pico and other M0 microcontrollers than M4
microcontrollers with floating point math in the hardware.
Happily, flash size is also improved a bit on the Pico build I did,
going from
> 542552 bytes used, 506024 bytes free in flash firmware space out of 1048576 bytes (1024.0kB).
to
> 542376 bytes used, 506200 bytes free in flash firmware space out of 1048576 bytes (1024.0kB).
2021-02-24 10:29:59 -05:00
|
|
|
self->scaled_brightness = 0x100;
|
2021-07-16 14:08:39 -04:00
|
|
|
common_hal_adafruit_pixelbuf_pixelbuf_set_brightness(MP_OBJ_FROM_PTR(self), brightness);
|
2020-01-24 21:23:07 -05:00
|
|
|
|
|
|
|
// Turn on auto_write. We don't want to do it with the above brightness call.
|
|
|
|
self->auto_write = auto_write;
|
|
|
|
}
|
|
|
|
|
2021-07-16 14:08:39 -04:00
|
|
|
size_t common_hal_adafruit_pixelbuf_pixelbuf_get_len(mp_obj_t self_in) {
|
2021-03-15 09:57:36 -04:00
|
|
|
pixelbuf_pixelbuf_obj_t *self = native_pixelbuf(self_in);
|
2020-01-24 21:23:07 -05:00
|
|
|
return self->pixel_count;
|
|
|
|
}
|
|
|
|
|
2021-07-16 14:08:39 -04:00
|
|
|
uint8_t common_hal_adafruit_pixelbuf_pixelbuf_get_bpp(mp_obj_t self_in) {
|
2021-03-15 09:57:36 -04:00
|
|
|
pixelbuf_pixelbuf_obj_t *self = native_pixelbuf(self_in);
|
2020-01-24 21:23:07 -05:00
|
|
|
return self->byteorder.bpp;
|
|
|
|
}
|
|
|
|
|
2021-07-16 14:08:39 -04:00
|
|
|
mp_obj_t common_hal_adafruit_pixelbuf_pixelbuf_get_byteorder_string(mp_obj_t self_in) {
|
2021-03-15 09:57:36 -04:00
|
|
|
pixelbuf_pixelbuf_obj_t *self = native_pixelbuf(self_in);
|
2020-01-24 21:23:07 -05:00
|
|
|
return self->byteorder.order_string;
|
|
|
|
}
|
|
|
|
|
2021-07-16 14:08:39 -04:00
|
|
|
bool common_hal_adafruit_pixelbuf_pixelbuf_get_auto_write(mp_obj_t self_in) {
|
2021-03-15 09:57:36 -04:00
|
|
|
pixelbuf_pixelbuf_obj_t *self = native_pixelbuf(self_in);
|
2020-01-24 21:23:07 -05:00
|
|
|
return self->auto_write;
|
|
|
|
}
|
|
|
|
|
2021-07-16 14:08:39 -04:00
|
|
|
void common_hal_adafruit_pixelbuf_pixelbuf_set_auto_write(mp_obj_t self_in, bool auto_write) {
|
2021-03-15 09:57:36 -04:00
|
|
|
pixelbuf_pixelbuf_obj_t *self = native_pixelbuf(self_in);
|
2020-01-24 21:23:07 -05:00
|
|
|
self->auto_write = auto_write;
|
|
|
|
}
|
|
|
|
|
2021-07-16 14:08:39 -04:00
|
|
|
mp_float_t common_hal_adafruit_pixelbuf_pixelbuf_get_brightness(mp_obj_t self_in) {
|
2021-03-15 09:57:36 -04:00
|
|
|
pixelbuf_pixelbuf_obj_t *self = native_pixelbuf(self_in);
|
2020-01-24 21:23:07 -05:00
|
|
|
return self->brightness;
|
|
|
|
}
|
|
|
|
|
2021-07-16 14:08:39 -04:00
|
|
|
void common_hal_adafruit_pixelbuf_pixelbuf_set_brightness(mp_obj_t self_in, mp_float_t brightness) {
|
2021-03-15 09:57:36 -04:00
|
|
|
pixelbuf_pixelbuf_obj_t *self = native_pixelbuf(self_in);
|
2020-01-27 18:10:32 -05:00
|
|
|
// Skip out if the brightness is already set. The default of self->brightness is 1.0. So, this
|
|
|
|
// also prevents the pre_brightness_buffer allocation when brightness is set to 1.0 again.
|
_pixelbuf: Increase performance of brightness-scaling
On the Pico, this increases the "fill rate" of
pixels[:] = newvalues
considerably. On a strip of 240 RGB LEDs, auto_write=False, the timings
are:
|| Brightness || Before || After || Improvement ||
|| 1.0 || 117 kpix/s || 307 kpix/s || 2.62x ||
|| 0.07 || 117 kpix/s || 273 kpix/s || 2.33x ||
It's worth noting that even the "before" rate is fast compared to the
time to transmit a single neopixel, but any time we can gain back
in the whole pipeline will let marginal animations work a little better.
To set all the pixels in this way and then show() gives a pleasant bump
to the framerate, from about 108Hz to 124Hz (1.15x)
The main source of speed-up is using integer math instead of floating
point math for the calculation of the post-scaled pixel values. A slight
secondary gain is achieved by avoiding the scaling altogether when
the scale factor is 1.0.
Because the math is not exactly the same, some scaled pixel values may
change by +- 1 RGBW "step". In practice, this is unlikely to matter.
The gains are bigger on the Pico and other M0 microcontrollers than M4
microcontrollers with floating point math in the hardware.
Happily, flash size is also improved a bit on the Pico build I did,
going from
> 542552 bytes used, 506024 bytes free in flash firmware space out of 1048576 bytes (1024.0kB).
to
> 542376 bytes used, 506200 bytes free in flash firmware space out of 1048576 bytes (1024.0kB).
2021-02-24 10:29:59 -05:00
|
|
|
self->brightness = brightness;
|
2021-02-24 17:27:09 -05:00
|
|
|
// Use 256 steps of brightness so that we can do integer math below.
|
|
|
|
uint16_t new_scaled_brightness = (uint16_t)(brightness * 256);
|
_pixelbuf: Increase performance of brightness-scaling
On the Pico, this increases the "fill rate" of
pixels[:] = newvalues
considerably. On a strip of 240 RGB LEDs, auto_write=False, the timings
are:
|| Brightness || Before || After || Improvement ||
|| 1.0 || 117 kpix/s || 307 kpix/s || 2.62x ||
|| 0.07 || 117 kpix/s || 273 kpix/s || 2.33x ||
It's worth noting that even the "before" rate is fast compared to the
time to transmit a single neopixel, but any time we can gain back
in the whole pipeline will let marginal animations work a little better.
To set all the pixels in this way and then show() gives a pleasant bump
to the framerate, from about 108Hz to 124Hz (1.15x)
The main source of speed-up is using integer math instead of floating
point math for the calculation of the post-scaled pixel values. A slight
secondary gain is achieved by avoiding the scaling altogether when
the scale factor is 1.0.
Because the math is not exactly the same, some scaled pixel values may
change by +- 1 RGBW "step". In practice, this is unlikely to matter.
The gains are bigger on the Pico and other M0 microcontrollers than M4
microcontrollers with floating point math in the hardware.
Happily, flash size is also improved a bit on the Pico build I did,
going from
> 542552 bytes used, 506024 bytes free in flash firmware space out of 1048576 bytes (1024.0kB).
to
> 542376 bytes used, 506200 bytes free in flash firmware space out of 1048576 bytes (1024.0kB).
2021-02-24 10:29:59 -05:00
|
|
|
if (new_scaled_brightness == self->scaled_brightness) {
|
2020-01-27 18:10:32 -05:00
|
|
|
return;
|
|
|
|
}
|
_pixelbuf: Increase performance of brightness-scaling
On the Pico, this increases the "fill rate" of
pixels[:] = newvalues
considerably. On a strip of 240 RGB LEDs, auto_write=False, the timings
are:
|| Brightness || Before || After || Improvement ||
|| 1.0 || 117 kpix/s || 307 kpix/s || 2.62x ||
|| 0.07 || 117 kpix/s || 273 kpix/s || 2.33x ||
It's worth noting that even the "before" rate is fast compared to the
time to transmit a single neopixel, but any time we can gain back
in the whole pipeline will let marginal animations work a little better.
To set all the pixels in this way and then show() gives a pleasant bump
to the framerate, from about 108Hz to 124Hz (1.15x)
The main source of speed-up is using integer math instead of floating
point math for the calculation of the post-scaled pixel values. A slight
secondary gain is achieved by avoiding the scaling altogether when
the scale factor is 1.0.
Because the math is not exactly the same, some scaled pixel values may
change by +- 1 RGBW "step". In practice, this is unlikely to matter.
The gains are bigger on the Pico and other M0 microcontrollers than M4
microcontrollers with floating point math in the hardware.
Happily, flash size is also improved a bit on the Pico build I did,
going from
> 542552 bytes used, 506024 bytes free in flash firmware space out of 1048576 bytes (1024.0kB).
to
> 542376 bytes used, 506200 bytes free in flash firmware space out of 1048576 bytes (1024.0kB).
2021-02-24 10:29:59 -05:00
|
|
|
self->scaled_brightness = new_scaled_brightness;
|
2020-01-24 21:23:07 -05:00
|
|
|
size_t pixel_len = self->pixel_count * self->bytes_per_pixel;
|
_pixelbuf: Increase performance of brightness-scaling
On the Pico, this increases the "fill rate" of
pixels[:] = newvalues
considerably. On a strip of 240 RGB LEDs, auto_write=False, the timings
are:
|| Brightness || Before || After || Improvement ||
|| 1.0 || 117 kpix/s || 307 kpix/s || 2.62x ||
|| 0.07 || 117 kpix/s || 273 kpix/s || 2.33x ||
It's worth noting that even the "before" rate is fast compared to the
time to transmit a single neopixel, but any time we can gain back
in the whole pipeline will let marginal animations work a little better.
To set all the pixels in this way and then show() gives a pleasant bump
to the framerate, from about 108Hz to 124Hz (1.15x)
The main source of speed-up is using integer math instead of floating
point math for the calculation of the post-scaled pixel values. A slight
secondary gain is achieved by avoiding the scaling altogether when
the scale factor is 1.0.
Because the math is not exactly the same, some scaled pixel values may
change by +- 1 RGBW "step". In practice, this is unlikely to matter.
The gains are bigger on the Pico and other M0 microcontrollers than M4
microcontrollers with floating point math in the hardware.
Happily, flash size is also improved a bit on the Pico build I did,
going from
> 542552 bytes used, 506024 bytes free in flash firmware space out of 1048576 bytes (1024.0kB).
to
> 542376 bytes used, 506200 bytes free in flash firmware space out of 1048576 bytes (1024.0kB).
2021-02-24 10:29:59 -05:00
|
|
|
if (self->scaled_brightness == 0x100 && !self->pre_brightness_buffer) {
|
|
|
|
return;
|
|
|
|
} else {
|
|
|
|
if (self->pre_brightness_buffer == NULL) {
|
2023-08-10 20:06:32 -04:00
|
|
|
self->pre_brightness_buffer = m_malloc(pixel_len);
|
_pixelbuf: Increase performance of brightness-scaling
On the Pico, this increases the "fill rate" of
pixels[:] = newvalues
considerably. On a strip of 240 RGB LEDs, auto_write=False, the timings
are:
|| Brightness || Before || After || Improvement ||
|| 1.0 || 117 kpix/s || 307 kpix/s || 2.62x ||
|| 0.07 || 117 kpix/s || 273 kpix/s || 2.33x ||
It's worth noting that even the "before" rate is fast compared to the
time to transmit a single neopixel, but any time we can gain back
in the whole pipeline will let marginal animations work a little better.
To set all the pixels in this way and then show() gives a pleasant bump
to the framerate, from about 108Hz to 124Hz (1.15x)
The main source of speed-up is using integer math instead of floating
point math for the calculation of the post-scaled pixel values. A slight
secondary gain is achieved by avoiding the scaling altogether when
the scale factor is 1.0.
Because the math is not exactly the same, some scaled pixel values may
change by +- 1 RGBW "step". In practice, this is unlikely to matter.
The gains are bigger on the Pico and other M0 microcontrollers than M4
microcontrollers with floating point math in the hardware.
Happily, flash size is also improved a bit on the Pico build I did,
going from
> 542552 bytes used, 506024 bytes free in flash firmware space out of 1048576 bytes (1024.0kB).
to
> 542376 bytes used, 506200 bytes free in flash firmware space out of 1048576 bytes (1024.0kB).
2021-02-24 10:29:59 -05:00
|
|
|
memcpy(self->pre_brightness_buffer, self->post_brightness_buffer, pixel_len);
|
|
|
|
}
|
|
|
|
for (size_t i = 0; i < pixel_len; i++) {
|
|
|
|
// Don't adjust per-pixel luminance bytes in dotstar mode
|
|
|
|
if (self->byteorder.is_dotstar && i % 4 == 0) {
|
|
|
|
continue;
|
|
|
|
}
|
2021-02-24 17:27:09 -05:00
|
|
|
self->post_brightness_buffer[i] = (self->pre_brightness_buffer[i] * self->scaled_brightness) / 256;
|
2020-01-24 21:23:07 -05:00
|
|
|
}
|
|
|
|
|
_pixelbuf: Increase performance of brightness-scaling
On the Pico, this increases the "fill rate" of
pixels[:] = newvalues
considerably. On a strip of 240 RGB LEDs, auto_write=False, the timings
are:
|| Brightness || Before || After || Improvement ||
|| 1.0 || 117 kpix/s || 307 kpix/s || 2.62x ||
|| 0.07 || 117 kpix/s || 273 kpix/s || 2.33x ||
It's worth noting that even the "before" rate is fast compared to the
time to transmit a single neopixel, but any time we can gain back
in the whole pipeline will let marginal animations work a little better.
To set all the pixels in this way and then show() gives a pleasant bump
to the framerate, from about 108Hz to 124Hz (1.15x)
The main source of speed-up is using integer math instead of floating
point math for the calculation of the post-scaled pixel values. A slight
secondary gain is achieved by avoiding the scaling altogether when
the scale factor is 1.0.
Because the math is not exactly the same, some scaled pixel values may
change by +- 1 RGBW "step". In practice, this is unlikely to matter.
The gains are bigger on the Pico and other M0 microcontrollers than M4
microcontrollers with floating point math in the hardware.
Happily, flash size is also improved a bit on the Pico build I did,
going from
> 542552 bytes used, 506024 bytes free in flash firmware space out of 1048576 bytes (1024.0kB).
to
> 542376 bytes used, 506200 bytes free in flash firmware space out of 1048576 bytes (1024.0kB).
2021-02-24 10:29:59 -05:00
|
|
|
if (self->auto_write) {
|
2021-07-16 14:08:39 -04:00
|
|
|
common_hal_adafruit_pixelbuf_pixelbuf_show(self_in);
|
_pixelbuf: Increase performance of brightness-scaling
On the Pico, this increases the "fill rate" of
pixels[:] = newvalues
considerably. On a strip of 240 RGB LEDs, auto_write=False, the timings
are:
|| Brightness || Before || After || Improvement ||
|| 1.0 || 117 kpix/s || 307 kpix/s || 2.62x ||
|| 0.07 || 117 kpix/s || 273 kpix/s || 2.33x ||
It's worth noting that even the "before" rate is fast compared to the
time to transmit a single neopixel, but any time we can gain back
in the whole pipeline will let marginal animations work a little better.
To set all the pixels in this way and then show() gives a pleasant bump
to the framerate, from about 108Hz to 124Hz (1.15x)
The main source of speed-up is using integer math instead of floating
point math for the calculation of the post-scaled pixel values. A slight
secondary gain is achieved by avoiding the scaling altogether when
the scale factor is 1.0.
Because the math is not exactly the same, some scaled pixel values may
change by +- 1 RGBW "step". In practice, this is unlikely to matter.
The gains are bigger on the Pico and other M0 microcontrollers than M4
microcontrollers with floating point math in the hardware.
Happily, flash size is also improved a bit on the Pico build I did,
going from
> 542552 bytes used, 506024 bytes free in flash firmware space out of 1048576 bytes (1024.0kB).
to
> 542376 bytes used, 506200 bytes free in flash firmware space out of 1048576 bytes (1024.0kB).
2021-02-24 10:29:59 -05:00
|
|
|
}
|
2020-01-24 21:23:07 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-11-10 09:42:21 -05:00
|
|
|
STATIC uint8_t _pixelbuf_get_as_uint8(mp_obj_t obj) {
|
2021-04-22 20:55:39 -04:00
|
|
|
if (mp_obj_is_small_int(obj)) {
|
2020-08-07 18:42:06 -04:00
|
|
|
return MP_OBJ_SMALL_INT_VALUE(obj);
|
2022-11-14 22:25:33 -05:00
|
|
|
#if MICROPY_LONGINT_IMPL != MICROPY_LONGINT_IMPL_NONE
|
2021-04-22 20:55:39 -04:00
|
|
|
} else if (mp_obj_is_int(obj)) {
|
2020-08-07 18:42:06 -04:00
|
|
|
return mp_obj_get_int_truncated(obj);
|
2022-11-14 22:25:33 -05:00
|
|
|
#endif
|
2020-08-07 18:42:06 -04:00
|
|
|
} else if (mp_obj_is_float(obj)) {
|
|
|
|
return (uint8_t)mp_obj_get_float(obj);
|
2020-08-10 12:04:44 -04:00
|
|
|
}
|
2020-08-07 18:42:06 -04:00
|
|
|
mp_raise_TypeError_varg(
|
2021-03-15 09:57:36 -04:00
|
|
|
translate("can't convert %q to %q"), mp_obj_get_type_qstr(obj), MP_QSTR_int);
|
2020-08-07 18:42:06 -04:00
|
|
|
}
|
|
|
|
|
2022-11-22 19:47:25 -05:00
|
|
|
static void pixelbuf_parse_color(pixelbuf_pixelbuf_obj_t *self, mp_obj_t color, uint8_t *r, uint8_t *g, uint8_t *b, uint8_t *w) {
|
2020-01-24 21:23:07 -05:00
|
|
|
pixelbuf_byteorder_details_t *byteorder = &self->byteorder;
|
|
|
|
// w is shared between white in NeoPixels and brightness in dotstars (so that DotStars can have
|
|
|
|
// per-pixel brightness). Set the defaults here in case it isn't set below.
|
|
|
|
if (byteorder->is_dotstar) {
|
2022-11-22 19:47:25 -05:00
|
|
|
*w = 255;
|
2020-01-24 21:23:07 -05:00
|
|
|
} else {
|
2022-11-22 19:47:25 -05:00
|
|
|
*w = 0;
|
2020-01-24 21:23:07 -05:00
|
|
|
}
|
|
|
|
|
2021-04-22 20:55:39 -04:00
|
|
|
if (mp_obj_is_int(color) || mp_obj_is_float(color)) {
|
2021-12-17 16:23:58 -05:00
|
|
|
mp_int_t value = mp_obj_is_int(color) ? mp_obj_get_int_truncated(color) : (mp_int_t)mp_obj_get_float(color);
|
2022-11-22 19:47:25 -05:00
|
|
|
*r = value >> 16 & 0xff;
|
|
|
|
*g = (value >> 8) & 0xff;
|
|
|
|
*b = value & 0xff;
|
2019-01-13 23:51:13 -05:00
|
|
|
} else {
|
|
|
|
mp_obj_t *items;
|
|
|
|
size_t len;
|
2020-01-24 21:23:07 -05:00
|
|
|
mp_obj_get_array(color, &len, &items);
|
2022-05-13 15:33:43 -04:00
|
|
|
mp_arg_validate_length_range(len, 3, 4, MP_QSTR_color);
|
2020-01-24 21:23:07 -05:00
|
|
|
|
2022-11-22 19:47:25 -05:00
|
|
|
*r = _pixelbuf_get_as_uint8(items[PIXEL_R]);
|
|
|
|
*g = _pixelbuf_get_as_uint8(items[PIXEL_G]);
|
|
|
|
*b = _pixelbuf_get_as_uint8(items[PIXEL_B]);
|
2019-01-13 23:51:13 -05:00
|
|
|
if (len > 3) {
|
2020-01-24 21:23:07 -05:00
|
|
|
if (mp_obj_is_float(items[PIXEL_W])) {
|
2022-11-22 19:47:25 -05:00
|
|
|
*w = 255 * mp_obj_get_float(items[PIXEL_W]);
|
2019-01-13 23:51:13 -05:00
|
|
|
} else {
|
2022-11-22 19:47:25 -05:00
|
|
|
*w = mp_obj_get_int_truncated(items[PIXEL_W]);
|
2019-01-13 23:51:13 -05:00
|
|
|
}
|
2022-11-22 19:47:25 -05:00
|
|
|
return;
|
2019-01-13 23:51:13 -05:00
|
|
|
}
|
|
|
|
}
|
2020-05-24 20:35:13 -04:00
|
|
|
// Int colors can't set white directly so convert to white when all components are equal.
|
|
|
|
// Also handles RGBW values assigned an RGB tuple.
|
2022-11-22 19:47:25 -05:00
|
|
|
if (!byteorder->is_dotstar && byteorder->bpp == 4 && byteorder->has_white && *r == *g && *r == *b) {
|
|
|
|
*w = *r;
|
|
|
|
*r = 0;
|
|
|
|
*g = 0;
|
|
|
|
*b = 0;
|
2020-05-24 20:35:13 -04:00
|
|
|
}
|
2019-01-13 23:51:13 -05:00
|
|
|
}
|
|
|
|
|
2022-11-22 19:47:25 -05:00
|
|
|
void common_hal_adafruit_pixelbuf_pixelbuf_parse_color(mp_obj_t self_in, mp_obj_t color, uint8_t *r, uint8_t *g, uint8_t *b, uint8_t *w) {
|
|
|
|
pixelbuf_pixelbuf_obj_t *self = native_pixelbuf(self_in);
|
|
|
|
pixelbuf_parse_color(self, color, r, g, b, w);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void pixelbuf_set_pixel_color(pixelbuf_pixelbuf_obj_t *self, size_t index, uint8_t r, uint8_t g, uint8_t b, uint8_t w) {
|
2020-01-24 21:23:07 -05:00
|
|
|
// DotStars don't have white, instead they have 5 bit brightness so pack it into w. Shift right
|
|
|
|
// by three to leave the top five bits.
|
|
|
|
if (self->bytes_per_pixel == 4 && self->byteorder.is_dotstar) {
|
|
|
|
w = DOTSTAR_LED_START | w >> 3;
|
|
|
|
}
|
|
|
|
pixelbuf_rgbw_t *rgbw_order = &self->byteorder.byteorder;
|
|
|
|
size_t offset = index * self->bytes_per_pixel;
|
_pixelbuf: Increase performance of brightness-scaling
On the Pico, this increases the "fill rate" of
pixels[:] = newvalues
considerably. On a strip of 240 RGB LEDs, auto_write=False, the timings
are:
|| Brightness || Before || After || Improvement ||
|| 1.0 || 117 kpix/s || 307 kpix/s || 2.62x ||
|| 0.07 || 117 kpix/s || 273 kpix/s || 2.33x ||
It's worth noting that even the "before" rate is fast compared to the
time to transmit a single neopixel, but any time we can gain back
in the whole pipeline will let marginal animations work a little better.
To set all the pixels in this way and then show() gives a pleasant bump
to the framerate, from about 108Hz to 124Hz (1.15x)
The main source of speed-up is using integer math instead of floating
point math for the calculation of the post-scaled pixel values. A slight
secondary gain is achieved by avoiding the scaling altogether when
the scale factor is 1.0.
Because the math is not exactly the same, some scaled pixel values may
change by +- 1 RGBW "step". In practice, this is unlikely to matter.
The gains are bigger on the Pico and other M0 microcontrollers than M4
microcontrollers with floating point math in the hardware.
Happily, flash size is also improved a bit on the Pico build I did,
going from
> 542552 bytes used, 506024 bytes free in flash firmware space out of 1048576 bytes (1024.0kB).
to
> 542376 bytes used, 506200 bytes free in flash firmware space out of 1048576 bytes (1024.0kB).
2021-02-24 10:29:59 -05:00
|
|
|
uint8_t *scaled_buffer, *unscaled_buffer;
|
|
|
|
if (self->pre_brightness_buffer) {
|
|
|
|
scaled_buffer = self->post_brightness_buffer + offset;
|
|
|
|
unscaled_buffer = self->pre_brightness_buffer + offset;
|
|
|
|
} else {
|
|
|
|
scaled_buffer = NULL;
|
|
|
|
unscaled_buffer = self->post_brightness_buffer + offset;
|
2020-01-24 21:23:07 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
if (self->bytes_per_pixel == 4) {
|
_pixelbuf: Increase performance of brightness-scaling
On the Pico, this increases the "fill rate" of
pixels[:] = newvalues
considerably. On a strip of 240 RGB LEDs, auto_write=False, the timings
are:
|| Brightness || Before || After || Improvement ||
|| 1.0 || 117 kpix/s || 307 kpix/s || 2.62x ||
|| 0.07 || 117 kpix/s || 273 kpix/s || 2.33x ||
It's worth noting that even the "before" rate is fast compared to the
time to transmit a single neopixel, but any time we can gain back
in the whole pipeline will let marginal animations work a little better.
To set all the pixels in this way and then show() gives a pleasant bump
to the framerate, from about 108Hz to 124Hz (1.15x)
The main source of speed-up is using integer math instead of floating
point math for the calculation of the post-scaled pixel values. A slight
secondary gain is achieved by avoiding the scaling altogether when
the scale factor is 1.0.
Because the math is not exactly the same, some scaled pixel values may
change by +- 1 RGBW "step". In practice, this is unlikely to matter.
The gains are bigger on the Pico and other M0 microcontrollers than M4
microcontrollers with floating point math in the hardware.
Happily, flash size is also improved a bit on the Pico build I did,
going from
> 542552 bytes used, 506024 bytes free in flash firmware space out of 1048576 bytes (1024.0kB).
to
> 542376 bytes used, 506200 bytes free in flash firmware space out of 1048576 bytes (1024.0kB).
2021-02-24 10:29:59 -05:00
|
|
|
unscaled_buffer[rgbw_order->w] = w;
|
|
|
|
}
|
|
|
|
|
|
|
|
unscaled_buffer[rgbw_order->r] = r;
|
|
|
|
unscaled_buffer[rgbw_order->g] = g;
|
|
|
|
unscaled_buffer[rgbw_order->b] = b;
|
|
|
|
|
|
|
|
if (scaled_buffer) {
|
|
|
|
if (self->bytes_per_pixel == 4) {
|
|
|
|
if (!self->byteorder.is_dotstar) {
|
2021-02-24 17:27:09 -05:00
|
|
|
w = (w * self->scaled_brightness) / 256;
|
_pixelbuf: Increase performance of brightness-scaling
On the Pico, this increases the "fill rate" of
pixels[:] = newvalues
considerably. On a strip of 240 RGB LEDs, auto_write=False, the timings
are:
|| Brightness || Before || After || Improvement ||
|| 1.0 || 117 kpix/s || 307 kpix/s || 2.62x ||
|| 0.07 || 117 kpix/s || 273 kpix/s || 2.33x ||
It's worth noting that even the "before" rate is fast compared to the
time to transmit a single neopixel, but any time we can gain back
in the whole pipeline will let marginal animations work a little better.
To set all the pixels in this way and then show() gives a pleasant bump
to the framerate, from about 108Hz to 124Hz (1.15x)
The main source of speed-up is using integer math instead of floating
point math for the calculation of the post-scaled pixel values. A slight
secondary gain is achieved by avoiding the scaling altogether when
the scale factor is 1.0.
Because the math is not exactly the same, some scaled pixel values may
change by +- 1 RGBW "step". In practice, this is unlikely to matter.
The gains are bigger on the Pico and other M0 microcontrollers than M4
microcontrollers with floating point math in the hardware.
Happily, flash size is also improved a bit on the Pico build I did,
going from
> 542552 bytes used, 506024 bytes free in flash firmware space out of 1048576 bytes (1024.0kB).
to
> 542376 bytes used, 506200 bytes free in flash firmware space out of 1048576 bytes (1024.0kB).
2021-02-24 10:29:59 -05:00
|
|
|
}
|
|
|
|
scaled_buffer[rgbw_order->w] = w;
|
2020-01-24 21:23:07 -05:00
|
|
|
}
|
2021-02-24 17:27:09 -05:00
|
|
|
scaled_buffer[rgbw_order->r] = (r * self->scaled_brightness) / 256;
|
|
|
|
scaled_buffer[rgbw_order->g] = (g * self->scaled_brightness) / 256;
|
|
|
|
scaled_buffer[rgbw_order->b] = (b * self->scaled_brightness) / 256;
|
2020-01-24 21:23:07 -05:00
|
|
|
}
|
|
|
|
}
|
2022-11-22 19:47:25 -05:00
|
|
|
void common_hal_adafruit_pixelbuf_pixelbuf_set_pixel_color(mp_obj_t self_in, size_t index, uint8_t r, uint8_t g, uint8_t b, uint8_t w) {
|
|
|
|
pixelbuf_pixelbuf_obj_t *self = native_pixelbuf(self_in);
|
|
|
|
pixelbuf_set_pixel_color(self, index, r, g, b, w);
|
|
|
|
}
|
2020-01-24 21:23:07 -05:00
|
|
|
|
2021-11-10 09:42:21 -05:00
|
|
|
STATIC void _pixelbuf_set_pixel(pixelbuf_pixelbuf_obj_t *self, size_t index, mp_obj_t value) {
|
2022-11-22 19:47:25 -05:00
|
|
|
uint8_t r;
|
|
|
|
uint8_t g;
|
|
|
|
uint8_t b;
|
|
|
|
uint8_t w;
|
|
|
|
common_hal_adafruit_pixelbuf_pixelbuf_parse_color(self, value, &r, &g, &b, &w);
|
|
|
|
common_hal_adafruit_pixelbuf_pixelbuf_set_pixel_color(self, index, r, g, b, w);
|
2020-01-24 21:23:07 -05:00
|
|
|
}
|
|
|
|
|
2021-07-16 14:08:39 -04:00
|
|
|
void common_hal_adafruit_pixelbuf_pixelbuf_set_pixels(mp_obj_t self_in, size_t start, mp_int_t step, size_t slice_len, mp_obj_t *values,
|
2021-03-15 09:57:36 -04:00
|
|
|
mp_obj_tuple_t *flatten_to) {
|
|
|
|
pixelbuf_pixelbuf_obj_t *self = native_pixelbuf(self_in);
|
2020-08-07 18:42:06 -04:00
|
|
|
mp_obj_iter_buf_t iter_buf;
|
|
|
|
mp_obj_t iterable = mp_getiter(values, &iter_buf);
|
|
|
|
mp_obj_t item;
|
|
|
|
size_t i = 0;
|
2020-08-10 18:05:13 -04:00
|
|
|
bool flattened = flatten_to != mp_const_none;
|
2021-03-15 09:57:36 -04:00
|
|
|
if (flattened) {
|
|
|
|
flatten_to->len = self->bytes_per_pixel;
|
|
|
|
}
|
2020-08-07 18:42:06 -04:00
|
|
|
while ((item = mp_iternext(iterable)) != MP_OBJ_STOP_ITERATION) {
|
|
|
|
if (flattened) {
|
2020-08-10 18:05:13 -04:00
|
|
|
flatten_to->items[i % self->bytes_per_pixel] = item;
|
|
|
|
if (++i % self->bytes_per_pixel == 0) {
|
|
|
|
_pixelbuf_set_pixel(self, start, flatten_to);
|
2021-03-15 09:57:36 -04:00
|
|
|
start += step;
|
2020-08-07 18:42:06 -04:00
|
|
|
}
|
|
|
|
} else {
|
|
|
|
_pixelbuf_set_pixel(self, start, item);
|
2021-03-15 09:57:36 -04:00
|
|
|
start += step;
|
2020-08-07 18:42:06 -04:00
|
|
|
}
|
2020-01-24 21:23:07 -05:00
|
|
|
}
|
|
|
|
if (self->auto_write) {
|
2021-07-16 14:08:39 -04:00
|
|
|
common_hal_adafruit_pixelbuf_pixelbuf_show(self_in);
|
2020-01-24 21:23:07 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-08-07 18:42:06 -04:00
|
|
|
|
|
|
|
|
2021-07-16 14:08:39 -04:00
|
|
|
void common_hal_adafruit_pixelbuf_pixelbuf_set_pixel(mp_obj_t self_in, size_t index, mp_obj_t value) {
|
2021-03-15 09:57:36 -04:00
|
|
|
pixelbuf_pixelbuf_obj_t *self = native_pixelbuf(self_in);
|
2020-01-24 21:23:07 -05:00
|
|
|
_pixelbuf_set_pixel(self, index, value);
|
|
|
|
if (self->auto_write) {
|
2021-07-16 14:08:39 -04:00
|
|
|
common_hal_adafruit_pixelbuf_pixelbuf_show(self_in);
|
2019-01-13 23:51:13 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-07-16 14:08:39 -04:00
|
|
|
mp_obj_t common_hal_adafruit_pixelbuf_pixelbuf_get_pixel(mp_obj_t self_in, size_t index) {
|
2021-03-15 09:57:36 -04:00
|
|
|
pixelbuf_pixelbuf_obj_t *self = native_pixelbuf(self_in);
|
2020-01-24 21:23:07 -05:00
|
|
|
mp_obj_t elems[self->byteorder.bpp];
|
2021-03-15 09:57:36 -04:00
|
|
|
uint8_t *pixel_buffer = self->post_brightness_buffer;
|
2020-01-24 21:23:07 -05:00
|
|
|
if (self->pre_brightness_buffer != NULL) {
|
|
|
|
pixel_buffer = self->pre_brightness_buffer;
|
|
|
|
}
|
2020-03-16 11:09:46 -04:00
|
|
|
pixel_buffer += self->byteorder.bpp * index;
|
2020-01-24 21:23:07 -05:00
|
|
|
|
|
|
|
pixelbuf_rgbw_t *rgbw_order = &self->byteorder.byteorder;
|
|
|
|
elems[0] = MP_OBJ_NEW_SMALL_INT(pixel_buffer[rgbw_order->r]);
|
|
|
|
elems[1] = MP_OBJ_NEW_SMALL_INT(pixel_buffer[rgbw_order->g]);
|
|
|
|
elems[2] = MP_OBJ_NEW_SMALL_INT(pixel_buffer[rgbw_order->b]);
|
|
|
|
if (self->byteorder.bpp > 3) {
|
|
|
|
uint8_t w = pixel_buffer[rgbw_order->w];
|
|
|
|
if (self->byteorder.is_dotstar) {
|
|
|
|
elems[3] = mp_obj_new_float((w & 0b00011111) / 31.0);
|
|
|
|
} else {
|
|
|
|
elems[3] = MP_OBJ_NEW_SMALL_INT(w);
|
|
|
|
}
|
2019-01-13 23:51:13 -05:00
|
|
|
}
|
|
|
|
|
2020-01-24 21:23:07 -05:00
|
|
|
return mp_obj_new_tuple(self->byteorder.bpp, elems);
|
|
|
|
}
|
|
|
|
|
2021-07-16 14:08:39 -04:00
|
|
|
void common_hal_adafruit_pixelbuf_pixelbuf_show(mp_obj_t self_in) {
|
2021-03-15 09:57:36 -04:00
|
|
|
pixelbuf_pixelbuf_obj_t *self = native_pixelbuf(self_in);
|
2020-01-24 21:23:07 -05:00
|
|
|
mp_obj_t dest[2 + 1];
|
|
|
|
mp_load_method(self_in, MP_QSTR__transmit, dest);
|
|
|
|
|
|
|
|
dest[2] = self->transmit_buffer_obj;
|
|
|
|
|
|
|
|
mp_call_method_n_kw(1, 0, dest);
|
|
|
|
}
|
|
|
|
|
2021-07-16 14:08:39 -04:00
|
|
|
void common_hal_adafruit_pixelbuf_pixelbuf_fill(mp_obj_t self_in, mp_obj_t fill_color) {
|
2021-03-15 09:57:36 -04:00
|
|
|
pixelbuf_pixelbuf_obj_t *self = native_pixelbuf(self_in);
|
2020-01-24 21:23:07 -05:00
|
|
|
|
2022-11-22 19:47:25 -05:00
|
|
|
uint8_t r;
|
|
|
|
uint8_t g;
|
|
|
|
uint8_t b;
|
|
|
|
uint8_t w;
|
|
|
|
common_hal_adafruit_pixelbuf_pixelbuf_parse_color(self, fill_color, &r, &g, &b, &w);
|
2020-01-24 21:23:07 -05:00
|
|
|
|
|
|
|
for (size_t i = 0; i < self->pixel_count; i++) {
|
2022-11-22 19:47:25 -05:00
|
|
|
common_hal_adafruit_pixelbuf_pixelbuf_set_pixel_color(self, i, r, g, b, w);
|
2020-01-24 21:23:07 -05:00
|
|
|
}
|
|
|
|
if (self->auto_write) {
|
2021-07-16 14:08:39 -04:00
|
|
|
common_hal_adafruit_pixelbuf_pixelbuf_show(self_in);
|
2020-01-24 21:23:07 -05:00
|
|
|
}
|
2019-01-13 23:51:13 -05:00
|
|
|
}
|