GitLab

When the file system is not enabled, the boot.py and main.py modules will
still be executed, if they are frozen.

Fixes issue #5159.

The size of the event ringbuf was previously fixed to compile-time config
value, but it's necessary to sometimes increase this for applications that
have large characteristic buffers to read, or many events at once.

With this commit the size can be set via BLE.config(rxbuf=512), for
example.  This also resizes the internal event data buffer which sets the
maximum size of incoming data passed to the event handler.

This allows the user to explicitly select the behaviour of the write to the
remote peripheral.  This is needed for peripherals that have
characteristics with WRITE_NO_RESPONSE set (instead of normal WRITE).  The
function's signature is now:

    BLE.gattc_write(conn_handle, value_handle, data, mode=0)

mode=0 means write without response, while mode=1 means write with
response.  The latter was the original behaviour so this commit is a change
in behaviour of this method, and one should specify 1 as the 4th argument
to get back the old behaviour.

In the future there could be more modes supported, such as long writes.

The default protection for the BLE ringbuf is to use
MICROPY_BEGIN_ATOMIC_SECTION, which disables all interrupts. On stm32 it
only needs to disable the lowest priority IRQ, pendsv, because that's the
IRQ level at which the BLE stack is driven.

This removes the limit on data coming in from a BLE.gattc_read() request,
or a notify with payload (coming in to a central).  In both cases the data
coming in to the BLE callback is now limited only by the available data in
the ringbuf, whereas before it was capped at (default hard coded) 20 bytes.

Instead of enqueue_irq() inspecting the ringbuf to decide whether to
schedule the IRQ callback (if ringbuf is empty), maintain a flag that knows
if the callback is on the schedule queue or not.  This saves about 150
bytes of code (for stm32 builds), and simplifies all uses of enqueue_irq()
and schedule_ringbuf().

This board doesn't have much flash and removing these unneeded names saves
about 900 bytes of code size.

qstrs in this file are always included in all builds, even if not used
anywhere.  So remove those that are never needed, and make USB names
conditional on having USB enabled.

To allow the future possibility of initial positional args, like flash id.

With the memcpy() call placed last it avoids the effects of registers
clobbering.  It's definitely effective in non-inlined functions, but even
here it is still making a small difference.  For example, on stm32, this
saves an extra `ldr` instruction to load `o->vstr` after the memcpy()
returns.

The string length being longer than the allowed qstr length can happen in
many locations, for example in the parser with very long variable names.
Without an explicit check that the length is within range (as done in this
patch) the code would exhibit crashes and strange behaviour with truncated
strings.

To prevent a crash returning MP_OBJ_NULL.  A test is added for this case.

And return -MP_EIO if calling storage_read_block/storage_write_block fails.
This lines up with the return type and value (negative for error) of the
calls to MICROPY_HW_BDEV_READBLOCKS (and WRITEBLOCKS, and BDEV2 versions).

To hint to the block device that the extended block protocol will be used.

The pyb.Flash() class can now be used to construct objects which reference
sections of the flash storage, starting at a certain offset and going for a
certain length.  Such objects also support the extended block protocol.
The signature for the constructor is: pyb.Flash(start=-1, len=-1).

This commit refactors and generalises the boot-mount routine on stm32 so
that it can mount filesystems of arbitrary type.  That is, it no longer
assumes that the filesystem is FAT.  It does this by using mp_vfs_mount()
which does auto-detection of the filesystem type.

Extracts name and service UUID fields.

The address, adv payload and uuid fields of the event are pre-allocated by
modbluetooth, and reused in the IRQ handler.  Simplify this and move all
storage into the `mp_obj_bluetooth_ble_t` instance.

This now allows users to hold on to a reference to these instances without
crashes, although they may be overwritten by future events.  If they want
to hold onto the values longer term they need to copy them.

Using mp_hal_delay_ms allows the scheduler to run, which might result in
another transmit operation happening, which would bypass the sleep (and
fail).  Use mp_hal_delay_us instead.

No need for this to throw an exception if the intent (don't be scanning) is
clear, and avoids a race with the scan duration timeout.