The bare metal framework includes a set of lightweight device drivers called “bm” that rely on a similar call convention as Arduino. These drivers interface directly with the various peripheral control registers on the chip and again are designed to be easy to use, understand and modify.
These drivers can be found in the
drivers folder that is present on the ARM core and SHARC core 1. These drivers have been written to work on all cores so the same UART driver works on both the ARM core and the SHARC cores. Thus it becomes easy to have different cores communicate directly with various peripherals.
A number of different “bm drivers” are provided. They fall into three categories:
Below is a brief description of the functionality provided by each driver and more documentation is provided within these source files.
bm_sysctrl_driver - this is a general system control driver that does three things: it configures the clocks on the processor; it generates a 1ms tick to allow it to support some Arduino-style functions like delay() and millis(); it manages the housekeeping (general purpose) ADC which is read during the 1ms tick interrupt.
bm_gpio_driver - provides very easy to use GPIO support for reading and writing GPIO as well as setting up interrupts on GPIO pins. The corresponding header file contains a number of #defines for commonly used GPIO inputs and outputs. Here are a few examples of how it can be used:
// Set `LED10` on the SHARC Audio Module board as an output gpio_setup(GPIO_SHARC_SAM_LED10, GPIO_OUTPUT); // Set the GPIO connected to PB1 (button) on the SHARC Audio Module board as an input gpio_setup(GPIO_SHARC_SAM_PB1, GPIO_INPUT); // Attach an interrupt callback when the pushbutton is pressed gpio_attachInterrupt(GPIO_SHARC_SAM_PB1, my_callback, GPIO_FALLING, 0);
bm_spi_driver - a SPI driver for communicating with SPI peripherals
bm_twi_driver - an I2C/TWI driver for communicating with I2C/TWI peripherals
bm_uart_driver - a UART driver for communicating with UART and MIDI peripherals
bm_sru_driver - the ADSP-SC589 is equipped with a powerful signal routing unit (SRU) that can be used to route I2S and other signals to various pins of the chip and to various internal peripherals. This driver configures the SRU for several standard configurations. Think of these really as SRU presets that enable various functionality and connectivity.
bm_adau_driver - this is a generic driver for ADI’s audio converters (ADCs, DACs and codecs). The SigmaStudio tool can be used to graphically configure audio codecs and this tool is also capable of generating a corresponding C header file with a sequence of initialization / control register writes (and reads). Rather than implementing a large number of functions specific to one device, this driver accepts and initialization file generated by SigmaStudio to initialize a device. It also provides control register mapping for a number of devices and a set of functions to read/write device control registers and parameter memory (in the case when the device has a SigmaDSP core). Thus, we’re able to use a single driver to initialize both an ADAU1761, ADAU1966 and ADAU1979. This driver does contain a few device specific functions as well when a bit more logic is needed to properly initialize a part.
bm_a2b_driver - this is a generic driver for the A2B controller on the SHARC Audio Module board. This does not include a full A2B stack but rather it can be used to initialize and control and A2B network using an initialization file generated by SigmaStudio. In addition to being able to configure converters, SigmaStudio can also be used to design A2B network topologies with various nodes and connected devices. SigmaStudio can export a .h file with an initialization sequence needed to initialize such a network. There is a callback in this driver when an I2C device needs to be initialized on a remote slave node. The “bm_adau_driver” can then be called to initialize this I2C device on a slave node just like it can a local device. The only difference is that the driver is pointing to a different I2C address (for a local device, the I2C address would be that of the device; for a device on an A2B slave node, we write to an I2C address associated with the A2B controller - everything else is identical).
The 8 channel audio framework makes use of the bm A2B driver and provide a good example of how easy it is to load an “topology” that SigmaStudio generated, and then run “bm_adau_driver” to the callback to initialize the various ADCs and DACs on the slave nodes.