Defensively tear down DMA/PIO so it's in a known good state upon (soft)reset.
Issue was a race condition with DMA interrupts firing and not being achknowledged, leaving a stuck raised IRQ.
The blocking wait for DMA transactions also exacerbated this, turning a borken DMA interrupt and blank screen into an unrecoverable hardlock.
...not that the blank screen was recoverable without a soft reset anyway!
Switch from 12-bit to 10-bit gamma to fit RGB into a uint32_t. Simplifies PIO and halves the RAM usage for F/B buffer.
Switch "flip" to *literally* swap the front and back buffers, and then asyncronously DMA the new back buffer into the front ready for the next draw.
The ST7789's Tscycw (time between serial write clock cycles) is
16 ns. This can be found on page 44 of the datasheet I'm using:
https://www.waveshare.com/w/upload/a/ae/ST7789_Datasheet.pdf
(I do not know which manufacturer Pimoroni products use and if
their parts might be different. But it seems like this wouldn't
change.)
The existing code sets the SPI baud to 16 * 1000 * 1000. But baud
is Hz, not seconds. That 16 * 1000 * 1000 doesn't represent 16 ns.
It represents 16,000,000 Hz.
16 ns * (1 Hz / s) = 62,500,000 Hz.
This commit changes the baud from 16 * 1000 * 1000 to 62'500'000,
representing ~4x speed improvement in SPI and thus ~4x frame rate
improvement, since the display's frame rate is currently
SPI-limited.
A before & after video can be seen here:
https://www.youtube.com/watch?v=n2y19TCnATo
Note that also on page 44 of that datasheet Tscycr (the read speed)
is only 150 ns, not 16 ns. Right now, the Pimoroni code doesn't read
any values back from the ST7789 so it is safe to operate at the
higher speed.
Also note that the 16 * 1000 * 1000 is the requested baud. The actual
baud is the closest the Pico can get, which is 15,625,000.
The new requested baud of 62'500'000 results in an exact match.
Moves the 256 entry GAMMA table into pimoroni_common.
Should probably be added into a library so MicroPython is built with only one instance of the table.
Add the init required for the 320x240 2.0" LCD.
Add an option to set baudrate, 320x240 needs 74MHz for 60FPS
Add library and example for 320x240 2.0 LCD.
This covers an edge case where pixels are updated intermittently - such as the once that happens when clearing before a Python soft reset.
Under normal circumstances users should `start` the LED strip and allow it to continuously update.
We chased a bug with handling/clearing interrupts on Encoder into the depths of madness, finding that a Debug build would magically fix the bug.
Turns out it was probably just us being a little aggressive with the poor little MS51-based Encoder driver.
* Fix delays to be more delayey.
* Replace big 'ol loop and boolean with straight up checks and an early exit- the bit-addressed regs are never going to change
Adds an ifdef guard around `pio_sm_unclaim` that prevents it being called when MicroPython cleans up/finalizes classes.
For some reason this appeared to be causing a hardfault.
Library:
Includes classes for driving WS2812 and APA102 LEDs and defines for Plasma features.
Encoder Example:
Supports connecting a Rotary Encoder via the Qw'St connector.
Works with APA102 or WS281X pixels.
Pressing A will cycle between:
1. Colour change
2. Brightness change
3. Cycle delay
Pressing B will switch back into auto-cycle mode.
Turning the encoder at any time will switch out of auto cycle mode into parameter adjust mode.
Also includes a bugfix to Rotary Encoder for getting the interrupt correctly.
Rainbow Example:
Basic rainbow cycle, press B to speed up and A to slow down.
The BME68X library is *linked* against the MicroPython bindings, rather than compiled directly in.
This saves specifing the list of target files twice.
This changeset brings the BOSCH BME68X Sensor API library in as a submodule and makes it buildable with CMake.
A thin wrapper- the BME68X driver- provides simple init, configure, read_forced and read_parallel functions.
Two BME688 examples are available for forced-mode and parallel-mode operation.
"RGBLED" PWMs 3 pins as a single RGB LED and exposes methods to set the colour via HSV/RGB.
"Button" handles tracking the state and changed state of a single GPIO button, in addition to supporting auto-repeat for held-down buttons.
The switch to common I2C and common definitions for SPI had broken an edge case in Pico Explorer where no backlight pin is used.
The backlight pin was inadvertently set to the front Breakout Garden SPI slot default, which is pin 20- this also happens to be the I2C SDA pin for Pico Explorer, breaking I2C comms.
This fix adds a new special case board "PICO_EXPLORER_ONBOARD" so that ST7789 can be initialised without the backlight pin.
This will be useful for anyone using ST7789 without the rest of the Pico Explorer library, although it feels a little contrived.
Also switches ST7735 over to the common defines.
Removes i2c_inst_t from constructors since it's ignored, and updated the Python bindings not to supply this argument. Instance is inferred from the supplied pins.
Removes all driver-specific SDA/SCL pin definitions and defaults.
Pin type is "uint" everywhere, but "PIN_UNUSED" is *int*_max for MicroPython compat. That's still a lot of pins!
Adds baudrate to the I2C class, and allows a driver (like Trackball) to check the baudrate is supported
This change adds a common I2C class, gathering various I2C functions into a single point of responsibility.
It's necessary for correctly managing the I2C bus pins and state across multiple devices.
* Add a common/pimoroni.hpp to list default pins for various add-ons
* Move the BG SPI Slot enum here for safe keeping
* Switch all GPIO pin references to "uint" to match Pico SDK and bring back PIN_UNUSED as UINT_MAX
Confused myself by plugging this into a BG base. It gave all the appearance of working, but the time was not counting up.
Turns out the library will happily talk to no device whatsoever and when you "set_time" it's stored in an C array and returned as if it came from the RTC.