RobertWoodruff

Hi Bob,
 
Your app looks doable to me, though not trivial. The hardware connections and interfaces are straight forward to make work for your prototype.  Of course, moving the h

Hi Bob,
 
I use CSS with the Energia libraries (CSS now has explicit support for Energia). It is a reasonable choice, you can

My recommendation is to use the Energia Setup()/Loop() construct, And use CCS as the IDE rather than the Energia IDE. CCS is Eclipse and so the its debugger can be used.. Without the debugger progress will be tough.
 
LPM3 is encapsulated in Energia by the sleep() methods so you make sleep() calls rather than LP3 directly.
 
I have  the MCU to respond to traffic on the UART RX channel while in LPM3 by processing the requests during the RX ISR wakeup.
 
Thank you,

My recommendation is to use the Energia Setup()/Loop() construct, And use CCS as the IDE rather than the Energia IDE. CCS is Eclipse and so the its debugger can be used.. Without the debugger progress will be tough.
 
LPM3 is encapsulated in Energia by the sleep() methods so you make sleep() calls rather than LP3 directly.
 
I have  the MCU to respond to traffic on the UART RX channel while in LPM3 by processing the requests during the RX ISR wakeup.
 
Thank you,

Hi Roboticus,
 
You are correct,  the parameter values to AT+CLASS= are hex numbers. There is a overview in the Bluetooth spec about formatting and interpreting the 32 bit class value (CoD). I am not going to learn all that now but have learned enough to carry forward with this application.
 
Here is a translation between what is sent to the AT command and what is seen on the Android side
 
/* Android Java code segment */
BluetoothClass bluetoothClass = btDevice.getBluetoothClass();
int deviceClass = bluetoothClass.getDeviceClass();
int majorDeviceclass = bluetoothClass.getMajorDeviceClass();
 
Apparently the default in the HC-05 is that lowest two bits of whatever hex value is sent to AT+CLASS= are set to 0 by the time it can be picked up on the Android side by deviceClass = bluetoothClass.getDeviceClass(); The majorDeviceclass is coming in at 0x100.
 
Here are a few test cases I tried
 
AT value(hex, binary)                deviceClass          majorDeviceClass  
128, 0001 0010 1000      0x128          0x100
129, 0001 0010 1001      0x128          0x100
12A, 0001 0010 1010      0x128          0x100
12B, 0001 0010 1011      0x128          0x100
12C, 0001 0010 1100      0x12C          0x100
12D, 0001 0010 1101      0x12C          0x100
 
There are also web sites where you can enter the characteristics of your BT device and it will generate a CoD (class of device) hex number for you.
 
Hope this info is useful to someone out there.
 
Thank you,

Hi Roboticus,
 
You are correct,  the parameter values to AT+CLASS= are hex numbers. There is a overview in the Bluetooth spec about formatting and interpreting the 32 bit class value (CoD). I am not going to learn all that now but have learned enough to carry forward with this application.
 
Here is a translation between what is sent to the AT command and what is seen on the Android side
 
/* Android Java code segment */
BluetoothClass bluetoothClass = btDevice.getBluetoothClass();
int deviceClass = bluetoothClass.getDeviceClass();
int majorDeviceclass = bluetoothClass.getMajorDeviceClass();
 
Apparently the default in the HC-05 is that lowest two bits of whatever hex value is sent to AT+CLASS= are set to 0 by the time it can be picked up on the Android side by deviceClass = bluetoothClass.getDeviceClass(); The majorDeviceclass is coming in at 0x100.
 
Here are a few test cases I tried
 
AT value(hex, binary)                deviceClass          majorDeviceClass  
128, 0001 0010 1000      0x128          0x100
129, 0001 0010 1001      0x128          0x100
12A, 0001 0010 1010      0x128          0x100
12B, 0001 0010 1011      0x128          0x100
12C, 0001 0010 1100      0x12C          0x100
12D, 0001 0010 1101      0x12C          0x100
 
There are also web sites where you can enter the characteristics of your BT device and it will generate a CoD (class of device) hex number for you.
 
Hope this info is useful to someone out there.
 
Thank you,

Believe I have this figured out.
 
It is the CSS debugger that interferes with the ISR routines. When the debugger is sitting at a breakpoint it keeps the ISRs from firing as expected which has the effect of causing input to the UART RX channel to appear to fall in the bit bucket. Not unexpected really by virtue of the way the debugger works.
 
The delay() call gave the IRS routines time to absorb all the responses before the debugger break point was reached. That is good news really, Because now we know that UART input continues to be accepted even when a delay() call is active.
 
So be careful when attempting to use debugger break points about the time the UART ISR routines might be firing. They will be disabled and input will get lost.
 
Otherwise the input from the HC-05 is coming in as expected on the UART RX channel.
 
Very cool!