Jump to content
43oh

Foghorn

Members
  • Content Count

    23
  • Joined

  • Last visited

  • Days Won

    1

Reputation Activity

  1. Like
    Foghorn got a reaction from freshfeesh in Scan Interface Applications - Five Members Win A Target Board And An MSP-FET   
    I must admit that this peripheral looks like a jack-of-all-trades kind. It's like an ADC, DMA, Comparator, Timer, and Processor all rolled into one.
     
    From what I gather, what makes this peripheral extra special is its configurable state machine.
     
    Correct me if I'm wrong, but this peripheral seems to act "generally" in this way:
    1) Takes an ADC sample.
    2) Stores it in dedicated RAM.
    3) Configured state machine processes that data and stores results. Sets up for the next measurement.
    4) State machine may or may not check/change its timer running in capture mode depending on the measurements being taken.
    5) May generate Interrupt.
    6) Repeat
     
    A lot of this can be easily replicated in software by lots of microcontrollers, but the advantage of this peripheral is that all of the sampling and processing takes place in the background without processor intervention and allows the processor to sleep longer and save more power.
     
    So, the ultimate benefit of this peripheral is to save power in applications that requires the processor to supervise the measurement-taking process. This is especially important in battery applications that require constant measurement taking.
     
    I can see why some of the applications would be flow metering and fitness tracking (they both require lots of measurements).
     
    My submission for this contest would be battery-powered auto-balancing applications. Auto-balancing requires constant sampling of motion sensors and sometimes combines optical data to aid in balancing by detecting the distance of a sensor relative to the ground. If the auto-balancing device moves, a quadrature encoder's velocity data would supplement the acceleration data of an accelerometer and angular velocity of a gyroscope. 
  2. Like
    Foghorn got a reaction from tripwire in Scan Interface Applications - Five Members Win A Target Board And An MSP-FET   
    I must admit that this peripheral looks like a jack-of-all-trades kind. It's like an ADC, DMA, Comparator, Timer, and Processor all rolled into one.
     
    From what I gather, what makes this peripheral extra special is its configurable state machine.
     
    Correct me if I'm wrong, but this peripheral seems to act "generally" in this way:
    1) Takes an ADC sample.
    2) Stores it in dedicated RAM.
    3) Configured state machine processes that data and stores results. Sets up for the next measurement.
    4) State machine may or may not check/change its timer running in capture mode depending on the measurements being taken.
    5) May generate Interrupt.
    6) Repeat
     
    A lot of this can be easily replicated in software by lots of microcontrollers, but the advantage of this peripheral is that all of the sampling and processing takes place in the background without processor intervention and allows the processor to sleep longer and save more power.
     
    So, the ultimate benefit of this peripheral is to save power in applications that requires the processor to supervise the measurement-taking process. This is especially important in battery applications that require constant measurement taking.
     
    I can see why some of the applications would be flow metering and fitness tracking (they both require lots of measurements).
     
    My submission for this contest would be battery-powered auto-balancing applications. Auto-balancing requires constant sampling of motion sensors and sometimes combines optical data to aid in balancing by detecting the distance of a sensor relative to the ground. If the auto-balancing device moves, a quadrature encoder's velocity data would supplement the acceleration data of an accelerometer and angular velocity of a gyroscope. 
  3. Like
    Foghorn got a reaction from chicken in Scan Interface Applications - Five Members Win A Target Board And An MSP-FET   
    I must admit that this peripheral looks like a jack-of-all-trades kind. It's like an ADC, DMA, Comparator, Timer, and Processor all rolled into one.
     
    From what I gather, what makes this peripheral extra special is its configurable state machine.
     
    Correct me if I'm wrong, but this peripheral seems to act "generally" in this way:
    1) Takes an ADC sample.
    2) Stores it in dedicated RAM.
    3) Configured state machine processes that data and stores results. Sets up for the next measurement.
    4) State machine may or may not check/change its timer running in capture mode depending on the measurements being taken.
    5) May generate Interrupt.
    6) Repeat
     
    A lot of this can be easily replicated in software by lots of microcontrollers, but the advantage of this peripheral is that all of the sampling and processing takes place in the background without processor intervention and allows the processor to sleep longer and save more power.
     
    So, the ultimate benefit of this peripheral is to save power in applications that requires the processor to supervise the measurement-taking process. This is especially important in battery applications that require constant measurement taking.
     
    I can see why some of the applications would be flow metering and fitness tracking (they both require lots of measurements).
     
    My submission for this contest would be battery-powered auto-balancing applications. Auto-balancing requires constant sampling of motion sensors and sometimes combines optical data to aid in balancing by detecting the distance of a sensor relative to the ground. If the auto-balancing device moves, a quadrature encoder's velocity data would supplement the acceleration data of an accelerometer and angular velocity of a gyroscope. 
  4. Like
    Foghorn got a reaction from bluehash in Generic Button Debouncer   
    All revisions can now be found on GitHub:
     
    https://github.com/tcleg
  5. Like
    Foghorn got a reaction from tripwire in Generic Button Debouncer   
    I implemented Jack Ganssle's State Button Debouncer Algorithm as C/C++ platform independent libraries. This is a fairly robust algorithm that can play nicely with interrupts (if the library is set up to be used that way) and can also work with setups where the button pins are polled on a regular interval instead.
     
    The library can debounce buttons on an 8 bit port in parallel and is efficient in that it only requires 14 bytes of RAM per instantiation, is malleable in that the amount of RAM consumed by each instantiation can be reduced if desired, and uses no computationally expensive operations such as multiplication and division to perform the debouncing.  If you would like a detailed explanation of the theory behind the algorithm, feel free to follow the link provided below: 
     
    http://www.ganssle.com/debouncing.htm
     
    The rest of the documentation can be found inside of the header files within the zipped file below. 
     
    EDIT:
     
    Updated the button debouncer to revision 1.1.
     
    Now instead of specifying pullups or pulldowns are being used for an entire port, you can pick and choose which button pins will have pullups or pulldowns respectively.
     
    Also, there is no additional performance or extra RAM penalty for this approach. So, enjoy the extra functionality.
    Button Debouncer Rev 1.1.zip
  6. Like
    Foghorn got a reaction from bluehash in Generic Button Debouncer   
    I implemented Jack Ganssle's State Button Debouncer Algorithm as C/C++ platform independent libraries. This is a fairly robust algorithm that can play nicely with interrupts (if the library is set up to be used that way) and can also work with setups where the button pins are polled on a regular interval instead.
     
    The library can debounce buttons on an 8 bit port in parallel and is efficient in that it only requires 14 bytes of RAM per instantiation, is malleable in that the amount of RAM consumed by each instantiation can be reduced if desired, and uses no computationally expensive operations such as multiplication and division to perform the debouncing.  If you would like a detailed explanation of the theory behind the algorithm, feel free to follow the link provided below: 
     
    http://www.ganssle.com/debouncing.htm
     
    The rest of the documentation can be found inside of the header files within the zipped file below. 
     
    EDIT:
     
    Updated the button debouncer to revision 1.1.
     
    Now instead of specifying pullups or pulldowns are being used for an entire port, you can pick and choose which button pins will have pullups or pulldowns respectively.
     
    Also, there is no additional performance or extra RAM penalty for this approach. So, enjoy the extra functionality.
    Button Debouncer Rev 1.1.zip
  7. Like
    Foghorn got a reaction from Automate in Generic Button Debouncer   
    I implemented Jack Ganssle's State Button Debouncer Algorithm as C/C++ platform independent libraries. This is a fairly robust algorithm that can play nicely with interrupts (if the library is set up to be used that way) and can also work with setups where the button pins are polled on a regular interval instead.
     
    The library can debounce buttons on an 8 bit port in parallel and is efficient in that it only requires 14 bytes of RAM per instantiation, is malleable in that the amount of RAM consumed by each instantiation can be reduced if desired, and uses no computationally expensive operations such as multiplication and division to perform the debouncing.  If you would like a detailed explanation of the theory behind the algorithm, feel free to follow the link provided below: 
     
    http://www.ganssle.com/debouncing.htm
     
    The rest of the documentation can be found inside of the header files within the zipped file below. 
     
    EDIT:
     
    Updated the button debouncer to revision 1.1.
     
    Now instead of specifying pullups or pulldowns are being used for an entire port, you can pick and choose which button pins will have pullups or pulldowns respectively.
     
    Also, there is no additional performance or extra RAM penalty for this approach. So, enjoy the extra functionality.
    Button Debouncer Rev 1.1.zip
  8. Like
    Foghorn got a reaction from igor in Generic Button Debouncer   
    I implemented Jack Ganssle's State Button Debouncer Algorithm as C/C++ platform independent libraries. This is a fairly robust algorithm that can play nicely with interrupts (if the library is set up to be used that way) and can also work with setups where the button pins are polled on a regular interval instead.
     
    The library can debounce buttons on an 8 bit port in parallel and is efficient in that it only requires 14 bytes of RAM per instantiation, is malleable in that the amount of RAM consumed by each instantiation can be reduced if desired, and uses no computationally expensive operations such as multiplication and division to perform the debouncing.  If you would like a detailed explanation of the theory behind the algorithm, feel free to follow the link provided below: 
     
    http://www.ganssle.com/debouncing.htm
     
    The rest of the documentation can be found inside of the header files within the zipped file below. 
     
    EDIT:
     
    Updated the button debouncer to revision 1.1.
     
    Now instead of specifying pullups or pulldowns are being used for an entire port, you can pick and choose which button pins will have pullups or pulldowns respectively.
     
    Also, there is no additional performance or extra RAM penalty for this approach. So, enjoy the extra functionality.
    Button Debouncer Rev 1.1.zip
  9. Like
    Foghorn got a reaction from bluehash in [Library] Six Axis or 6 DOF Complementary Filter   
    Update!
     
    I revised the complementary filter. It should work better than before now. I realized I had a bug floating around in the library. It is corrected and works a treat.
  10. Like
    Foghorn got a reaction from reaper7 in [Library] Six Axis or 6 DOF Complementary Filter   
    Update!
     
    I revised the complementary filter. It should work better than before now. I realized I had a bug floating around in the library. It is corrected and works a treat.
  11. Like
    Foghorn got a reaction from rober359 in [Library] Six Axis or 6 DOF Complementary Filter   
    I've been working on getting the MPU-6050 up and running on the Tiva C and thought I might share the complementary filter library that I created. TI provides a 9 DOF DCM Complementary Filter, but it will not work unless you also have the magnetometer data to go with it. Anyway, hope this helps out anyone who might need to use it.
     
    Enjoy!
     
    https://github.com/tcleg/SixAxisComplementaryFilter.git
  12. Like
    Foghorn got a reaction from superbrew in [Library] Six Axis or 6 DOF Complementary Filter   
    I've been working on getting the MPU-6050 up and running on the Tiva C and thought I might share the complementary filter library that I created. TI provides a 9 DOF DCM Complementary Filter, but it will not work unless you also have the magnetometer data to go with it. Anyway, hope this helps out anyone who might need to use it.
     
    Enjoy!
     
    https://github.com/tcleg/SixAxisComplementaryFilter.git
  13. Like
    Foghorn got a reaction from bluehash in [Library] Six Axis or 6 DOF Complementary Filter   
    I'm building an auto-balancing robot and found that the MPU-6050 suited my needs as an orientation sensor as I only really require orientation about the X or Y axes. I decided that I would go ahead and form a library and make it public for anyone who also wants to use the MPU-6050 and other 6 DOF (degrees of freedom) sensors. TI already provides an MPU-6050 driver, so with this filter, it will make that device's output more noise free.
     
    I'm surprized that there are almost no simple, generic 6 DOF complementary filters out there on the web. I had to remedy that!
     
    I'm just glad the Tiva C microcontrollers are Cortex-M4F and thus have FPUs (floating-point units) as this library relies on floating point arithmetic and trigonometry. Thus, this library would not be too useful for the MSP430 unless I could rework it into using fixed-point arithmetic instead.
  14. Like
    Foghorn got a reaction from bluehash in [Library] Six Axis or 6 DOF Complementary Filter   
    I've been working on getting the MPU-6050 up and running on the Tiva C and thought I might share the complementary filter library that I created. TI provides a 9 DOF DCM Complementary Filter, but it will not work unless you also have the magnetometer data to go with it. Anyway, hope this helps out anyone who might need to use it.
     
    Enjoy!
     
    https://github.com/tcleg/SixAxisComplementaryFilter.git
×
×
  • Create New...