The "scale" parameter wasn't exposed in the library, and there
were some problems in how it was handled.
This also fixes some types in the pixel-drawing functions.
complete pin mapping for Feather pins
stubbed out files needed for complilation. still to be modified
0 out all CPY modules in mpconfigboard.mk until we get the build running
add csv for pin generation for STM32L4R5
add F4R5 references in peripherals files
refactored out board files BECAUSE I AM AN IDIOT; add L4 series system clocks file from CubeMX
took a guess at the number of USB endpoint pairs to get the build done
guess was close, but wrong. It is 8
clean up peripheral DEFs
Fixes build error:
```
In file included from ../../py/mpstate.h:33,
from ../../py/mpstate.c:27:
../../py/misc.h: In function 'vstr_str':
../../py/misc.h:196:1: sorry, unimplemented: Thumb-1 hard-float VFP ABI
static inline char *vstr_str(vstr_t *vstr) {
^~~~~~
```
Sleuthing steps:
* verify that the feather_stm32f4_express board builds correctly
* put a `#error` at the bottom of the `mpstate.c` file.
* build for the feather and swan boards, with V=2 to capture the build command for that file.
* use a differencing tool to inspect the differences between the two invocations
* inspecting the differences, I saw a missing `-mcpu=cortex-m4` I tested by adding that to the Swan build command. The file built fine (stopping at the hard error, but no other warnings.)
A grep through the sources revealed where this flag was being set for the stm ports.
With this commit, the build gets further, but does not complete. The next exciting episode in this unfolding coding saga is just a commit away!
working build with minimal set of modules for the Blues Swan r5
chore:change header copyright name to Blues Wireless Contributors
USB operational. Fixed up clocks to be hardwired for LSE no HSE case. (Trying to combine HSE in there made the code much more complex, and I don't have a board to test it out on.)
USART working
adds support for `ENABLE_3V3` and `DISCHARGE_3V3` pins. I am surprised that pin definitions are quite low-level and don't include default direction and state, so the code currently has to initialize `ENABLE_3V3` pin as output. The LED takes over a second to discharge, so I wonder if the board startup code is not having the desired affect.
short circuit implementation of backup memory for the STM32L4
all the ports
remove company name from board name to be consistent with the Arduino board definition.
add default pins for I2C, SPI and UART, so that `board.I2C` et al. works as expected. Confirmed I2C timing.
fix board name
fix incorrect pin definition. add test to allow manual check of each output pin
analog IO
code changes for WebUSB. Doesn't appear to work, will revisit later.
ensure that `sys.platform` is available
checkin missing file
feat: make room for a larger filesystem so the sensor tutorial will fit on the device.
fix:(stm32l4r5zi.csv): merged AF0-7 and AF8-15 into single lines and removed extraneous headers mixed in with the data.
fix(parse_af_csv.py): pin index in the csv is 0 not 1, and AF index made 1 larger
chore(Swan R5): update peripherals pins from `parse_af_csv.py` output
optimize flash sector access
* Reduce the number of supported HID reports of IDs per descriptor.
This saves ~200 bytes in the default HID objects.
* (Not enabled) Compute QSTR attrs on init. This trades 1k RAM for
flash. Flash is the default (1).
The default KEYBOARD report descriptor had a signed/unsigned error,
and also could have allowed more keycodes. So I changed it, using the
very vanilla descriptor from a very plain extremely common commercial
keyboard, modifying it only have 5 LED's instead of 3, and added a
report ID.
* The new nonstandard '%S' format takes a pointer to compressed_string_t
and prints it
* The new mp_cprintf and mp_vcprintf take a format string that is a
compressed_string_t
* fix absolute_transform dirtying early instead of after the change, missing the draw
* fix transpose and mirror. (0,0) -> location in all vector shapes now in all rotations.
now works with all vector shapes, even those with internal reference locations
that are negative. All shape locations are anchored to their 0,0 but they can
display pixels from negative coordinates if the shape's location on the screen
would have room for it.
* add heuristic to avoid drawing area unnecessarily
* fix Polygon.points
* fix transpose
* fix mirror x and y
Known broken:
Polygon with negative Y coordinates does not work right.
* Removes VectorShape from user python interactions
* Re-integrates vectorio with displayio behind draw protocol implementations
* Implements draw protocol with VectorShape
* Composes VectorShape behaviors into Rectangle, Circle and Polygon
* Fixes terrible pixel garbage being left behind
* Improves redraw performance (heuristically) by tracking dirty area separately from current area.
Known Issues:
It does not work with transposed views.
Call `supervisor.disable_ble_workflow()` and the BLE workflow will
be disabled until the chip is reset.
This also includes a couple fixes:
1. Terminals can now be deinit by setting the tilegrid to NULL. This
prevents using the tilegrid before display is init.
2. Fix BLE serial send amount when sending more than a single packet.
Fixes#5049
This is a breaking change with previous palette semantic with respect to python code that uses vectorio.
Displayio has breaking changes in cpy 7 for Group's removal of max_size parameter so this is as good a
time as any to break everything.
Currently:
To color vectorio shapes correctly you have to pass in a palette with length 2. Palette[0] must be set transparent and palette[1] must be the color you want.
New:
To color vectorio shapes correctly you pass in a palette with length >= 1. Palette[0] will be the color of the shape.
Also improves pixels per second when skipping areas that aren't covered by the shape.
Before, when an OnDiskBitmap was a paletted bitmap type, the palette
was internal to the OnDiskBitmap, and it internally performed the palette
conversion itself. When using with a tilegrid, a ColorConverter() object
always had to be passed.
Now, an OnDiskBitmap has a "pixel_shader" property. If the bitmap is
a paletted bitmap type, it is a (modifiable) Palette object. Otherwise,
it is a ColorConverter() object as before. This allows palette effects
to be applied to paletted OnDiskBitmaps.
Code that used to say:
```python
face = displayio.TileGrid(odb, pixel_shader=displayio.ColorConverter())
```
must be updated to say:
```python
face = displayio.TileGrid(odb, pixel_shader=odb.pixel_shader)
```
Compatible code for 6.x and 7.x can say
```python
face = displayio.TileGrid(odb, pixel_shader=getattr(odb, 'pixel_shader', ColorConverter())
```
We can't handle rgbmatrix's interrupts from here until the display is
reinitialized, so set the display as paused.
With this change, I can survive multiple cycles with wifi+rgbmatrix
on an esp32s2. Before, it usually failed.
This also removes the need to pin share because we don't use the
status LED while user code is running.
The status flashes fallback to the HW_STATUS LED if no RGB LED is
present. Each status has a unique blink pattern as well.
One caveat is the REPL state. In order to not pin share, we set the
RGB color once. PWM and single color will be shutoff immediately but
DotStars and NeoPixels will hold the color until the user overrides
it.
Fixes#4133
Unify USB-related makefile var and C def as CIRCUITPY_USB.
Always define it as 0 or 1, same as all other settings.
USB_AVAILABLE was conditionally defined in supervisor.mk,
but never actually used to #ifdef USB-related code.
Loosely related to #4546
It is required to call .dirty() with appropriate arguments after modifications through the buffer protocol, or the display might not be updated correctly.
This is a modest code savings, but more importantly it reduces
boilerplate in bitmap-modifying routines.
Callers need only ensure they call displayio_bitmap_set_dirty_area in
advance of the bitmap modifications they perform.
(note that this assumes that no bitmap operation can enter background
tasks. If an operation COULD enter background tasks, it MUST re-dirty
the area it touches when it exits, simply by a fresh call to
set_dirty_area with the same area as before)
.. simplifying code in the process. For instance, now fill_region
uses area routines to order and constrain its coordinates.
Happily, this change also frees a modest amount of code space.
.. and simplify the implmentation of displayio_area_union
This _slightly_ changes the behavior of displayio_area_union:
Formerly, if one of the areas was empty, its coordinates were still
used in the min/max calculations.
Now, if one of the areas is empty, the result gets the other area's coords
In particular, taking the union of the empty area with coords (0,0,0,0)
with the non-empty area (x1,y1,x2,y2) would give the area (0,0,x2,y2)
before, and (x1,y1,x2,y2) after the change.
When reading uncompressed bitmap data directly, readinto can work
much more quickly than a Python-coded loop.
On a Raspberry Pi Pico, I benchmarked a modified version of
adafruit_bitmap_font's pcf reader which uses readinto instead of
the existing code. My test font was a 72-point file created from Arial.
This decreased the time to load all the ASCII glyphs from 4.9 seconds to
just 0.44 seconds.
While this attempts to support many pixel configurations (1/2/4/8/16/24/32
bpp; swapped words and pixels) only the single combination used by
PCF fonts was tested.
This is a first go at it, done by naive replacing of all array
operations with corresponding operations on the list. Note that
there is a lot of unnecessary type conversions, here. Also, list_pop
has been copied, because it's decalerd STATIC in py/objlist.h
Since we want to expose the list of group's children to the user,
we should only have the original objects in it, without any other
additional data, and compute the native object as needed.
* Comment on the reason for scaling by 256
* Divide by 256 instead of shifting
* fix a cast; eliminate an unneeded roundf() to get a few bytes code back
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).
Also found a race condition between timer_disable and redraw, which
would happen if I debugger-paused inside common_hal_rgbmatrix_timer_disable
or put a delay or print inside it. That's what pausing inside reconstruct
fixes.
So that the "right timer" can be chosen, `timer_allocate` now gets the `self`
pointer. It's guaranteed at this point that the pin information is accurate,
so you can e.g., find a PWM unit related to the pins themselves.
This required touching each port to add the parameter even though it's
unused everywhere but raspberrypi.
* Introduce explicit serpentine: bool argument instead of using negative
numbers (thanks, ghost of @tannewt sitting on one shoulder)
* Fix several calculations of height
Testing performed (matrixportal):
* set up a serpentine 64x64 virtual display with 2 64x32 tiles
* tried all 4 rotations
* looked at output of REPL
Changed calls: PointSize(), LineWidth(), VertexTranslateX() and VertexTranslateY()
Units for all the above are now pixels, not fixed-point integers. This matches OpenGL.
Docstrings updated accordingly
The RP2040 is new microcontroller from Raspberry Pi that features
two Cortex M0s and eight PIO state machines that are good for
crunching lots of data. It has 264k RAM and a built in UF2
bootloader too.
Datasheet: https://pico.raspberrypi.org/files/rp2040_datasheet.pdf
