This is an old revision of the document!
Helpful video: The Structure of the Bare Metal Framework
There are three distinct Project folders which each correspond to the code running on a distinct processor core of the ADSP-SC589. Furthermore, there are some folders which contain code that is shared between the three cores.
sam_baremetal_framework_core0- Code for ARM code
sam_baremetal_framework_core1- Code for SHARC Core 1
sam_baremetal_framework_core2- Code for SHARC Core 2
drivers- bare metal drivers for internal peripherals and external devices (e.g. ADCs, DACs, etc.)
common- files that are included in the three projects (ARM, SHARC Core 1, and SHARC Core 2). These files include a shared memory structure and project configuration.
The ARM core is responsible for the following:
Once the ARM core has initialized the various components of the system, it strobes
LED10 on the SHARC Audio Module board once per second. This serves as a visual indication that all of the initialization code completed successfully on the ARM core.
SHARC Core 1 is responsible for the following:
The framework can be configured for single-core processing or dual-core processing.
When the framework is configured for single-core processing, the processing flow works as such:
SHARC Core 1 →
And when the framework is configure for dual-core processing, SHARC Core 1 still manages the flow of audio data to and from the ADCs and DACs.
SHARC Core 1 [processing] →
SHARC Core 2 [processing] →
SHARC Core 1 [final data transfer] →
SHARC Core 2 is only responsible for processing audio.
All three projects have a few key folders:
audio_frameworks/- this folder contains a number of .c/.h file pairs that are used to configure and operate specific audio processing configurations. These essentially manage the audio plumbing and abstract away the underlying DMAs, interrupts, etc. Based on the overall project configuration (described in the next section), .c files are enabled through pre-processor variables. This allows us to have a common set of calling conventions (while sticking with C) and swap out modular frameworks without changing our audio processing.
drivers/- Device drivers used to initialize and control on-chip peripherals and external CODECs / ADCs / DACs, etc.
common/- files that are shared between all three cores
faust/- if you have generated source files using the Faust synthesis tool, place these files here
Each core also has one or more callbacks which is where your custom audio processing (or MIDI processing) resides. These callbacks have been architected such that all of the underlying mechanics of the audio movement and event generation have been abstracted so they are hardware platform agnostic.
Callback_Audio_Processing.cpp- add your C or C++ audio processing functions to this file
Callback_MIDI_Message.cpp- add any MIDI processing functions to this file
Callback_Pushbuttons.cpp- add any code to respond to push button events to this file