Find a file
2023-09-23 13:58:33 -05:00
.devcontainer Initial commit for the Development Container config 2023-01-07 15:50:09 +00:00
.github chore(ci): bump actions/checkout from 3 to 4 2023-09-11 01:24:38 +00:00
apps cleanup headers 2023-02-05 18:54:25 +11:00
config Edit config for mics 2023-09-23 13:58:33 -05:00
include/rtos add first commit 2022-08-15 17:20:27 +08:00
platform Remove USB 2023-02-04 10:36:08 +11:00
rtos Removing FPGA dev support 2023-02-02 17:42:33 +11:00
scripts fix(makefile): Use shell-builtins in Makefile 2023-05-19 00:46:44 +01:00
services Switch to opus by default, and support any format 2023-02-19 23:56:44 +01:00
thirdparty Formatting 2023-02-02 07:56:49 +11:00
utils Removing FPGA dev support 2023-02-02 17:42:33 +11:00
.clang-format Create clang-format spec 2023-01-31 21:22:20 +11:00
.gitignore Initial commit for the Development Container config 2023-01-07 15:50:09 +00:00
backup.sh refactor(scripts): Use #!/usr/bin/env as part of shebang 2023-05-19 00:45:38 +01:00
build.sh refactor(scripts): Use #!/usr/bin/env as part of shebang 2023-05-19 00:45:38 +01:00
clear.sh refactor(scripts): Use #!/usr/bin/env as part of shebang 2023-05-19 00:45:38 +01:00
convert.sh refactor(scripts): Use #!/usr/bin/env as part of shebang 2023-05-19 00:45:38 +01:00
docker-compose.yml compose: Use repository's container image for dev env 2023-06-20 17:51:25 +01:00
Dockerfile Update Dockerfile 2023-02-02 07:52:23 +11:00
download.sh refactor(scripts): Use #!/usr/bin/env as part of shebang 2023-05-19 00:45:38 +01:00
Makefile fix(makefile): Use shell-builtins in Makefile 2023-05-19 00:46:44 +01:00
notes.txt upstream 2022-12-27 10:27:11 +11:00
README.md Clarify README regarding open-source license 2023-06-26 16:37:14 +01:00
start_dev.sh Updated to docker compose 2023-06-16 21:49:24 +02:00
uart_log.sh refactor(scripts): Use #!/usr/bin/env as part of shebang 2023-05-19 00:45:38 +01:00

PineBuds SDK

This is just the SDK from the wiki (so far), with dockerfile setup to make building easier, and my reverse engineered bestool integrated. The docker image will build bestool for you first, then drop you into the dev container for building and flashing the buds.

NOTE: Currently, the SDK is not licensed under an 'open source' license. We are working to resolve this issue, and will be reaching out to contributors and other parties soon. For now, consider this SDK as 'All Rights Reserved'/'shared source'.

Usage

To use this setup to build & flash your PineBuds you will need a system with docker setup at the minimum. Docker is used to (1) make this all much more reprodicible and easier to debug and (2) so that we dont mess with your host system at all. In order to program the buds from inside of the docker container; privileged mode is used. So do be a tad more careful than usual.


./start_dev.sh # This will cause docker to start your working environment; this should take roughly 1-3 minutes depending on your network speed to the GCC hosting server

# Now you will be inside of the container, and your prompt will look akin to "root@ec5410d0a265:/usr/src#"

./build.sh # This will run make and build the output program. If you have weird build errors try running clean.sh or rm -rf'ing the out folder first

# Now that the firmware has finished building; if there are no errors you can load it to your buds

# You may want to back up the firmware currently on the buds - it will be deleted when the new firmware is loaded on:
./backup.sh

# You may need to take the buds out of the case, wait three seconds, place them back. This wakes them up and the programmer needs to catch this reboot.

# You can try the helper script by running
./download.sh

# Or do it manually by :

# Assuming that your serial ports are 0 and 1, run the following to commands to program each bud in series.
bestool write-image out/open_source/open_source.bin --port /dev/ttyACM0
bestool write-image out/open_source/open_source.bin --port /dev/ttyACM1

Changelist from stock open source SDK

  • Long hold (5 ish seconds) the button on the back when buds are in the case to force a device reboot (so it can be programmed)
  • Use the resistor in the buds to pick Left/Right rather than TWS master/slave pairing
  • Pressing the button on the back while in the case no longer triggers DFU mode
  • Debugging baud rate raised to 2000000 to match stock firmware
  • Fixed TWS operation such that putting either bud into the case correctly switches to the other bud
  • Working (mostly) audio controls using the touch button on the buds
  • Turned off showing up as a HID keyboard, as not sure why you would; but it stops android nagging me about a new keyboard

Current bud tap codes

Both pods active

Right Ear:

  • Single tap : Play/Pause
  • Double tap : Next track
  • Hold : Toggle ANC(Currently non functional, WIP)
  • Triple tap : Volume Up

Left Ear:

  • Single tap : Play/Pause
  • Double tap : Previous track
  • Hold : Toggle ANC(Currently non functional, WIP)
  • Triple tap : Volume Down

Single pod active

  • Single tap : Play/Pause
  • Double tap : Next track
  • Hold : Previous track
  • Triple tap : Volume Up
  • Quad tap : Volume Down

Changing audio alerts

The default audio alerts are stored in:

config/_default_cfg_src_/res/en/

If you want to change the alert to a custom sound, just replace the sound file you'd like to change (ie config/_default_cfg_src_/res/en/SOUND_POWER_ON.opus) with your own audio file with the same base name (ie config/_default_cfg_src_/res/en/SOUND_POWER_ON.mp3) and recompile with ./build.sh!

Language support

The AUDIO environment variable can be set when running the build.sh script to load sound files for languages other than the default English. For example, running AUDIO=cn ./build.sh will load sounds files from config/_default_cfg_src_/res/cn/ instead of the default en/ folder.

The current languages supported with sound files are English (en) and Chinese (cn). Other languages (or other sets of custom sounds) may be added by adding all the correct sound files into a config/_default_cfg_src_/res/<custom_sounds>/ directory and building with AUDIO=<custom_sounds> ./build.sh.

Blue light when connected

The firmware can be configured to either have a blinking blue light when connected or not. Build with CONNECTED_BLUE_LIGHT=1 ./build.sh to enable blinking when connected, or CONNECTED_BLUE_LIGHT=0 ./build.sh (or just the default ./build.sh) to keep the LEDs off when connected.