CSR, even before it was acquired by Qaulcomm, is a giant in wireless audio for consumer electronics, providing a significant share of the Bluetooth enabled chips that power earphones, headphones and other audio devices. These come in two variants – ROM chips and flash chips. The ROM chips are furnished with a FW that cannot be changed, but it can be configured to a large amount in terms of external HW components, the exact features that are enabled and the user interface of the headphones (from buttons and their actions, to voice overs and sound effects). The flash chips, on the other hand, provide a fully programmable environment that allow to develop any sort of FW that is required for a product.
The CSR8670 (and its more expensive and powerful brother, the CSR8675, which shares the same architecture, code base and development tools) has a main MCU running a proprietary CSR embedded environment with code written in C (called the VM), and a DSP co-processor that is optimized for audio signal processing and is written in a proprietary language called Kalimba, which is similar to most assembly languages in syntax, but with some higher level instructions and a large pre-built library for common audio related tasks.
Audio is handled by 16 bit ADCs and DACs, as well as via I2S or PCM digital interfaces. Other HW components on this SoC include input and output amplification, Bluetooth 4 radio (using an external antenna), 3 LED controller, USB interface, SPI to an external flash memory, I2C interface, GPIOs. Overall, it really is a System on Chip for all your wireless and wired audio needs.
Overall the CSR8670 looks like the perfect SoC for anybody interested in doing advanced functionality with audio, both wired and wireless. However, CSR is known in the industry as a tight lipped company, with poor technical support and meager documentation. The acquisition by Qualcomm did little to improve this. For the embedded FW engineer trying to implement the product requirements, this is a major stumbling block. This is aggravated by a lack of external resources online on this platform, that although it is used by countless companies in their audio products, there is almost no blogs, forums or articles about how to work with this chip (aside from a few Chinese blogs and a Chinese forum that looks like it is dedicated to CSR’s products).
Initially this might be considered an irrelevant issue – one assumes that once a formal company (and not just a curious individual) approaches CSR/Qualcomm with an intent of purchasing large quantities of chips then the hidden documentations will emerge and technical know-how will flow. Sadly this can’t be farther from the truth. It is even whispered that CSR won’t consider a customer until his orders are in the millions of chips. You can still buy the chips, but don’t expect any level of real support. Yes, there is a technical support site (with mostly higher-level documents, with many crucial technical points completely missing or a decade out of date); yes, there is a technical support email (which almost never replies to the emails sent to it, or simply directs you to the local sales representative company of CSR in your area); and yes, there are some code examples (a few being utterly trivial, and a few being monstrously complex, with nothing in the middle). All of this leads to a technical nightmare for the engineer that has real and serious implications on the time-to-market.
After contacting CSR, buying an evaluation board and purchasing a support contract you will have the CSR IDE – the Audio Development Kit (or ADK). This is a rather old-style IDE, with no intelli-sense and little in the way of advanced debug capabilities. It does allow the user to watch variables (both in the C code and in the DSP), set breakpoints (only while stopped) and view the registers (more interesting for the DSP). It might be more convenient to write the code in a third-party IDE (such as IntelliJ, Eclipse or VIM/Emacs) and use the ADK just for setting configuration, compiling and running the code.
In addition to being an IDE, the ADK installation also includes all the libraries CSR provides to write FW on the CSR8670. These include both C code libraries and Kalimba code libraries for the DSP. Most of the libraries actually include the source code (applies for a large part of the C libraries as well as of the Kalimba libraries) and are compiled during the installation of the ADK (and can be recompiled if needed). Other parts of the libraries are closed-source and only the header files are included.
When starting to write you FW, there broadly are two approaches:
- Write your FW from scratch – in this approach you start with a blank workspace and write both the VM code and the DSP code. One can use the examples
my_second_dsp_appto get started, but most of the code will be written afresh. This will require figuring out which APIs to use to do various operations on the FW and the HW peripherals and how to tie everything together to build the product you want.
- Use the provided Sink code – in this approach you start with the full-blown Sink application that is provided by CSR as the starting place for your project. The Sink application provides full functionality of an audio sink (meaning the side receiving the audio and actually playing it through speakers, as opposed to the source which pushes the audio to the sink (typically a mobile phone or PC)), with support for Bluetooth, wired connections, BLE, void prompts, buttons, LED stats, user events and much more.
It may seem that both approaches have their merits, but it is important to note that CSR’s Bluetooth stack is horribly undocumented and requires a lot of user glue-logic to work correctly with the open-sourced as well as the closed-sourced API libraries. Simply trying to begin Bluetooth advertising requires a complex flow of initialization and message handling which is not explained in any support document (other than a few misleading documents that refer to much older versions of the ADK or even to other CSR products that provide Bluetooth). It is possible to work with the Bluetooth library like that, but it requires a lot of reverse-engineering and trial-and-error and will typically leave the FW unable to easily add new features to the Bluetooth (such as supporting A2DP, HFP and AVRCP at the same time). On the other hand, the Sink application has a huge code-base, with every feasible feature implemented and controllable through run-time configurations (and some compile-time configuration as well). This means that even though the Sink code provides you with full Bluetooth functionality, it also adds a lot of other features and it is very difficult to add custom code (be it a unique user experience or advanced audio processing). The best rule-of-thumb is write code from scratch when Bluetooth is not required (typically when the audio handling is wired, either through the ADC or through the I2S) and only use the Sink application when Bluetooth is a requirement.
In the next posts we will dive into the nitty-gritty aspects of writing a FW for the CSR8670.