DSP Effects Rack Application

[digitaldanny]

• Read and decode data received from glove device over Bluetooth.
• Get original PitcherThis project up and running again.
• Modify PitcherThis project so that the tunable parameters are controlled by the received glove data.

[digitaldanny]

I am seeing a weird issue with the uart baud rate while running the demo/hc05.c code on my laptop. The BAUDRATE_9600 (9600 << 1) define from hc05.h results in a baud rate of 38.4k even though it results in 9.6k when loading the same code from my desktop. I am wondering if this is due to a difference in the driverlib 2 and driverlib 3 versions between my desktop and laptop.

I have a workaround to get it working on my laptop. Although I would prefer to find the root cause of the issue, I know I need to run the code from my laptop anyways since the DSP final project isn't running on my desktop. Below are the changes I made.

// Running project on laptop uses a different driverlib version
// that divides the clocks differently.
#define DRIVERLIB_2

#ifdef DRIVERLIB_2
 #define BAUDRATE_38400      (38400>>1)
 #define BAUDRATE_9600       (9600>>1)
#else
 #define BAUDRATE_38400      (38400<<1)
 #define BAUDRATE_9600       (9600<<1)
#endif // DRIVERLIB_2
#define BAUDRATE_DEFAULT    BAUDRATE_9600

[digitaldanny]

Adding a timeout counter so that the glove software can go back to a valid state if the DSP program restarts without powering off the slave HC-05. I was able to determine it takes about 10-15 main loop iterations from the SendUpdateToSlave function to the CheckForAck function returning true. I am going to make the timeout counter 500 iterations which is 50x the expected number of iterations for a response.

[digitaldanny]

The sizeof(dataPacket_t) results are different between the MSP432 (8) and the C2000 (6) due to varying word sizes. As a quick workaround, I created a define to be used on the C2000 side for reading the appropriate number of bytes.

#define DPP_PACKET_SIZE_IN_BYTES_C2000    (8) // 1=opCode, 3=flexSensors, 2=pitch, 2=roll

This workaround also requires manually decoding the receive buffer's data as shown below.

//memcpy((void*)&gloveSensorDataLocal, (void*)gloveDataBuf, sizeof(dataPacket_t));
gloveSensorDataLocal.opCode = gloveDataBuf[0];
gloveSensorDataLocal.flexSensors[0] = gloveDataBuf[1];
gloveSensorDataLocal.flexSensors[1] = gloveDataBuf[2];
gloveSensorDataLocal.flexSensors[2] = gloveDataBuf[3];
gloveSensorDataLocal.pitch = (short)((gloveDataBuf[5] << 8) | gloveDataBuf[4]);
gloveSensorDataLocal.roll = (short)((gloveDataBuf[7] << 8) | gloveDataBuf[6]);

The neater solution would be to pack or pad the dataPacket_t struct in a way that the sizeof results are the same between both processors. This way, I would be able to do a memcpy from the receive buffer to the C2000's dataPacket_t gloveSensorDataLocal variable. This would automatically typecast the bytes into the dataPacket_t fields.

[digitaldanny]

Currently working on the DSP side code to have the sensor data control the effects rack.

Glove Sensor	DSP Effect
Thumb	Toggle effects on/off
Pointer	Change volume
Middle	High-pass filter cutoff frequency
Pitch	Pitch
Roll	Low-pass filter cutoff frequency

[digitaldanny]

All the effects are working correctly right now. I am currently trying to figure out why the music gets so loud and noisy with the effects enabled. This was not happening even with all the effects being processed previously, but I have not root caused the problem yet.

[digitaldanny]

Root cause checks

• LCD_SendBytes: Commented the guts of this function out to avoid I2C transfers. Thought this might be the problem since I2C starting hanging last night.
• isFxEnabled: Commented out toggle and hardcoded value to true. No change.
• FFT/FX/IFFT: Commented out the FX processing to see if this was taking too long before next DMA transfer out. Output is more quiet but still stutters.
• Unloading/reloading fftBuffer: Sound is clean. I am not sure how this could be the problem since this code has been in the project since day 1. Going to continue looking into this.

[digitaldanny]

I added the below code to the DMA interrupt and added a breakpoint to the dma_flag++ line to see if the DMA transfer was ever triggered before processing was complete. The breakpoint hit quickly, which I think shows that the main loop is taking too long to handle the frame processing.

__interrupt void DMA_FRAME_COMPLETE_ISR(void)
{
    if (dma_flag == 1)
    {
        dma_flag++;
    }

When I connect the timer pins from the C2000 to my LSA, it looks like the opposite is happening. It seems like the frame is processed with plenty of time remaining before the next DMA transfer. In the screenshot below, the frame is processed in the time marked in red while it actually has up to the time marked in blue.

[digitaldanny]

Looking for the commit where the music with FX enabled stops working. Will do a git diff on these two commits to see differences in the demo/main.c file.

Last working commit with FX enabled: 53d74f2 First failing commit with FX enabled: 2eb0ce4

git diff 53d74f2 2eb0ce4 demo/src/main.c

[digitaldanny]

Found the issue. Looks like the sprintf function takes more than 1 frame's worth of processing time to complete. If I add the LCD code into the toggle GPIO, I can see the time to complete is too long.

[digitaldanny]

Everything is good to go now on the demo side. Will still need to do some tweaking on the flex sensor readings with the new flex sensors, but this can be pushed directly to master.