GitLab

In the `ble` module, we maintain a copy of observed advertisement data
that is updated during servicing of PBIO (contiki) events. These events
can be triggered any time the GC is invoked, e.g. during allocation of
memory for MicroPython objects.

In pb_module_ble_observe(), we were iterating over the observed data
and allocating new MicroPython objects for each item which could trigger
PBIO events to be run resulting in the observed data being modified
while we are still iterating over it. This could result in a crash, the
most likely of which is raising an exception for an invalid data type.

We can avoid this by making a copy of the data before iterating over it.

Fixes: https://github.com/pybricks/support/issues/1278

This finishes up the REVISIT comment in start_broadcasting_task() to
actually wait for the set advertising data command to complete before
the task completes.

This fixes issues with calling the task too fast while the commands
from the previous call are still pending.

The timer was used to work around the issue but is no longer needed.

Fixes: https://github.com/pybricks/support/issues/1151

When broadcasting, the advertising parameters dont' change, so we only
need to set them once when we start broadcasting. This is done by
moving the code inside the if statement along with the enable function.

This changes the GAP discoverable parameters to limit connecting to
devices in a whitelist. Normally, when broadcasting, the hub should
not be connectable, but due to some quirks of the Bluetooth chip,
ADV_NONCONN_IND doesn't work under all circumstances and we have to use
ADV_IND which makes the device connectable. If another device connects
while broadcasting, it currently causes things to lock up. However,
we can prevent devices from connecting in the first place by enabling
the whitelist (which is empty).

This changes the command to update advertising data on the Bluetooth
chip in the broadcast task to use HCI_LE_setAdvertisingData() instead of
GAP_updateAdvertisingData().

It appears there is some sort of memory leak or some such on the
Bluetooth chip that causes it to lock up if we call the vendor-specific
GAP_updateAdvertisingData() too many times. It appears that we can work
around this by calling the standard Bluetooth command
HCI_LE_setAdvertisingData() instead.

GAP_updateAdvertisingData() would result in two events being sent back
from the Bluetooth chip, a status event and a command complete event.
With HCI_LE_setAdvertisingData() we only get a command complete event
back - with the TI vendor-specific opcode as if we had called
GAP_updateAdvertisingData().

Fixes: https://github.com/pybricks/support/issues/1095

Since efda5d02 ("drv/bluetooth_stm32_bluenrg: strict ordering of BLE
tasks"), it is no longer safe to call pbio_task_run_once() anywhere but
in the main contiki process loop of Bluetooth drivers.

This could break canceling some Bluetooth operations (causing them to
hang), but this will need to be fixed in a different way. A FIXME
comment with some suggestions is added to remind us to fix this.

This reverts commit a50ff187.

The Bluetooth drivers have task queues that prevent more than 1 task
from running concurrently.

The reverted change broke this safety mechanism by pumping tasks from
MicroPython causing multiple tasks to run at the same time, overwhelming
the Bluetooth chip.

We were always reading/writing 3 extra bytes because we weren't taking
into account the 3 extra bytes already sent for the header.

Also, real_write_xfer_size is unsigned and can be zero, so we should
not be subtracting from it.

Also, also, add some comments to clarify where the FCS (checksum) byte
comes into play.

The Move Hub cannot have true vector axes, but we can still use this API to initialize the hub using numeric indices.

This ensures we can use the custom orientation not just in tilt, but also in acceleration like we do on other hubs.

This object does not have an attribute handler, causing any imu read operation to crash the hub.

Fixes https://github.com/pybricks/support/issues/1269

Fixes https://github.com/pybricks/support/issues/1162

Fixes https://github.com/pybricks/support/issues/881

Fixes https://github.com/pybricks/support/issues/1151

Previously, tasks were only driven by Bluetooth events
so timers would not work correctly.

This is more consistent with the rest of our API where collections are returned.

Since None is used to indicate no data, it is more intuitive avoid it as a data type.

This will also allow us implement it such that broadcast(None) stops broadcasting, equivalent to reading None in observe. This is marked as a TODO for future implementation.

This makes it simple to send and receive single values.

It is also necessary for an upcoming non-Python implementation.

This ensures the same object is sent and received.

Fixes https://github.com/pybricks/support/issues/1213

This was putting the sensor in the wrong mode.

Fixes https://github.com/pybricks/support/issues/1232

This was called before the drivebase could be used, and the error was not returned.

Fixes 3ae1fb89 (which was unreleased).

Keep singular for backwards compatibility.

Fixes https://github.com/pybricks/support/issues/1254

Also ensure we pick the proper sign for v in radial computations.

With the newly introduced color cost function, any measured value less than 50 results in Color.NONE, which makes it the predominant result. This reduces the distance range for the default colors.

Instead of adjusting all colors (which are also used to emit colors), we can make the value of Color.NONE negative to achieve a similar result.

The newly introduced color cost function intrinsically deals with low s and v, so we don't need to artificially suppress them here.

This new distance function estimates the similarity of two hsv
colors by calculating their euclidean distance when mapped into a
Hue-Chroma-Lightness bicone. This is much more robust for realistic
colors, especially when low saturation or low value is involved.

For color detection applications, negative h can be used to increase the contrast between "no color" and any other color.

For most other application, the value has a lower bound of 0, which is what this commit enforces.

Fixes https://github.com/pybricks/support/issues/1189

Since we added the use_gyro() method to turn the gyro on and off, we no
longer need a separate GyroDriveBase class.

It was placed in legodev_pup to avoid the need for an extra process. But since it isn't enabled on Move Hub anyway, it makes more sense to place it where it belongs.

This makes the main uart thread cleaner. Instead of resetting one thread with PT_INIT midway from another thread, organize them as follows:

- spawn synchronization, exit on error
- run send + receive in parallel until no data

This in turn can be spawned from the higher level process on platforms that support device detection, or just called indefinitely on platforms where uart mode is always active.