Everything should be using the keypad module instead.
Note: there are several boards that still had gamepadshift enabled. I
did not contact their authors to make sure they already switched to
keypad in their code and documentation. We should probably wait with
merging this for their go ahead.
os.getenv() will use it (when available) to load variables from
/.env
This will also be useful when we need secrets or config for
CircuitPython outside of the VM (like WiFi credentials.)
Fixes#4212
The old formulation
* wouldn't work if there were ID3 tags at the end
* would choose whether to background-refill the inbuf
based on a check before skipping to the next sync word, which
could be incorrect.
I think it was aspect "B" that ended up triggering the erroneous EOF
problem fixed in the prior commit. This would depend on specific data
sizes and offsets occuring in the file such that a read would be
scheduled but then the buffer would be filled and left 100% full by
find_sync_word(). It's just lucky(?) that a particular person produced
such a file, and/or many files produced by Audacity have those
characteristics.
This saves 444 bytes on the pygamer build (both commits taken together)
testing performed:
* pygamer (samd51) with ShiftRegisterKeys
* macropad (rp2040) with Keys
* UM feather s2 (esp32-s2) with KeyMatrix
Result:
* all ports still worked nicely
* keys held down at start always registered (>2 trials all boards, >100 trials esp32-s2)
* keys held down are immediately registered after reset() (>100 trials esp32-s2)
* double .reset() is OK, accessing .events throws (only tested esp32-s2)
Some audio implementations, notably samd, really don't like it when
you return 0 samples of data. This was the case when reaching the
end of an MP3 file.
Now, we read forward in an MP3 file to the next sync word during
"get_buffer", so that we can accurately return GET_BUFFER_DONE when the
NEXT call WOULD HAVE resulted in 0 samples.
Tested with @gamblor21's "laugh.mp3" file on a Trellis M4 Express.
This unifies the delay into the post-run delay that also waits
for user input and fake sleep. This ensures we always delay.
Previous code would only delay if the code.py was running when
autoreload was triggered. Now it will always delay.
We also now suspend autoreload when a USB write starts and then
resume on completion. This should prevent reloading in between
sectors of a single write.
This allows you to list and explore connected USB devices. It
only stubs out the methods to communicate to endpoints. That will
come in a follow up once TinyUSB has it. (It's in progress.)
Related to #5986
Initially enabled for samd51, this enables reading raw flux data as well
as DOS/MFM formatted media.
This is only the low-level code for reading & decoding flux pulses from a floppy drive.
high level details will live in a Python library.
adafruit-circuitpython-floppy will take care of details like stepping
from track to track, etc.
In testing, I saw that the decoded_samples value kept increasing when I
stopped and restarted playback, as I'd missed setting it back to zero
during the reset operation.
In my testing, there is no way to accurately know how far into a MP3 file
you're currently playing. You can use monotonic time, but that can have
drift versus the audio playback system, which may not be running at exactly
the expected sample rate.
To allow syncing animation with timestamps in a MP3 file, this presents a
new property, decoded_samples, that records the number of audio samples
sent out of the decoder. While this may not be a completely accurate time,
due to mixer delays, it's much better position that the monotonic clock
difference.
Implementation is keeping track of this value in the mp3file structure and
adding to it whenever data is sent out of the decoder. The property
implementation was a copy/paste from current properties in the audiomp3
files.
new utility function for all vectorio shape specializations for testing
whether a screen-space x,y point falls within a shape's x,y.
This respects the current orientation of the screen in the manner of
displayio and vectorio - so your x,y requests are in the same coordinate
domain as your x,y locations and your width/height etc. properties that
ou set on other shapes. I.e., if you're using this for touch points then
you will need to make sure the touch events are in the same x,y domain as
your display.
```
contains(2, 4) -> true
------------------
| |
| |
| -- |
| | \ |
| |. \ |
| | \ |
| |____\ |
| |
------------------
contains(5, 4) -> false
------------------
| |
| |
| -- |
| | \ |
| | \. |
| | \ |
| |____\ |
| |
------------------
```
This helps provide low overhead introspection of shape coverage on screen.
It's envisioned that this will be used for things like touch-and-drag
widget controls, touch "areas" and may help with random ornament placement
on toy Christmas trees.
.. which is what the addition of cmd25 made happen. We still signal
an error when failing to reach the idle state at any other time,
which _is_ different than adafruit_sdcard but I think that it is
correct.
This fixed#5600 according to Dan's testing on a GCM4 on the internal
SD card slot. There are still some ambiguous results on the MM4 with
external SD card slot on 6" jumper wires.
this happens to make the occasional FS dither artifact disappear.
I guess `a * b >> 8` and `(a * b) / 256` are not identical. I'm not
sure if it was just the parens or not, but write the clearer code and
rely on the compiler to substitute an appropriate shift if possible.
This targets the 64-bit CPU Raspberry Pis. The BCM2711 on the Pi 4
and the BCM2837 on the Pi 3 and Zero 2W. There are 64-bit fixes
outside of the ports directory for it.
There are a couple other cleanups that were incidental:
* Use const mcu_pin_obj_t instead of omitting the const. The structs
themselves are const because they are in ROM.
* Use PTR <-> OBJ conversions in more places. They were found when
mp_obj_t was set to an integer type rather than pointer.
* Optimize submodule checkout because the Pi submodules are heavy
and unnecessary for the vast majority of builds.
Fixes#4314
This blends two "565"-format bitmaps, including byteswapped ones. All
the bitmaps have to have the same memory format.
The routine takes about 63ms on a Kaluga when operating on 320x240 bitmaps.
Of course, displaying the bitmap also takes time.
There's untested code for the L8 (8-bit greyscale) case. This can be
enabled once gifio is merged.
By having a pair of buffers, the capture hardware can fill one buffer while
Python code (including displayio, etc) operates on the other buffer. This
increases the responsiveness of camera-using code.
On the Kaluga it makes the following improvements:
* 320x240 viewfinder at 30fps instead of 15fps using directio
* 240x240 animated gif capture at 10fps instead of 7.5fps
As discussed at length on Discord, the "usual end user" code will look like
this:
camera = ...
with camera.continuous_capture(buffer1, buffer2) as capture:
for frame in capture:
# Do something with frame
However, rather than presenting a context manager, the core code consists of
three new functions to start & stop continuous capture, and to get the next
frame. The reason is twofold. First, it's simply easier to implement the
context manager object in pure Python. Second, for more advanced usage, the
context manager may be too limiting, and it's easier to iterate on the right
design in Python code. In particular, I noticed that adapting the
JPEG-capturing programs to use continuous capture mode needed a change in
program structure.
The camera app was structured as
```python
while True:
if shutter button was just pressed:
capture a jpeg frame
else:
update the viewfinder
```
However, "capture a jpeg frame" needs to (A) switch the camera settings and (B)
capture into a different, larger buffer then (C) return to the earlier
settings. This can't be done during continuous capture mode. So just
restructuring it as follows isn't going to work:
```python
with camera.continuous_capture(buffer1, buffer2) as capture:
for frame in capture:
if shutter button was just pressed:
capture a jpeg frame, without disturbing continuous capture mode
else:
update the viewfinder
```
The continuous mode is only implemented in the espressif port; others
will throw an exception if the associated methods are invoked. It's not
impossible to implement there, just not a priority, since these micros don't
have enough RAM for two framebuffer copies at any resonable sizes.
The capture code, including single-shot capture, now take mp_obj_t in the
common-hal layer, instead of a buffer & length. This was done for the
continuous capture mode because it has to identify & return to the user the
proper Python object representing the original buffer. In the Espressif port,
it was convenient to implement single capture in terms of a multi-capture,
which is why I changed the singleshot routine's signature too.
The easiest thing to implement was to use the i/j numbers, but they were not
directly related to image x/y coordinates. This may slow things down a tiny
little bit, but it looks much better.
* Increase colorspace conversion efficiency.
This not only avoids a function call, it avoids the time-consuming
switch statement in conver_pixel (replacing it with a single
conditional on the byteswap flag + accounting for BGR/RGB during
palette creation)
* Buffer all the bytes of a single frame together. By reducing
low level write calls we get a decent speed increase even though
it increases data-shuffling a bit.
Together with some other changes that enable "double buffered" camera
capture, this gets me to 8.8fps capturing QVGA (320x240) gifs and
11fps capturing 240x240 square gifs.
This involves:
* Adding a new "L8" colorspace for colorconverters
* factoring out displayio_colorconverter_convert_pixel
* Making a minimal "colorspace only" version of displayio for the
unix port (testing purposes)
* fixing an error message
I only tested writing B&W animated images, with the following script:
```python
import displayio
import gifio
with gifio.GifWriter("foo.gif", 64, 64, displayio.Colorspace.L8) as g:
for i in range(0, 256, 14):
data = bytes([i, 255-i] * 32 + [255-i, i] * 32) * 32
print("add_frame")
g.add_frame(data)
# expected to raise an error, buffer is not big enough
with gifio.GifWriter("/dev/null", 64, 64, displayio.Colorspace.L8) as g:
g.add_frame(bytes([3,3,3]))
```
This increases write rates (of gifio from #5490) from about 2.4fps to over
5fps by making more efficient use of the SD card protocol.
Because of details of oofatfs, it usually manages 64 writes in a single
CMD25, then two writes in a different area of the SD card (presumably,
filesystem metadata). I couldn't find where to increase "64" to a higher
number. This may depend on the allocation size of the filesystem.
I tried preallocating too, but oddly it significantly lowered the write
rate.
Any trailing data is committed when the file is close()d, or when
the `sync` method of the SDCard object is called.
