BeagleBone Black For DSP Application Project

Business Overview

BeagleBone Black For DSP Application

To modernize our technology to make it easier & cheaper to manufacture, to enable new features, and to protect against obsolescence. The current product is built using TMS320VC5510 on custom PCB. The TMS320VC5510 is popular, but the old product could become obsolete. The development system is a very old Code Composer which is unsupported and doesn’t like newer versions of Windows. The built-in memory is maxed out, preventing us from implementing a number of new features we have in mind. The CPU is also close to maxed out. The part is getting expensive, not only because of its price but because we need external AES receiver, AES transmitter, and external UART chips. A more modern processor may have these built-in. This is the reason to leapfrog to a modern device which will have much more MIPS and much more RAM (room to grow), built in I2S and UART peripherals, and doesn’t use more watts. It might also be attractive to have a dual processor & DSP to make it easier to add user application features without impacting the real-time code.

Existing Product

The board receives conversion samples from an A/D (over an AES3 interface) at 192,000 samples per second and performs some mathematical operations to generate ‘processed’ data. (The conversion rate of the A/D, 192,000 samples/sec., is either controlled by the A/D itself, or by an external conversion clock input.) The processed data is sent out via a serial port. The serial port is also used to communicate and control this board from the handheld PC. At the same time, The DSP also copies data from pre-loaded table to a parallel port to operate the transmitter. Only 2 or 4 bits need to be copied, but the rate is up to 1,536,000 transfers per second.The current firmware is based on TI’s proprietary RTOS for TI DSPs, TI-RTOS. This has evolved over many years and in the past has been known as DSP/BIOS, SYS/BIOS, TI-RTOS Kernel, etc.

Windows Handheld

WinGEM does the following:

  • Provides a graphical user interface.
  • Talks to the EMSYS2 board for configuration and control.
  • Receives and logs the “processed data” from the EMSYS2.
  • Provides a real-time display when the instrument is actively measuring.
  • Provides a facility for uploading data files when the instrument is NOT actively measuring.

Challenges

Device Selection

The device selection is based on (in rough order of priority):

  • Will the device operate from (-40°C to +70°C min)?
  • Will it be easier to port to a TI brand, or have things tools and architectures changed so much over the years that it doesn’t matter?
  • Is the device available for purchase now and in the future? We only use dozens or hundreds per year, so a part that can only be purchased in thousand quantities is not suitable for us?
  • Is there an affordable proven (simple?) RTOS that can be easily used with the chip? Is Linux usable?
  • Is there an affordable proven development environment that can be easily used with the chip.
  • Is there some kind of “demo” board we can get so that we can at least test the code we have posted, and some of the real-time operation before having to spin our first PCB?
Hardware Solution

Could be based on Linux and the Sitara processor as used in the BeagleBone Black. The Sitara processor includes:

  • ARM core with DSP 32-bit multiply-accumulated instructions
  • McASP hardware for receiving the A/D samples at 192 kHz
  • UART & parallel port hardware
  • optionally 2 completely separate PRU processors

The significance of the BeagleBone is that it would provide us with a software and hardware development platform right away at little cost. The concept is that the hard real-time (RT) functions would be carried out by the on-chip hardware, i.e. clocking in the A/D samples and clocking out the transmitter bits. These functions cannot tolerate jitter, so the clocking has to be done by hardware peripherals, not firmware/software. If the incoming data samples can be reliably buffered, then the math functions can be considered “soft” real-time and might conceivably be carried out within Linux.

The challenge is to run the hardware peripherals within Linux and guarantee that there can never be latencies that would mess up the processing of data. Ultimately, all of the user interface (i.e. WinGEM) could then be ported to run on the same Linux system, solution effectively eliminating the need for the Windows Handheld computer.

Technologies Used
  • Beaglebone Black Revision C ARM Cortex A8
  • Audio cape AK5385
  • Saleae Logic Analyzer

Solution

Target Configuration of the McASP versus Demo

This section explains what we expect the final configuration of the McASP will be in the final product. We don’t have to implement it this way from the start, but we should not go down any paths that are incompatible unless we redefine the final configuration.

McASP0 Vs McASP1

McASP1 is not as easily available on most boards because of the limited number of pins. So our goal is to use McASP0 transmitter (X) for transmitting and McASP0 receiver (R) for receiving. Part 1 of the study is only concerned with transmitting, but we will describe the clocking for both.

Clocking Scheme

Configuration

A 12.288 MHz clock enters ACLKR (regular Receive clock) and AHCLKX (‘High speed’ Transmit clock). The receiver will use the 12.288 MHz clock directly, but the AHCLKX will be divided down by 8 to provide a 1.536 MHz clock for the transmitter. (Contrary to previous thinking, we will not need to run the transmitter faster than this.)

For the demo, there are 2 possible clock sources. In the default configuration, the Beaglebone puts out a 24.576 MHz clock on P9 pin 25. This is exactly twice the eventual 12.288 MHz. This can be fed into AHCLKX pin to be divided down, OR

The audio cape provides a 12.288 MHz data clock (In the early stages of step 1 you could also start with an internal clock before trying to use an external clock).

Input/Output Pins

The I/O pins available to McASP0 are AXR0, AXR1, AXR2, and AXR3. The ‘XR’ indicates that a pin can be assigned to either the transmitter (X) or receiver (R).

Final Configuration

AXR0 is assigned to the receiver. AXR1 and AXR2 are transmitter outputs. AXR1 is available by default, AXR2 is made available by resetting the McASP0_AHCLKR pin(BGA ball C12) into I/O mode 2 to change it to being McASP0_AXR2.

At the divided-down clock rate, 1.536 MHz or less, the transmitter will put out 2 bits on the pins.

A file of 2-bit patterns will be stored in memory and clocked out on the 2 pins. The protocol analyzer can capture the sequence of bits for comparison with the source file.

(In the early stages of step 1 you might want to start with 1-bit output on pin AXR1, before tackling the reassignment of the McASP0_AHCLKR pin to McASP0_AXR2.)

Use of DMA

The transmitter and receiver must be performed with DMA. We require that they both operate in lock-step with the external clock, so no software loop, no matter how fast, can eliminate jitter.

Share