With the Kaluga devkit, the camera interferes with the JTAG function.
However, having DEBUG turned on e.g., to get extended debug information
on the UART debug connection remains useful.
Now, by arranging to add to CFLAGS += -DDEBUG -DENABLE_JTAG=0, this
configuration is easy to achieve.
It's intended that the actual timeout always be at least the requested
timeout. However, due to multiplying by the wrong factor to get from
seconds to cycles, a timeout request of e.g., 8.1s (which is less than
8.192s) would give an actual timeout of 8, not 16 as it should.
Now that there are feature levels, and that this port uses
MICROPY_CONFIG_ROM_LEVEL_MINIMUM, it's easy to see what optional features
can be disabled. And this commit disables them.
Signed-off-by: Damien George <damien@micropython.org>
Word-size specific configuration is now done automatically, so it no longer
requires this to match the ARM configuration.
Also it's less common to have 32-bit compilation support installed, so this
will make it work "out of the box" for more people.
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
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.
This is an stm32-specific feature that's accessed via the pyb module, so
not something that will be widely enabled.
Signed-off-by: Damien George <damien@micropython.org>
This commit is a no-op change. Future improvements can come from making
individual boards use CORE or BASIC.
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
Prior to this commit IRQs on STM32F4 could be lost because SR is cleared by
reading SR then reading DR. For example, if both RXNE and IDLE IRQs were
active upon entry to the IRQ handler, then IDLE is lost because the code
that handles RXNE comes first and accidentally clears SR (by reading SR
then DR to get the incoming character).
This commit fixes this problem by making the IRQ handler more atomic in the
following operations:
- get current IRQ status flags
- deal with RX character
- clear remaining status flags
- call user handler
On the STM32F4 it's very hard to get this right because the only way to
clear IRQ status flags is to read SR then DR, but the read of DR may read
some data which should remain in the register until the user wants to read
it. And it won't work to cache the read because RTS/CTS flow control will
then not work. So instead the new code disables interrupts if the DR is
full and waits for the user to read it before reenabling the interrupts.
Fixes issue mentioned in #4599 and #6082.
Signed-off-by: Damien George <damien@micropython.org>
Following on from ba940250a5b630018c8d9b0e21c5ed858a20450f, the change here
makes output about 15 times faster (now up to about 550 kbytes/sec).
tinyusb_cdcacm_write_queue will return the number of bytes written, so
there's no need to use tud_cdc_n_write_available.
Signed-off-by: Damien George <damien@micropython.org>
