Texas instruments offers source code for a Bluetooth stack (Serial Port Profile) that was written by Mindtree. It runs on an MSP430 microprocessor and interfaces with their baseband controller chip (i.e. the RF chip). This uses the FreeRTOS operating system. This software comes in the form of several demos; the one I used is called the accelerometer demo. This chipset is part of custom handheld hardware I am developing. I am running the GA1.0 release (modified accelerometer demo to work on the custom hardware). I'm trying to simply trying to pass data between Bluetooth SPP and a UART running at 78K. I have SNIFF mode disabled and am disabling RTS in the UART interrupt. No processing is done in the Interrupt, other than a write to a buffer and a semaphore take. I have a low priority task that handles buffering.
All I need the chip to do is provide a link between the Bluetooth and a UART running at 76K (this UART connects with our DSP processor). Currently, the DSP is the brains of the hardware and communicates with a PC GUI via USB. I want to take the DSP UART and forward it over Bluetooth instead without the DSP knowing or caring what its UART is connected to.
As constructed right now, the software connects via bluetooth correctly and I've verified transmitting and receiving data. At low rates, this works great. Since the DSP is always transmitting a status message out its UART, I can connect a PC with a bluetooth dongle to the hardware, and use Putty (serial port terminal) to watch this status message coming across correctly. However, once I try to connect with our PC GUI, the resulting RX traffic on the bluetooth is such that the software can no longer service the DSP UART interrupts in a timely manner. With no Bluetooth RX, I'm getting over 100 UART interrupts before my task is able to process the data, even with the task's priority set to highest. I imagine it's a great magnitude more once RX data starts coming in, which currently crashes us. Unfortunately, this MSP430 processor does not offer DMA for the UART we are using, and does not offer hardware buffering.
My attempts at fixing this have always lead to one of three outcomes: my UART interrupt overflowing, the BT UART interrupt overflowing, or my UART buffer overflowing when the Stack can't manage to send the data in time. The developer guide says that at 18 MHz and 115K, the average data throughput is 84K, and the average CPU utilization is 10.7% yet the software can't keep up with a 78K UART.
It's my fear at this point that the Bluetooth UART interrupt (part of Mindtree's stack) is hogging too much CPU to allow the handling of any other interrupts at the rate we want.
Has anyone had any success integrating the TI/MindTree Bluetooth stack? If so did you run into these same issues? I'm basically loooking for any and all suggestions on how to overcome these issues.
