Foghorn

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 t

@@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 t

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 measure

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.

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.

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

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. R

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

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

_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.

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.

@@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

@@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 (us

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

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 operati