| commit | 41fa1a71c5a7e11dbe1aa41239aae879cffcf907 | [log] [tgz] |
|---|---|---|
| author | pigweed-roller <pigweed-roller@pigweed-service-accounts.iam.gserviceaccount.com> | Sat Jul 13 18:10:51 2024 +0000 |
| committer | CQ Bot Account <pigweed-scoped@luci-project-accounts.iam.gserviceaccount.com> | Sat Jul 13 18:10:51 2024 +0000 |
| tree | 937ae76e486763e3e61d75f9153649e857aa7715 | |
| parent | 85635ac05aa85dac3d9c5f4a6e34395ce6510e94 [diff] |
roll: pigweed, pw_toolchain: pw_bluetooth_sapphire: Update LowEnergyAdvertiser to use std::vector The current implementation for LowEnergyAdvertiser and its subclasses all assume a single set of LE extended advertising HCI commands. LowEnergyAdvertiser orchestrates the advertising process by calling out to pure virtual methods (e.g. BuildEnablePacket, BuildSetAdvertisingParams, etc) to generate the HCI command packets to be sent to the controller. Extended advertising PDUs can send up to 1,650 bytes of advertising or scan response data. However, this total is fragmented across multiple extended advertising PDUs. In preparation for extended advertising PDUs, we need a way for LowEnergyAdvertiser subclasses to indicate to LowEnergyAdvertiser that they have multiple sets of LE extended advertising HCI commands to send. This change modifies the pure virtual method packet builder API of LowEnergyAdvertiser::BuildSetAdvertisingData and LowEnergyAdvertiser::BuildSetScanResponse to indicate that it can generate multiple packets (e.g. a return value of std::vector<EmbossCommandPacket>). Other LowEnergyAdvertiser subclasses such as LegacyLowEnergyAdvertiser and AndroidExtendedLowEnergyAdvertiser simply return back an std::vector of size one. Original-Bug: b/312898345 Original-Bug: b/309013696 Test: fx test //src/connectivity/bluetooth/core/bt-host Original-Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/1017324 GitOrigin-RevId: 2afd52f9393d3ebbee080c1a44d2db2b6f177f4f Original-Reviewed-on: https://pigweed-review.googlesource.com/c/pigweed/pigweed/+/221023 Lint: Lint 🤖 <android-build-ayeaye@system.gserviceaccount.com> https://pigweed.googlesource.com/pigweed/pigweed pigweed, pw_toolchain Rolled-Commits: f150ac17e8fde07..a12f93925d8d184 Roller-URL: https://ci.chromium.org/b/8742505464219387313 GitWatcher: ignore CQ-Do-Not-Cancel-Tryjobs: true Change-Id: I8f9feb66307d0948641f55c2b4f7b5551e7fc73e Reviewed-on: https://pigweed-review.googlesource.com/c/pigweed/quickstart/bazel/+/222648 Bot-Commit: Pigweed Roller <pigweed-roller@pigweed-service-accounts.iam.gserviceaccount.com> Commit-Queue: Pigweed Roller <pigweed-roller@pigweed-service-accounts.iam.gserviceaccount.com> Lint: Lint 🤖 <android-build-ayeaye@system.gserviceaccount.com>
This repository contains a minimal example of a Bazel-based Pigweed project. It's an echo application for the STM32F429 Discovery Board.
git clone --recursive https://pigweed.googlesource.com/pigweed/quickstart/bazel
If you already cloned but forgot to include --recursive, run git submodule update --init to pull all submodules.
TODO: b/300695111 - Don't require submodules for this example.
We‘ll assume you already have Bazel on your system. If you don’t, the recommended way to get it is through Bazelisk.
To build the entire project (including building the application for both the host and the STM32 Discovery Board), run
bazel build //...
To run the application locally on your machine, run,
bazel run //src:echo
To flash the firmware to a STM32F429 Discovery Board connected to your machine, run,
bazel run //tools:flash
Note that you don't need to build the firmware first: Bazel knows that the firmware images are needed to flash the board, and will build them for you. And if you edit the source of the firmware or any of its dependencies, it will get rebuilt when you flash.
Run,
bazel run //tools:miniterm -- /dev/ttyACM0 --filter=debug
to communicate with the board. When you transmit a character, you should get the same character back!