chicken

Philips Hue Tap, a wireless light switch without battery, featuring a MSP430FR5730

 
Teardown by Adafruit, with the MSP430 discovered at the 15 minute mark.
https://youtu.be/4T4nhuobjZM?t=875
 
This device doesn't have a battery, but uses a mechanical, relais-like component to generate power when the user pushes buttons.
https://www.enocean.com/en/enocean_modules/eco-200/

With the delay, all the characters of the response were received by the MCU and waiting in a buffer before you read it.
 
Serial communication is not instantaneous. At 9600 baud, the 4 characters will take about 4ms to be transmitted. Add to that the time it takes to actually send the command and the time for the Bluetooth module to process your command and you quickly get to a few 100ms.
 
You should check for the end of line to ensure you received the complete response.

Philips Hue Tap, a wireless light switch without battery, featuring a MSP430FR5730

 
Teardown by Adafruit, with the MSP430 discovered at the 15 minute mark.
https://youtu.be/4T4nhuobjZM?t=875
 
This device doesn't have a battery, but uses a mechanical, relais-like component to generate power when the user pushes buttons.
https://www.enocean.com/en/enocean_modules/eco-200/

Philips Hue Tap, a wireless light switch without battery, featuring a MSP430FR5730

 
Teardown by Adafruit, with the MSP430 discovered at the 15 minute mark.
https://youtu.be/4T4nhuobjZM?t=875
 
This device doesn't have a battery, but uses a mechanical, relais-like component to generate power when the user pushes buttons.
https://www.enocean.com/en/enocean_modules/eco-200/

Philips Hue Tap, a wireless light switch without battery, featuring a MSP430FR5730

 
Teardown by Adafruit, with the MSP430 discovered at the 15 minute mark.
https://youtu.be/4T4nhuobjZM?t=875
 
This device doesn't have a battery, but uses a mechanical, relais-like component to generate power when the user pushes buttons.
https://www.enocean.com/en/enocean_modules/eco-200/

Philips Hue Tap, a wireless light switch without battery, featuring a MSP430FR5730

 
Teardown by Adafruit, with the MSP430 discovered at the 15 minute mark.
https://youtu.be/4T4nhuobjZM?t=875
 
This device doesn't have a battery, but uses a mechanical, relais-like component to generate power when the user pushes buttons.
https://www.enocean.com/en/enocean_modules/eco-200/

Hard to tell without seeing all the code code, the one above is missing where you read the buffer.
 
A few potential issues:
- the buffer offset variable should be declared as volatile if you use it inside and outside of the ISR.
- Serial.available() will return false for a while between characters.

With the delay, all the characters of the response were received by the MCU and waiting in a buffer before you read it.
 
Serial communication is not instantaneous. At 9600 baud, the 4 characters will take about 4ms to be transmitted. Add to that the time it takes to actually send the command and the time for the Bluetooth module to process your command and you quickly get to a few 100ms.
 
You should check for the end of line to ensure you received the complete response.

Most likely for schadenfreude purposes, as illustrated here :-D

From my notes, the USB peripheral on the F55xx only works down to LPM0. sleepSeconds() goes all the way down to LPM3, i.e. disables the USB peripheral.

Saw this on DP and checked out the author's blog. Neat way of producing a inexpensive, small form factor wireless data acquisition node. Two AA cells and the board all in a cheap three cell AA enclosure. Would be cool to see this adapted to a TI MCU.
 
http://johan.kanflo.com/the-aaduino/

@@ak96 Nothing wrong with preferring bare metal, my preference as well
 
Take a look at the innards of the counter library, even if you don't plan to use Energia. It basically sets up a timer to count up when a pin changes from 0 to 1. Using the timer, you don't need an interrupt for the counting itself.
 
The source code of the library may look a bit cryptic, because it tries to accommodate many different MSP430s. The gist is:
 
1. Set GPIO pin as input and select it's function (PxSEL) as timer input. The timer input (TxxCLK) is only available on a few pins, consult your MCUs datasheet.
2. Configure timer for external clock and continuous mode
3. Functions to start, stop and reset the timer as well as reading out the current timer value.
 
Run the timer for a known time, and the number of pulses will allow to determine the rate.
 
That being said, not sure if that's the best approach for a heart rate monitor. Measuring the time between pulses might be more sensible:
 
1. Start the timer, driven by one of the MSP's internal clocks. Use a divider to avoid overflowing the 16bit timer for the expected heart rate.
2. Wait for a pulse on a pin. A busy loop reading the pin is probably good enough for a beginner project.
3. When a pulse arrives, read the timer value.
4. Calculate the rate using clock frequency, timer divider and measured timer value.
 
I don't know what output signal heart rate monitors provide. If it's an analog wave form, you may need some circuitry to convert it to something that is usable for digital inputs and/or use the built-in comparator or ADC peripherals. 

PS: If you're new to programming, take a look at Energia.
 
There's a library for Energia, that makes it easy to count pulses with the MSP430.
http://forum.43oh.com/topic/8870-energia-library-hardware-counter-library-for-msp430/

The code in main.txt sets up interrupts that are triggered when pins change from high to low (falling edge). A counter J is increased by some of these interrupts.
 
That being said, the code has quite a few issues. If this is not your code, I would look for a better example as this one will cause a lot of grief to get working. If it is your code, I suggest to first think about the structure of the program before reattempting the implementation.
 
A few issues:
- the variable j used by the interrupt routine to keep track of the pulses should be declared as volatile.
- the setup of interrupts that configure interrupts is very convoluted and without further documentation, it will be hard to figure out how they interact and how the program is supposed to work
- there are several interrupt routines that include printing out of date, this is bad practice and almost certainly will create issues.

Sorry, carefully reading your question might help me to actually answer it
 
Looking at the datasheet of the MMA8653, I think the relevant chapters are 6.7 (freefall / motion detect registers) and 6.9.3 through 6.9.5 (CTRL_REG3-5, interrupt configuration registers).
 
In the linked Arduino code, ctrl_reg3-5 are already available. Add values for the motion detect registers.
int ff_mt_cfg = 0x15;  // Freefall/motion configuration register int ff_mt_src = 0x16;  // Freefall/motion source register int ff_mt_ths = 0x17;  // Freefall/motion threshold register int ff_mt_count = 0x18;  // Freefall/motion debounce register (Personally I'd use #define reg_name reg_address for this, but I will stick with the style of the Arduino code linked above)
 
You can use the I2C_SEND function in the Arduino code to set the registers to the desired values. I'd expand on the example's ACC_INIT function.
 
1. Set the desired detection mode with the bits in FF_MT_CFG.
Set bit 6 to 1 (OAE, detect mode, 0 = freefall, 1 = motion). Motion means, any axis measures above the threshold
Set bits 3, 4, 5 to 1 for the axis you want to detect on (XEFE, YEFE, ZEFE, representing x, y, z respectively).
Leave the other bits at 0.
0x78 looks like a reasonable value. You may need to exclude the axis of gravity when trying to detect motion < 1g.
 
2. Set the desired threshold at which motion is detected in FF_MT_THS
Set this register to a value between 0 and 127, representing 0 to 8g.
The register also has a flag (bit 7, DBCNTM) that determines how debouncing works. I think leaving it at 0 is fine.
0x20 would set about 2g as trigger level, be careful with values < 1g to avoid detecting gravity as motion.
 
3. Set how many samples are needed to trigger the motion detection in FF_MT_COUNT
Set this register to a value between 0 and 255. The duration depends on the update rate (ODR), which the Arduino example set to 800Hz. So each sample represents a 1/800th of a second. I'd experiment with values around 10 and lower it when reaction is too sluggish or increase it if detection is triggered randomly.
0x0a represents a debounce counter value of 10.
 
4. Optional: Set the interrupt pin we want to wiggle in CTRL_REG5
Bit 2 controls the interrupt pin for motion detection, either INT1 (1) or INT2 (0).
Default is INT2, so we only need to write to this register if we want to use the INT1 pin.
 
5. Optional: Set how the pin wiggles CTRL_REG3
Bit 1 (IPOL) selects, whether the pin goes high to low or low to high when an interrupt occurs. Default is going from high to low.
You will also need to look into this register if you use the sleep modes of the accelerometer.
0x01 will make the interrupt pin go high when motion is detected
 
6. Enable interrupt from motion detection in CTRL_REG4
Bit 2 enables the freefall/motion interrupt.
0x02 will enable the interrupt.
 
So in summary:
I2C_SEND(ff_mt_cfg, 0x78); // motion detection, x, y, z I2C_SEND(ff_mt_ths, 0x20); // 2g I2C_SEND(ff_mt_count, 0x0a); // debounce over 10 readings I2C_SEND(ctrl_reg4, 0x02); // enable motion interrupt (default is INT2 pin) When you connect INT2 pin of the accelerometer to the MSP430, you can then use DigitalRead or AttachInterrupt to react to the signal.
 
All the above is just theoretical as I don't have this chip at hand. But I obviously had too much time at hand

@@ak96 Nothing wrong with preferring bare metal, my preference as well
 
Take a look at the innards of the counter library, even if you don't plan to use Energia. It basically sets up a timer to count up when a pin changes from 0 to 1. Using the timer, you don't need an interrupt for the counting itself.
 
The source code of the library may look a bit cryptic, because it tries to accommodate many different MSP430s. The gist is:
 
1. Set GPIO pin as input and select it's function (PxSEL) as timer input. The timer input (TxxCLK) is only available on a few pins, consult your MCUs datasheet.
2. Configure timer for external clock and continuous mode
3. Functions to start, stop and reset the timer as well as reading out the current timer value.
 
Run the timer for a known time, and the number of pulses will allow to determine the rate.
 
That being said, not sure if that's the best approach for a heart rate monitor. Measuring the time between pulses might be more sensible:
 
1. Start the timer, driven by one of the MSP's internal clocks. Use a divider to avoid overflowing the 16bit timer for the expected heart rate.
2. Wait for a pulse on a pin. A busy loop reading the pin is probably good enough for a beginner project.
3. When a pulse arrives, read the timer value.
4. Calculate the rate using clock frequency, timer divider and measured timer value.
 
I don't know what output signal heart rate monitors provide. If it's an analog wave form, you may need some circuitry to convert it to something that is usable for digital inputs and/or use the built-in comparator or ADC peripherals. 

The code in main.txt sets up interrupts that are triggered when pins change from high to low (falling edge). A counter J is increased by some of these interrupts.
 
That being said, the code has quite a few issues. If this is not your code, I would look for a better example as this one will cause a lot of grief to get working. If it is your code, I suggest to first think about the structure of the program before reattempting the implementation.
 
A few issues:
- the variable j used by the interrupt routine to keep track of the pulses should be declared as volatile.
- the setup of interrupts that configure interrupts is very convoluted and without further documentation, it will be hard to figure out how they interact and how the program is supposed to work
- there are several interrupt routines that include printing out of date, this is bad practice and almost certainly will create issues.

Sorry, carefully reading your question might help me to actually answer it
 
Looking at the datasheet of the MMA8653, I think the relevant chapters are 6.7 (freefall / motion detect registers) and 6.9.3 through 6.9.5 (CTRL_REG3-5, interrupt configuration registers).
 
In the linked Arduino code, ctrl_reg3-5 are already available. Add values for the motion detect registers.
int ff_mt_cfg = 0x15;  // Freefall/motion configuration register int ff_mt_src = 0x16;  // Freefall/motion source register int ff_mt_ths = 0x17;  // Freefall/motion threshold register int ff_mt_count = 0x18;  // Freefall/motion debounce register (Personally I'd use #define reg_name reg_address for this, but I will stick with the style of the Arduino code linked above)
 
You can use the I2C_SEND function in the Arduino code to set the registers to the desired values. I'd expand on the example's ACC_INIT function.
 
1. Set the desired detection mode with the bits in FF_MT_CFG.
Set bit 6 to 1 (OAE, detect mode, 0 = freefall, 1 = motion). Motion means, any axis measures above the threshold
Set bits 3, 4, 5 to 1 for the axis you want to detect on (XEFE, YEFE, ZEFE, representing x, y, z respectively).
Leave the other bits at 0.
0x78 looks like a reasonable value. You may need to exclude the axis of gravity when trying to detect motion < 1g.
 
2. Set the desired threshold at which motion is detected in FF_MT_THS
Set this register to a value between 0 and 127, representing 0 to 8g.
The register also has a flag (bit 7, DBCNTM) that determines how debouncing works. I think leaving it at 0 is fine.
0x20 would set about 2g as trigger level, be careful with values < 1g to avoid detecting gravity as motion.
 
3. Set how many samples are needed to trigger the motion detection in FF_MT_COUNT
Set this register to a value between 0 and 255. The duration depends on the update rate (ODR), which the Arduino example set to 800Hz. So each sample represents a 1/800th of a second. I'd experiment with values around 10 and lower it when reaction is too sluggish or increase it if detection is triggered randomly.
0x0a represents a debounce counter value of 10.
 
4. Optional: Set the interrupt pin we want to wiggle in CTRL_REG5
Bit 2 controls the interrupt pin for motion detection, either INT1 (1) or INT2 (0).
Default is INT2, so we only need to write to this register if we want to use the INT1 pin.
 
5. Optional: Set how the pin wiggles CTRL_REG3
Bit 1 (IPOL) selects, whether the pin goes high to low or low to high when an interrupt occurs. Default is going from high to low.
You will also need to look into this register if you use the sleep modes of the accelerometer.
0x01 will make the interrupt pin go high when motion is detected
 
6. Enable interrupt from motion detection in CTRL_REG4
Bit 2 enables the freefall/motion interrupt.
0x02 will enable the interrupt.
 
So in summary:
I2C_SEND(ff_mt_cfg, 0x78); // motion detection, x, y, z I2C_SEND(ff_mt_ths, 0x20); // 2g I2C_SEND(ff_mt_count, 0x0a); // debounce over 10 readings I2C_SEND(ctrl_reg4, 0x02); // enable motion interrupt (default is INT2 pin) When you connect INT2 pin of the accelerometer to the MSP430, you can then use DigitalRead or AttachInterrupt to react to the signal.
 
All the above is just theoretical as I don't have this chip at hand. But I obviously had too much time at hand

Sorry, carefully reading your question might help me to actually answer it
 
Looking at the datasheet of the MMA8653, I think the relevant chapters are 6.7 (freefall / motion detect registers) and 6.9.3 through 6.9.5 (CTRL_REG3-5, interrupt configuration registers).
 
In the linked Arduino code, ctrl_reg3-5 are already available. Add values for the motion detect registers.
int ff_mt_cfg = 0x15;  // Freefall/motion configuration register int ff_mt_src = 0x16;  // Freefall/motion source register int ff_mt_ths = 0x17;  // Freefall/motion threshold register int ff_mt_count = 0x18;  // Freefall/motion debounce register (Personally I'd use #define reg_name reg_address for this, but I will stick with the style of the Arduino code linked above)
 
You can use the I2C_SEND function in the Arduino code to set the registers to the desired values. I'd expand on the example's ACC_INIT function.
 
1. Set the desired detection mode with the bits in FF_MT_CFG.
Set bit 6 to 1 (OAE, detect mode, 0 = freefall, 1 = motion). Motion means, any axis measures above the threshold
Set bits 3, 4, 5 to 1 for the axis you want to detect on (XEFE, YEFE, ZEFE, representing x, y, z respectively).
Leave the other bits at 0.
0x78 looks like a reasonable value. You may need to exclude the axis of gravity when trying to detect motion < 1g.
 
2. Set the desired threshold at which motion is detected in FF_MT_THS
Set this register to a value between 0 and 127, representing 0 to 8g.
The register also has a flag (bit 7, DBCNTM) that determines how debouncing works. I think leaving it at 0 is fine.
0x20 would set about 2g as trigger level, be careful with values < 1g to avoid detecting gravity as motion.
 
3. Set how many samples are needed to trigger the motion detection in FF_MT_COUNT
Set this register to a value between 0 and 255. The duration depends on the update rate (ODR), which the Arduino example set to 800Hz. So each sample represents a 1/800th of a second. I'd experiment with values around 10 and lower it when reaction is too sluggish or increase it if detection is triggered randomly.
0x0a represents a debounce counter value of 10.
 
4. Optional: Set the interrupt pin we want to wiggle in CTRL_REG5
Bit 2 controls the interrupt pin for motion detection, either INT1 (1) or INT2 (0).
Default is INT2, so we only need to write to this register if we want to use the INT1 pin.
 
5. Optional: Set how the pin wiggles CTRL_REG3
Bit 1 (IPOL) selects, whether the pin goes high to low or low to high when an interrupt occurs. Default is going from high to low.
You will also need to look into this register if you use the sleep modes of the accelerometer.
0x01 will make the interrupt pin go high when motion is detected
 
6. Enable interrupt from motion detection in CTRL_REG4
Bit 2 enables the freefall/motion interrupt.
0x02 will enable the interrupt.
 
So in summary:
I2C_SEND(ff_mt_cfg, 0x78); // motion detection, x, y, z I2C_SEND(ff_mt_ths, 0x20); // 2g I2C_SEND(ff_mt_count, 0x0a); // debounce over 10 readings I2C_SEND(ctrl_reg4, 0x02); // enable motion interrupt (default is INT2 pin) When you connect INT2 pin of the accelerometer to the MSP430, you can then use DigitalRead or AttachInterrupt to react to the signal.
 
All the above is just theoretical as I don't have this chip at hand. But I obviously had too much time at hand

@@ak96 Nothing wrong with preferring bare metal, my preference as well
 
Take a look at the innards of the counter library, even if you don't plan to use Energia. It basically sets up a timer to count up when a pin changes from 0 to 1. Using the timer, you don't need an interrupt for the counting itself.
 
The source code of the library may look a bit cryptic, because it tries to accommodate many different MSP430s. The gist is:
 
1. Set GPIO pin as input and select it's function (PxSEL) as timer input. The timer input (TxxCLK) is only available on a few pins, consult your MCUs datasheet.
2. Configure timer for external clock and continuous mode
3. Functions to start, stop and reset the timer as well as reading out the current timer value.
 
Run the timer for a known time, and the number of pulses will allow to determine the rate.
 
That being said, not sure if that's the best approach for a heart rate monitor. Measuring the time between pulses might be more sensible:
 
1. Start the timer, driven by one of the MSP's internal clocks. Use a divider to avoid overflowing the 16bit timer for the expected heart rate.
2. Wait for a pulse on a pin. A busy loop reading the pin is probably good enough for a beginner project.
3. When a pulse arrives, read the timer value.
4. Calculate the rate using clock frequency, timer divider and measured timer value.
 
I don't know what output signal heart rate monitors provide. If it's an analog wave form, you may need some circuitry to convert it to something that is usable for digital inputs and/or use the built-in comparator or ADC peripherals. 

The noise you see probably correlates with packets sent over WiFi. Even if your application doesn't send anything, the CC3200 will occasionally send a packet to maintain a WiFi connection.
 
I can see three possible reasons:
1. the thermocouple acts as WiFi antenna
2. the trace between the amplifier and the CC3200 acts as WiFi antenna
3. noise and/or voltage drop on the power rail when the CC3200 transmits
 
Given that the AD8495 is a differential amplifier, we probably can rule out #1
 
If #2 is the culprit, you could add a low-pass filter to that connection. As simple RC filter that filters anything above a few KHz would probably work. E.g. 100 ohm in series and a 0.1-1 uF capacitor to ground. http://www.learningaboutelectronics.com/Articles/Low-pass-filter-calculator.php#answer1
 
If it's #3 make sure that you properly decoupled the power rail of the amplifier. The application note suggests 0.1 uF and 10 uF capacitors. Make sure they are placed close to the amplifier.

The noise you see probably correlates with packets sent over WiFi. Even if your application doesn't send anything, the CC3200 will occasionally send a packet to maintain a WiFi connection.
 
I can see three possible reasons:
1. the thermocouple acts as WiFi antenna
2. the trace between the amplifier and the CC3200 acts as WiFi antenna
3. noise and/or voltage drop on the power rail when the CC3200 transmits
 
Given that the AD8495 is a differential amplifier, we probably can rule out #1
 
If #2 is the culprit, you could add a low-pass filter to that connection. As simple RC filter that filters anything above a few KHz would probably work. E.g. 100 ohm in series and a 0.1-1 uF capacitor to ground. http://www.learningaboutelectronics.com/Articles/Low-pass-filter-calculator.php#answer1
 
If it's #3 make sure that you properly decoupled the power rail of the amplifier. The application note suggests 0.1 uF and 10 uF capacitors. Make sure they are placed close to the amplifier.

@@chicken
 
I am new to programming micro controllers. I only started a couple of days ago. I'm kind of uncomfortable using that energia library because it feels like...cheating. The project i'm working on is a heartbeat sensor with a physical circuit and micro controller to count the beats. I want to make this project from scratch as a learning experience, and using a library that does all of the work for me defeats that purpose I think. 
 
Also, that is not my code. I found it on an instructable.
 
So far, I've just learned how to blink LED's in different patterns at different speeds using interrupts and timers. What should I focus on learning to be able to make the heart rate monitor? Is there anything in particular I should look into?

Hi @@artium,
 
thank you very much (and also adafruit )
I ran the benchmarks on my msp432 launchpad and also on my msp430f5529 launchpad (25 MHz), here with #define USE_FAST_PINIO commented for both.
 
msp432
Display Power Mode: 0x9C
MADCTL Mode: 0x48
Pixel Format: 0x5
Image Format: 0x0
Self Diagnostic: 0x0
Benchmark                Time (microseconds)
Screen fill              31922493
Text                     1787874
Lines                    17494289
Horiz/Vert Lines         2618766
Rectangles (outline)     1675845
Rectangles (filled)      66276560
Circles (filled)         9775988
Circles (outline)        7653239
Triangles (outline)      5548662
Triangles (filled)       21812339
Rounded rects (outline)  3461099
Rounded rects (filled)   72269681
Done!


msp430f5529
ILI9341 Test!
Display Power Mode: 0x60
MADCTL Mode: 0x0
Pixel Format: 0xFF
Image Format: 0x0
Self Diagnostic: 0x0
Benchmark                Time (microseconds)
Screen fill              2263167
Text                     340734
Lines                    3615312
Horiz/Vert Lines         195546
Rectangles (outline)     133089
Rectangles (filled)      4699971
Circles (filled)         1194204
Circles (outline)        1580064
Triangles (outline)      1146462
Triangles (filled)       1952517
Rounded rects (outline)  558189
Rounded rects (filled)   5281704
Done!
 
 
The 432 seems to be significantly slower in everything than the 5529, which I don't understand yet. (I did use uint32_t, I forgot which one I used when writing the forum post away from my home computer)...

Hackaday today featured a sensor node which runs on harvested RF energy.
http://hackaday.com/2016/05/01/wisp-needs-no-battery-or-cable/
 
As the article mentions a 16bit CPU, I wondered if someone put an MSP430 to good low-power use. And yes, digging into the WISP5 project finds that it uses an MSP430FR5969.
 
Project wiki with links to source code and schematics here:
http://wisp5.wikispaces.com/WISP+Home