Tested with a rp2040.
TODO: add the ability to set the absolute humidity for more accurate
sensor details. The formula for that is rather complex, so I've left
this as a future addition.
Replace DrawRGBBitmap8 with DrawBitmap, following the change in the
previous commit.
This improves performance from 86fps to 100fps! I didn't investigate
why, but I suspect it's because it now needs only a single store instead
of two to update a pixel.
Same as for st7735 in the previous commit.
In addition, this avoids allocating a big chunk of memory on _every_
draw operation (even SetPixel) and instead reuses it across draw
operations. This makes the driver a whole lot more efficient.
Using RGB444 instead of RGB565 can speed up graphics operations by up to
25%, especially on slow screens. But for full support, all parts of the
driver need to be aware of the color format.
It's possible to do this using a regular configuration variable, but
it's unlikely to be very efficient. Hence the usage of generics.
This has been optimized for working with SPI displays like the ST7789.
By working directly in the native color format of the display, graphics
operations can be much, _much_ faster.
Also, this makes it easier to use a different color format like RGB444
simply by changing the generic type.
The previoius behavior was that entirely black pixels were treated as
white, and anything else as black. That's at least counter-intuitive.
This patch changes the behavior to actually look at the color values and
use a cutoff around medium gray: darker colors are treated as black, and
lighter colors are treated as white.
This is a backwards incompatible change, but I think this behavior makes
a lot more sense.
This commit updates rotation behavior to match other displays.
For more information, see: https://github.com/tinygo-org/drivers/pull/550
This changes the signature of `SetRotation` but I don't think any
existing code will be affected by this change.
named channel, do the same for RegionSettings, and then change RegionSettings to
just Settings to avoid the redundant naming.
Signed-off-by: deadprogram <ron@hybridgroup.com>
For details, see: https://github.com/tinygo-org/tinygo/pull/3927
This change just means we need to be more careful to use the right type,
now that types like C.uint32_t don't match to the Go equivalent (like
uint32).
I wrote this for the PineTime, and all available sensors (accelerometer,
step counter, temperature sensor) do work.
This commit also includes two "configuration files", that actually
appear to be firmware files to run on the accelerometer for special
features like step counting.
I'm not sure where they originally came for, and I don't know the
copyright status of them. However, Bosch has open-sourced the BMA423
driver which includes a similar binary blob and the InfiniTime and
Wasp-OS projects have been shipping these blobs without issues, so I
think it's reasonably safe to include these binary blobs directly in the
source.
The rotation as configured using st7789.Config was rotated 180°: 0° was
configured as 180°, 90° was configured as 270°, etc. Presumably with the
original test display, the ribbon cable was seen as the top of the
screen while if you look at product photos it is usually at the bottom.
Example:
https://www.buydisplay.com/wide-angle-1-3-inch-240x240-color-ips-tft-display-st7789-controller
Only Adafruit seems to sell these displays upside down:
https://www.adafruit.com/product/3787
This patch fixes this mistake. It should be noted that this is backwards
incompatible: all code that uses a st7789 will have to be modified to
use the correct rotation instead of the previous incorrect rotation.
If this is too big of a change, we could just keep things as-is and
pretend that all displays are upside down.
The existing code was broken in a few ways:
- It didn't use the correct operator precedence for the VSCRDEF VSA
variable: it needed some extra parentheses to be correct.
- It used the configured height instead of the actual display height
for calculating VSA, which is incorrect. TFA+VSA+BFA must always be
exactly 320, even if a lower value is configured.
- If a lower than 320 pixel height is configured, the bottomFixedArea
parameter applied to the whole 320 pixel screen height. Because this
seems counter intuitive (and relies on properties of any given
screen), I've changed it to work from the actual visible bottom of
the screen (which may be smaller than 320 pixels).
TODO: this doesn't take RowOffset into account, while it probably
should.
I haven't fixed the st7735 implementation, because I didn't have example
code on hand that would easily work on a st7735 screen. This is left as
a TODO for the future.
This is only really useful for applications that use DrawRGBBitmap8. The
RGB444 format has fewer colors, but can be up to 25% faster than the
default RGB565.
I have tested this change on the Gopher Badge and the PineTime. Both can
be substantially faster once the code is modified to output RGB444
instead of RGB565.