Permalink
Browse files

Restructure Arduino project into standard .cpp/.h form, update Doxyge…

…n comments
  • Loading branch information...
Jeff Rowberg
Jeff Rowberg committed Nov 9, 2014
1 parent 677a408 commit f7a1874f492d746ae9a3a480a1fc2cdde44cf61a
Showing with 7,818 additions and 6,369 deletions.
  1. +187 −0 keyglove/application.cpp
  2. +11 −147 keyglove/application.h
  3. +19 −8 keyglove/{application_stubs.h → application_stubs.cpp}
  4. +4 −4 keyglove/config.h
  5. +151 −0 keyglove/custom_protocol.cpp
  6. +8 −119 keyglove/custom_protocol.h
  7. +6 −7 keyglove/hardware.h
  8. +429 −0 keyglove/keyglove.cpp
  9. +66 −0 keyglove/keyglove.h
  10. +8 −357 keyglove/keyglove.ino
  11. +50 −0 keyglove/support_bluetooth.h
  12. +1,835 −0 keyglove/support_bluetooth2_iwrap.cpp
  13. +64 −1,880 keyglove/support_bluetooth2_iwrap.h
  14. +57 −0 keyglove/support_board.h
  15. +339 −0 keyglove/support_board_teensypp2_t19.cpp
  16. +12 −293 keyglove/support_board_teensypp2_t19.h
  17. +496 −0 keyglove/support_board_teensypp2_t37.cpp
  18. +12 −450 keyglove/support_board_teensypp2_t37.h
  19. +94 −0 keyglove/support_feedback.cpp
  20. +25 −122 keyglove/support_feedback.h
  21. +166 −0 keyglove/support_feedback_blink.cpp
  22. +10 −150 keyglove/support_feedback_blink.h
  23. +153 −0 keyglove/support_feedback_piezo.cpp
  24. +8 −117 keyglove/support_feedback_piezo.h
  25. +244 −0 keyglove/support_feedback_rgb.cpp
  26. +9 −198 keyglove/support_feedback_rgb.h
  27. +141 −0 keyglove/support_feedback_vibrate.cpp
  28. +8 −96 keyglove/support_feedback_vibrate.h
  29. +292 −0 keyglove/support_helper_3dmath.cpp
  30. +25 −250 keyglove/support_helper_3dmath.h
  31. +287 −0 keyglove/support_hid_keyboard.cpp
  32. +15 −253 keyglove/support_hid_keyboard.h
  33. +268 −0 keyglove/support_hid_mouse.cpp
  34. +11 −225 keyglove/support_hid_mouse.h
  35. +89 −0 keyglove/support_motion.cpp
  36. +12 −75 keyglove/support_motion.h
  37. +194 −0 keyglove/support_motion_mpu6050_hand.cpp
  38. +15 −155 keyglove/support_motion_mpu6050_hand.h
  39. +414 −0 keyglove/support_protocol.cpp
  40. +30 −516 keyglove/support_protocol.h
  41. +302 −0 keyglove/support_protocol_bluetooth.cpp
  42. +57 −250 keyglove/support_protocol_bluetooth.h
  43. +241 −0 keyglove/support_protocol_feedback.cpp
  44. +39 −194 keyglove/support_protocol_feedback.h
  45. +60 −0 keyglove/support_protocol_flex.cpp
  46. +3 −18 keyglove/support_protocol_flex.h
  47. +101 −0 keyglove/support_protocol_motion.cpp
  48. +23 −56 keyglove/support_protocol_motion.h
  49. +60 −0 keyglove/support_protocol_pressure.cpp
  50. +3 −18 keyglove/support_protocol_pressure.h
  51. +191 −0 keyglove/support_protocol_system.cpp
  52. +40 −122 keyglove/support_protocol_system.h
  53. +101 −0 keyglove/support_protocol_touch.cpp
  54. +23 −56 keyglove/support_protocol_touch.h
  55. +60 −0 keyglove/support_protocol_touchset.cpp
  56. +3 −18 keyglove/support_protocol_touchset.h
  57. +224 −0 keyglove/support_touch.cpp
  58. +17 −208 keyglove/support_touch.h
  59. +6 −7 keyglove/version.h
@@ -0,0 +1,187 @@
// Keyglove controller source code - Custom application behavior implementaions
// 2014-11-07 by Jeff Rowberg <jeff@rowberg.net>

/* ============================================
Controller code is placed under the MIT license
Copyright (c) 2014 Jeff Rowberg
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE SOFTWARE.
===============================================
*/

/**
* @file application.h
* @brief **USER-DEFINED:** Custom application behavior definition
* @author Jeff Rowberg
* @date 2014-11-07
*
* Use this file to define any autonomous behavior the firmware should have. By
* default, the processor will boot into what would be considered "idle" mode,
* available for KGAPI control from an external host but otherwise not really
* doing anything. Using custom event handlers, you can trigger actions based on
* API events, such as boot/reset, Bluetooth ready, touch status changing, etc.
*
* Technically these custom event handlers could go anywhere in the codebase,
* but it makes sense to centralize everything in one place for simplicity. You
* will most likely not need to modify any other source files (except possibly
* the "config.h" file which defines the modular hardware configuration), unless
* you are intentionally changing or adding to the low-level functionality of
* the Keyglove codebase.
*/

#include "keyglove.h"
#include "support_board.h"
#include "support_protocol.h"
#include "support_feedback.h"
#include "support_motion.h"
#include "support_touch.h"
#include "support_bluetooth.h"
#include "support_hid_keyboard.h"
#include "application.h"

uint8_t touch_data_prev[KG_BASE_COMBINATION_BYTES]; ///< Container for tracking previous touch status bits
uint8_t touch_data_xor[KG_BASE_COMBINATION_BYTES]; ///< Container for XOR'd touch status bits

/**
* @brief Indicates that Keyglove has completed the boot process
* @return KGAPI event packet fallthrough, zero allows and non-zero prevents
*
* This event is triggered on every power-on or reset, after all internal
* subsystems have been initialized. For custom application behavior, it is
* similar to a "main()" entry point in C, or the "setup()" function in an
* Arduino sketch. Note that the "system_boot" event may seem intuitive for
* this purpose also, but that runs before the individual subsystem setup
* functions, which may overwrite some settings (like feedback mode changes).
*/
uint8_t my_kg_evt_system_ready() {
// start 3-second LED pulse after boot process finishes
kg_cmd_feedback_set_blink_mode(KG_BLINK_MODE_B3000_100);

// start RGB (red) LED fade cycle
//kg_cmd_feedback_set_rgb_mode(0, KG_RGB_MODE_F3000_3000, KG_RGB_MODE_F3000_3000, KG_RGB_MODE_F3000_3000);

// start 10-second repeating timer
//kg_cmd_system_set_timer(0, 1000, 0);

// allow KGAPI event packet transmission
return 0;
}

uint8_t my_kg_evt_system_timer_tick(uint8_t handle, uint32_t seconds, uint8_t subticks) {
// read raw battery voltage
int16_t rawBat = analogRead(0);
uint8_t payload[2] = { rawBat & 0xFF, (rawBat >> 8) & 0xFF };
send_keyglove_packet(KG_PACKET_TYPE_EVENT, 2, 0xFE, 0xFE, payload);

// prevent KGAPI event packet transmission
return 1;
}

/**
* @brief Indicates that a motion sensor's measurement data has been updated
* @param[in] index Relevant motion sensor
* @param[in] flags Flags indicating which measurement data is represented
* @param[in] data_len Length in bytes of data_data buffer
* @param[in] data_data New measurement data
* @return KGAPI event packet fallthrough, zero allows and non-zero prevents
*/
uint8_t my_kg_evt_motion_data(uint8_t index, uint8_t flags, uint8_t data_len, uint8_t *data_data) {
// TODO: special event handler code here
// ...

// prevent KGAPI event packet transmission
return 1;
}

/**
* @brief "bluetooth_ready" event handler
* @return KGAPI event packet fallthrough, zero allows and non-zero prevents
*
* This event is triggered once the Bluetooth subsystem has been tested for the
* expected communication response over UART, and all relevant module settings
* have been requested and parsed.
*/
uint8_t my_kg_evt_bluetooth_ready() {
// set the Bluetooth mode to autocall paired devices
kg_cmd_bluetooth_set_mode(KG_BLUETOOTH_MODE_AUTOCALL);

// allow KGAPI event packet transmission
return 0;
}

/**
* @brief Indicates that the touch sensor status has changed
* @param[in] status_len Length in bytes of status_data buffer
* @param[in] status_data New touch status
* @return KGAPI event packet fallthrough, zero allows and non-zero prevents
*
* This event is triggered every time any touch status bits change. This data is
* detected in the update_board_touch() function in the board definition file,
* and filtered/debounced in the update_touch() function in the support_touch.h
* file.
*/
uint8_t my_kg_evt_touch_status(uint8_t status_len, uint8_t *status_data) {
// XOR current and previous to identify which bits have been changed
for (uint8_t i = 0; i < KG_BASE_COMBINATION_BYTES; i++) {
touch_data_xor[i] = touch_data_prev[i] ^ status_data[i];
}

// bits set in "touch_data_prev" indicate which touches are on as of last time any touches changed
// bits set in "touch_data_xor" indicate which touches have just flipped between on and off
// bits set in "status_data" indicate which touches are on right now

// check to see whether this is adding or removing
if (memcmp(status_data, touch_data_prev, KG_BASE_COMBINATION_BYTES) > 0) {
// touch added
if (KGT_AY(touch_data_xor)) kg_cmd_motion_set_mode(0, true); // enable motion sensor 0 (default MPU-6050 on back of hand)
else if (KGT_DY(touch_data_xor)) keyboard_key_down(KEY_A); // send key-down report for 'A' key
} else {
// touch removed
if (KGT_AY(touch_data_xor)) kg_cmd_motion_set_mode(0, false); // disable motion sensor 0
else if (KGT_DY(touch_data_xor)) keyboard_key_up(KEY_A); // send key-up report for 'A' key
else if (KGT_GY(touch_data_xor)) keyboard_key_press(KEY_A); // send key down and key-up report for 'A' key
}

// store current touch status for comparing next time
memcpy(touch_data_prev, status_data, status_len);

// allow KGAPI event packet transmission
return 0;
}

/**
* @brief Custom application setup routine
*
* This function is called during the main firmware initialization procedure,
* inside the setup() function in the keyglove.ino file. It is necessary here to
* assign the event handler functions to the correct function pointers; without
* this step, the handlers defined above will not be called when the relevant
* events are generated.
*
* You can also place any other application initialization code in this function
* to ensure that it is run anytime the system boots or is reset.
*/
void setup_application() {
// assign any events implemented above here so they will take effect
kg_evt_system_ready = my_kg_evt_system_ready;
kg_evt_system_timer_tick = my_kg_evt_system_timer_tick;
kg_evt_motion_data = my_kg_evt_motion_data;
kg_evt_bluetooth_ready = my_kg_evt_bluetooth_ready;
kg_evt_touch_status = my_kg_evt_touch_status;
}
@@ -1,5 +1,5 @@
// Keyglove controller source code - Custom application behavior definition
// 7/4/2014 by Jeff Rowberg <jeff@rowberg.net>
// Keyglove controller source code - Custom application behavior declarations
// 2014-11-07 by Jeff Rowberg <jeff@rowberg.net>

/* ============================================
Controller code is placed under the MIT license
@@ -27,156 +27,20 @@ THE SOFTWARE.

/**
* @file application.h
* @brief **USER-DEFINED:** Custom application behavior definition
* @brief **USER-DEFINED:** Custom application behavior declarations
* @author Jeff Rowberg
* @date 2014-07-04
*
* Use this file to define any autonomous behavior the firmware should have. By
* default, the processor will boot into what would be considered "idle" mode,
* available for KGAPI control from an external host but otherwise not really
* doing anything. Using custom event handlers, you can trigger actions based on
* API events, such as boot/reset, Bluetooth ready, touch status changing, etc.
*
* Technically these custom event handlers could go anywhere in the codebase,
* but it makes sense to centralize everything in one place for simplicity. You
* will most likely not need to modify any other source files (except possibly
* the "config.h" file which defines the modular hardware configuration), unless
* you are intentionally changing or adding to the low-level functionality of
* the Keyglove codebase.
* @date 2014-11-07
*/

#ifndef _APPLICATION_H_
#define _APPLICATION_H_

uint8_t touch_data_prev[KG_BASE_COMBINATION_BYTES]; ///< Container for tracking previous touch status bits
uint8_t touch_data_xor[KG_BASE_COMBINATION_BYTES]; ///< Container for XOR'd touch status bits
uint8_t my_kg_evt_system_ready();
uint8_t my_kg_evt_system_timer_tick(uint8_t handle, uint32_t seconds, uint8_t subticks);
uint8_t my_kg_evt_motion_data(uint8_t index, uint8_t flags, uint8_t data_len, uint8_t *data_data);
uint8_t my_kg_evt_bluetooth_ready();
uint8_t my_kg_evt_touch_status(uint8_t status_len, uint8_t *status_data);

/**
* @brief Indicates that Keyglove has completed the boot process
* @return KGAPI event packet fallthrough, zero allows and non-zero prevents
*
* This event is triggered on every power-on or reset, after all internal
* subsystems have been initialized. For custom application behavior, it is
* similar to a "main()" entry point in C, or the "setup()" function in an
* Arduino sketch. Note that the "system_boot" event may seem intuitive for
* this purpose also, but that runs before the individual subsystem setup
* functions, which may overwrite some settings (like feedback mode changes).
*/
uint8_t my_kg_evt_system_ready() {
// start 3-second LED pulse after boot process finishes
kg_cmd_feedback_set_blink_mode(KG_BLINK_MODE_B3000_100);

// start RGB (red) LED fade cycle
//kg_cmd_feedback_set_rgb_mode(0, KG_RGB_MODE_F3000_3000, KG_RGB_MODE_F3000_3000, KG_RGB_MODE_F3000_3000);

// start 10-second repeating timer
//kg_cmd_system_set_timer(0, 1000, 0);

// allow KGAPI event packet transmission
return 0;
}

uint8_t my_kg_evt_system_timer_tick(uint8_t handle, uint32_t seconds, uint8_t subticks) {
// read raw battery voltage
int16_t rawBat = analogRead(0);
uint8_t payload[2] = { rawBat & 0xFF, (rawBat >> 8) & 0xFF };
send_keyglove_packet(KG_PACKET_TYPE_EVENT, 2, 0xFE, 0xFE, payload);

// prevent KGAPI event packet transmission
return 1;
}

/**
* @brief Indicates that a motion sensor's measurement data has been updated
* @param[in] index Relevant motion sensor
* @param[in] flags Flags indicating which measurement data is represented
* @param[in] data_len Length in bytes of data_data buffer
* @param[in] data_data New measurement data
* @return KGAPI event packet fallthrough, zero allows and non-zero prevents
*/
uint8_t my_kg_evt_motion_data(uint8_t index, uint8_t flags, uint8_t data_len, uint8_t *data_data) {
// TODO: special event handler code here
// ...

// prevent KGAPI event packet transmission
return 1;
}

/**
* @brief "bluetooth_ready" event handler
* @return KGAPI event packet fallthrough, zero allows and non-zero prevents
*
* This event is triggered once the Bluetooth subsystem has been tested for the
* expected communication response over UART, and all relevant module settings
* have been requested and parsed.
*/
uint8_t my_kg_evt_bluetooth_ready() {
// set the Bluetooth mode to autocall paired devices
kg_cmd_bluetooth_set_mode(KG_BLUETOOTH_MODE_AUTOCALL);

// allow KGAPI event packet transmission
return 0;
}

/**
* @brief Indicates that the touch sensor status has changed
* @param[in] status_len Length in bytes of status_data buffer
* @param[in] status_data New touch status
* @return KGAPI event packet fallthrough, zero allows and non-zero prevents
*
* This event is triggered every time any touch status bits change. This data is
* detected in the update_board_touch() function in the board definition file,
* and filtered/debounced in the update_touch() function in the support_touch.h
* file.
*/
uint8_t my_kg_evt_touch_status(uint8_t status_len, uint8_t *status_data) {
// XOR current and previous to identify which bits have been changed
for (uint8_t i = 0; i < KG_BASE_COMBINATION_BYTES; i++) {
touch_data_xor[i] = touch_data_prev[i] ^ status_data[i];
}

// bits set in "touch_data_prev" indicate which touches are on as of last time any touches changed
// bits set in "touch_data_xor" indicate which touches have just flipped between on and off
// bits set in "status_data" indicate which touches are on right now

// check to see whether this is adding or removing
if (memcmp(status_data, touch_data_prev, KG_BASE_COMBINATION_BYTES) > 0) {
// touch added
if (KGT_AY(touch_data_xor)) kg_cmd_motion_set_mode(0, true); // enable motion sensor 0 (default MPU-6050 on back of hand)
else if (KGT_DY(touch_data_xor)) keyboard_key_down(KEY_A); // send key-down report for 'A' key
} else {
// touch removed
if (KGT_AY(touch_data_xor)) kg_cmd_motion_set_mode(0, false); // disable motion sensor 0
else if (KGT_DY(touch_data_xor)) keyboard_key_up(KEY_A); // send key-up report for 'A' key
else if (KGT_GY(touch_data_xor)) keyboard_key_press(KEY_A); // send key down and key-up report for 'A' key
}

// store current touch status for comparing next time
memcpy(touch_data_prev, status_data, status_len);

// allow KGAPI event packet transmission
return 0;
}

/**
* @brief Custom application setup routine
*
* This function is called during the main firmware initialization procedure,
* inside the setup() function in the keyglove.ino file. It is necessary here to
* assign the event handler functions to the correct function pointers; without
* this step, the handlers defined above will not be called when the relevant
* events are generated.
*
* You can also place any other application initialization code in this function
* to ensure that it is run anytime the system boots or is reset.
*/
void setup_application() {
// assign any events implemented above here so they will take effect
kg_evt_system_ready = my_kg_evt_system_ready;
kg_evt_system_timer_tick = my_kg_evt_system_timer_tick;
kg_evt_motion_data = my_kg_evt_motion_data;
kg_evt_bluetooth_ready = my_kg_evt_bluetooth_ready;
kg_evt_touch_status = my_kg_evt_touch_status;
}
void setup_application();

#endif // _APPLICATION_H_
#endif // _APPLICATION_H_
Oops, something went wrong.

0 comments on commit f7a1874

Please sign in to comment.