Jump to content

Foghorn

Members
  • Content Count

    23
  • Joined

  • Last visited

  • Days Won

    1

Foghorn last won the day on February 9 2014

Foghorn had the most liked content!

About Foghorn

  • Rank
    Member

Profile Information

  • Location
    Texas
  1. Foghorn

    trouble with battery backup

    Hmmmm...you could try using a small 10nF or 100nF decoupling cap across the Vcc pin of the MSP430 and directly connect the battery + terminal to the Vcc pin as well just to make sure without the 78L33 in the circuit but still with the AC adaptor powering the LEDs and 74LS chip. I know the MSP430 can handle up to 3.6V maximum. (Hopefully the battery does not exceed that). Under that condition, it "should" definitely be operational. Then, try backstepping to adding the diode in series with the battery. Then, check again to make sure the MSP430 is operational. If it is, feel free to add back in the series resistor to the battery and diode. Then, check for operation again. Finally if that checks out, reconnect the 78L33 and check again. I find backstepping helps my thought processes. By the way, if the battery is powering the MSP430 off of a couple milliamps, it could be advantageous to use a Germanium diode instead of a silicon diode since they have a smaller forward voltage drop (about 0.3V) and would result in less power being dissipated in the diode and thus a longer lasting battery.
  2. @@chicken That's true. I'd have to check into whether my idea is feasible with only comparator inputs (then again, I suppose there is always slope A/D conversion available if an integrator is used although I'm spoiled on ADCs). Truthfully, if I were to use the ESI, I'm not sure how long it would take for me to get a good grasp on its functioning to see how it fits into a design choice. Usually whenever I design something, I already have a good grasp of what microcontrollers are able to do and what peripherals I'll need. Then, I choose the best microcontroller that has what I need for the price. I'm more a fan of top-down rather than bottom-up design and build trees starting with the trunk rather than the branch.
  3. 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. Did you follow how to add the library to a project in CCS? It's listed in the documentation. I attached a snippet of the IQMath doc that can be found below. Also, I noticed that the CCS debugger also did strange things for me with the example program, too. The values shown in the debugger appear incorrect but the program works just fine. Kinda weird. I'll have to check it out more in-depth.
  5. Foghorn

    MSP430 and Java?

    Java probably isn't the best choice on a "strapped for memory" embedded system. I've had some experience with eLua, though. It's a good language that is often used in embedded systems, specifically built for them actually. Its use of tables is somewhat and I quote, "magical." It makes getting new people up and running on complex projects faster and has a lot of nice features.
  6. Foghorn

    Generic Button Debouncer

    All revisions can now be found on GitHub: https://github.com/tcleg
  7. Foghorn

    Beginner Question - Programming with a 'time delay'

    Welcome to 43oh! Anyway, I would suggest using Energia to program the MSP430 for the application you described. It's an Arduino-like IDE that should be able to help you more easily accomplish what you want. I'm assuming that the pneumatic actuator can be completely controlled by the state of an I/O pin, only simple on and off functionality is desired, and does not have any feedback mechanisms that might need monitoring. Just use the millis() or delay() function to wait the desired time, and then use the digitalWrite() function on the specific pin you would like to go High or Low. Rinse and repeat in a loop. No crystal oscillator is required.
  8. Foghorn

    Bliking a LED every 500ms

    I have attached a zipped file to the bottom of this post. It shows some examples of how to use Timer A. Read the "!README" file first. It will tell you what all of the example files are referring to. Then, look specifically at the msp430g2xx3_ta_* examples. They'll be helpful guides. MSP430g2xx3 Examples.zip
  9. I attached the IQMath Library documentation shown below. Starting on page 88 of the document, you'll find the benchmarks for the MSP430G2553. MSP430-IQmathLib-01_00_00_00.pdf
  10. Foghorn

    Bliking a LED every 500ms

    _BIC_SR(GIE); /*ENABLE INTERRUPT*/ That line actually "disables" interrupts. The function stands for "Bit Clear Status Register." It clears the GIE or General Interrupt Enable bit in the status register in this instance. What you want is: _BIS_SR(GIE); /*ENABLE INTERRUPT*/ This enables interrupts. It stands for "Bit Set Status Register." This sets the GIE bit in the status register, which will then enable interrupts.
  11. I've been waiting for quite some time for some decent fixed-point library support from TI for the G Series and looks like we finally got it. The link to the libs is at the link below: http://www.ti.com/tool/msp430-iqmathlib?DCMP=ep-mcu-msp-iqmath-en&HQS=ep-mcu-msp-iqmath-em-tf-en&sp_rid_pod4=MTcwNDA5NzM3MzUS1&sp_mid_pod4=45625358&spMailingID=45625358&spUserID=MTcwNDA5NzM3MzUS1&spJobID=421682205&spReportId=NDIxNjgyMjA1S0 They even give benchmarks for the performance of an MSP430G2553 when using the various functions in the libraries.
  12. @@pabigot Thanks for the suggestions. I'll look into fully setting up a Github. And, I'll see if I can't put out some resources and examples to show platform independency. That way, the overall concept can be conveyed. Another tool for the proverbial toolbox I suppose. BSP430 is very nice. I like it. Really good Doxygen documentation (something many of my projects live and die by). As for target audience, I'll try to set the bar of skill as low as possible. I'll incorporate some of the concepts into Wiring libraries so that the benefit of the approach can be seen and applied. That way, Arduino enthusiasts can quickly pick up the concept and run with it and even embedded experts can benefit. As for assumed environment, I'm mainly shooting at the embedded space and C/C++ languages in my coming examples. No RTOS or POSIX required to deploy the concepts although can be used.
  13. @@Fred I figured that writing for platform independency would be more difficult. Although from a design perspective, I find it's much easier. Being able to separate algorithm and platform from each other means only focusing on one aspect of the library at a time. In other words, I can focus on the "idea" of how the library will work while not having to think about the "way" the specific platform will be hooked into it. So, I don't have to have a datasheet or driver API document open on my computer to create the library. I found that I could test C implemented algorithms in a vacuum (using a generic C compiler on my computer) by feeding it some typical data and check for problems on the output. Then afterward, I could hook the library into something architecture or framework specific and have one fully functioning library. Writing for platform independency is easier if the writer knows the concept. Writing object oriented code in C/C++ is harder too in the beginning although it saves many headaches later on. I'm promoting taking that idea one step farther and modularizing the algorithm away from the hardware that it will run on. @@spirilis You're right. The basic idea is to have hooks. FatFs is somewhat of a middleman layer that provides hooks that the hardware can be made to latch onto and then serve up the higher level info to the application. The diagram presented below shows how the module sits between the low-level components and the higher level application. This is very much inline with the concept I'm presenting. And because of FatFs's platform independency, it has been ported to lots of platforms. The same goes for FreeRTOS. It requires a lot of initial work porting it to other platforms (because it has a LOT of hooks) but the main functioning of the RTOS is encapsulated away and does not require changes. @@pabigot Thanks for telling me about putting in revision information and about linking to where newer revisions of the software can be found! I'll get right on that! Anyway, your list of reasons against why platform independency may not take off are definitely valid. Specifically in relation to software debouncing, there are many alternatives. Although, in relation to larger pieces of specific software, there usually aren't many alternatives (think of PID controllers. There are only so many ways to do PID). And as software grows larger and larger, porting that piece of software to other platforms (if it is platform dependent) becomes exceedingly arduous. So if a bright and shiny new toy (like a new powerful, low-cost, swiss army knife of a microcontroller were to come out), I would have to spend grueling hours porting over libraries that would give me the basic functions I desired. For very large pieces of well-written software, I might be willing to muddle copyrights. I plan to post more libraries here time soon that helps to better illustrate the idea of platform independent code. I figure that if people can get their heads around platform independency, more people might mimic that approach to design and reap the benefits: 1) Decreased debugging time. The algorithm can usually be tested in a vacuum while not worrying about how the hardware is interacting with it. 2) Increased modularity. A team can work on separate components at once. One side works on the algorithm. The other side works on the specific architecture implementation. 3) Increased portability. The algorithm can be instantly and painlessly ported to new microcontrollers and microcontroller families. Only the specific architecture implementation has to be re-coded. So even if no one else discovers the code you might post on internet and thus won't get the benefits of portability, the first two aspects of decreased debugging time and increased modularity are overall project improvements. @@Rei Vilo When I was referring to platform independency, I was referring to also being free of required frameworks as well as architectures. I love what the Processing / Wiring / Arduino framework has done in the realm of hobbyists, though. It got hobbyists talking and cooperating with each other. Hobbyists can now build way more complex projects than if they were going alone and building everything custom.
  14. This is a thought I've been mulling on for a while now.... I recently finished working on prototyping an auto-balancing robot. I used the Tiva C Launchpad since the TM4C123GH6PM microcontroller that comes on the board is well-suited for the realm of robotics. In my extensive Google searching for information when working on the project, I found most C and C++ libraries written for embedded applications are platform dependent, non-generic, and have non-modular algorithms. This makes porting these libraries to other platforms (like the Tiva C) significantly more difficult. What I mean by these terms: 1) Platform Dependent Written for a specific architecture. The functioning of the code is tied intimately to the specific microcontroller or microcontroller family for which it was written. For example, the code used in the library uses a specific driver library or certain registers. This makes porting to other embedded platforms/architectures especially difficult. 2) Non-Generic Only works for a narrow setup. For example, a button debouncer library that can only work for two buttons. TI actually wrote a button debouncer library for the Tiva C Launchpad that could only debounce the two onboard buttons on the Launchpad. 3) Non-Modular Algorithms In order to use a specific algorithm in the library, all algorithms must be subscribed to. For example, think of a library that tries to do a little of everything, which thus makes the library large (code wise). If I wanted to use just a small subset of the library's functionality, I would have to include the entire library including the superfluous aspects to my application. To improve library modularity and reduce porting time, libraries can be written as so: 1) Platform Independent Will work regardless of architecture. The algorithm and architecture implementation are separated. For example, the algorithm has its own separate header and source file while the architecture implementation has its own header and source files as well. This greatly reduces porting time since the algorithm specific file is completely architecture independent and thus can be ported instantly. 2) Generic Works for a wide variety of setups. For example, a button debouncer algorithm that can grow with the amount of buttons in use. 3) Modular Algorithms The algorithms are written for a specific use. For example, a matrix library that tries to do both floating point and fixed point matrix algebra can be split into a separate floating point matrix library and fixed point matrix library. Example of Platform Dependent Libraries Most Arduino Libraries Example of Platform Independent Libraries FatFs and Petite FatFs Most RTOSes If libraries were originally written with those latter qualities in mind, I don't think I would have had nearly as tough of a time with my robotics project.
  15. Foghorn

    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
×