There is an issue (https://github.com/bbc/microbit-extras/issues/2755)
whereby CCCD data is required to be persisted through device resets.
This commit integrates the new MicroBitStorage class, and persistently
stores this information in flash.
P.S. what a long night!
Integrated simple 1K block buffer to host small amount of persistent
data and a 1K FLASH memory block located immediately below the FOTA/DFU
bootloader and APPDATA region that intended to hold core configuration
information, such as:
* BLE bonding information.
* Compass Calibration data.
* Thermometer Calibration data.
The block is resident at 0x0003B400 - 0x0003B800.
Missed a zero in a previous commit, that caused a system lockup due to
a missed timer event.
This commit also changes the minimum display brightness to 4, to also
minimise another feature that needs fixing in the future, where the
timer does not interrupt in the expected time frame.
Previously the range of MicrobitLightSensor read() was 0 - 100,
this didn't align with other APIs.
The new range is 0-255 which aligns with display brightness to give
a more consistent overall API.
Previous revisions of microbit-dal would handle the case of a bonding request
when the bond table was full by attempting to purge the bonding table on
demand. This suffered two flaws:
1) Nordic's device manager does not support the purging of the bonding table
while a connection is active (including a pairing request).
2) Some devices (e.g. Android 4.4.2 take two entries in the bonding table
when paired), thus making predictions of how 'full' the table is challenging.
This patch employs a simpler replacement policy. The maximum size of the bond
table has been increased to 6 (from 4). However, if the bond table contains 4
or more entries when entering pairing mode it will be purged in advance of any
pairing requetss being initiated.
* This commit fixes an exposed member variable
that was not intended to be public 'tickPeriod'
* normalised the light level to return values between 0 - 100
The BLE stack locks out the CPU for long periods of time when necessary. This
can be alleviated by eans of a flag that release the CPU between radio events.
(BLE_COMMON_OPT_RADIO_CPU_MUTEX).
This can cause issues from applications with tighter timing requirements.
This patch only enables this MUTEX when a BLE connection is active, rather
than automatically at startup. Therefore, application that do not actively use
BLE will not suffer this penalty.
Integration of new radio mode that permits simple local area multicast communication
directly between micro:bits using the device's on board radio hardware.
It should be noted that this implementation build directly on the nrf51822
hardware. It is not a BLE protocol, and must (currently) be operated with BLE
disabled.
A standard on the wire configuration is defined, to promote future
interoperability between projects and languages. A lightweight
packet format is also defined and adhered to, so as to promote future
extensibility without sacrificing compatibility. The notion of groups is also
introduced, that enable multiple groups of children to work in the same area
without compromising each other's projects.
In adition to a low level packet radio driver, two higher level protocols are
defined that allow simple user datagram communication between micro:bits and
an EventBus protocol that allows the micro:bit's MessageBus to be extended to
other micro:bits.
New registered eventcodes added for:
- Game controller functions in the micro:bit app
- General broadcast event ID in preparation for broadcast radio capability
Previously, to light sense a user would have to configure a
MicroBitLightSensor instance themselves, and flip the display mode
manually. This is difficult in languages that target our API.
This commit resolves that by adding a new method readLightLevel which
flips the display mode, and instantiates a light sensor.
When changing the mode, the tickSpeed is also modified to reduce
artefacts on the display.
Added a new class called MicroBitLightSensor which interleaves sensing
with the display.
This class takes advantage of the previous commits which add a dynamic
system tick, and a new display mode for the display.
A future optimisation would be for the display to handle the instantion
of a light sensor when the display mode is changed!
This commit adds a mutator that dynamically reconfigures the
systemTicker to call systemTick at a different period to the default.
The accessor returns the current tick speed in milliseconds.
The accessor is now also used in scheduler_tick to keep timing as
accurate as possible.
MICROBIT_DISPLAY_REFRESH_PERIOD has now been removed, and replaced with
MICROBIT_DEFAULT_TICK_PERIOD.
This commit introduces a new display mode,
DISPLAY_MODE_BLACK_AND_WHITE_LIGHT_SENSE, where the 4th render in
every “frame” is dropped allowing for other components that use the
display to use this dropped frame for processing. This is in
preparation for Light Sensing on the 5x5 LED matrix.
An accessor has also been added to MicroBitDisplay to check the current
display mode!
BLE maintains metadata on its characterisitics, some of which record whether
or not a central device (phone/tablet) wishes to receive notifications when a
given BLE characteristic changes value. One such characterisitic is used as
part of a core BLE service to indicate of the BLE profile of a device has
changed.
IOS is heavily reliant on this feature, and expects the state of this metadata
to be persistent across device reboots. This patch ensures that this metadata
is always set to allow Service Changed indications to be propagated to central
devices.
As per https://github.com/lancaster-university/microbit-dal/issues/83 the comment in the MicroBitI2c.h file lacked context around a known hardware glitch. This commit rectifies this issue by adding a link to a collection PDF providing a more detailed explanation.
calibration
MicroBitCompass initiates a calibration procedure on demand if a heading is
requested from an uncalibrated device. The BLE MagnetometerService also
attempts to retrieve a heading periodically, but it is not good behaviour to
initiate calibration as a response to this.
This patch introduces a check such that the BLE MagnetometerService will only
attempt to read heading data from a previously calibrated compass.
