admin
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 a 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 an 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 that 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 & BeagleBone Black for DSP to make it easier to add user application features without impacting the real-time code.
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 the 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.
Winnie does the following:
The device selection is based on (in rough order of priority):
Could be based on Linux and the Sitara processor as used in the BeagleBone Black. The Sitara processor includes:
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 interfaces (i.e. WinGEM) could then be ported to run on the same Linux system, a solution effectively eliminating the need for the Windows Handheld computer.
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 many paths that are incompatible unless we redefine the final configuration.
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.
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).
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).
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.)
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.
Faststream helped one of the clients to design a next-generation vending machine solution using IoT and AI that supports functions such as predictive maintenance, customer-centric loyalty programs, and cashless transactions, and BeagleBone Black For DSP Application Project, feel free and contact us for more details: Email: [email protected]
