nickds1

"...or tear more hair out..." May i be so bold as to suggest not using Energia in this case? For true micropower applications, total control of all aspects of the device's operation is essential. Having a framework doing stuff you don't know about in the background is not helpful when calculating the energy budget or predicting performance. I'm doing an FR5969 IoT project at the moment and it's coded from scratch. By careful design and fine tuning I've managed to get the power consumption so low that it'll run off a CR2032 for at least a year - every little bit of the code is tu

Late into this thread, and I haven't read it top to bottom, but there seems to be a slight conceptual gap developing regarding what C & C++ really are. They are languages, not environments. The C language was originally designed for telephone exchange testing & control. Subsequently, it was used to implement the early UNIX kernels. There is a "C Standard Library", which is distinct from the language proper - this is where printf etc. come from. The story is similar with C++ - the language is distinct from its support libraries, e.g. stdlib, STL, and the various boost librarie

I highly doubt that this is an HW issue, though it's possible.... lets start with the code... Is the Watchdog timer still running? You've not stopped it (though I don't use Energia and don't know if it's stopped by default).. The code you provided is a bit messy, but is essentially the same as in the driverlib manual, and looks OK, except the WDT is on. As this seems to be a timing-sensitive issue, I'd start by stopping the WDT.

Hi, I needed a way to see how much of my C++ stack was being consumed in my MSP application - the traditional way is to "poison" the stack with a known pattern, and then to see how much of it gets burnt away. So I wrote the following - hope folk find it useful: The following code allows you to simply do this and to check at any point how much of the pre-allocated stack was consumed during peak usage, i.e. how close your app got to the bottom of the stack, or indeed, whether it over-ran. The TI CCS documentation is completely wrong in the names it gives for the global symbols tha

You could always use void GPIO_toggleOutputOnPin ( uint8_t selectedPort, uint16_t selectedPins Simplifies the loop code a bit... )

This seems to be using a Raspberry Pi to drive the LEDs if you look carefully at the flow chart in the "Making of" associated video...

Quick question on this - the counters go from 0-n and reset at n, so the actual count would be n+1. I thought that to count precisely "n" tickets, the CCRx registers would have to be set to "n-1"...

Just wondering what RTOS people have been using (if any) that can take advantage of the MSP430[x] ULP modes? I've been having a look at TI-RTOS, FreeRTOS, TinyOS & Contiki etc. Experiences & thoughts welcome, Thanks

Bit new to the MSP430 - I have the new FR5969 launchpad and was playing with RTC_B. Ideally, I'd like to protect the RTC over a main power failure, i.e. keep it ticking but stop the rest of the processor (think clock that doesn't lose track during a power outage). Is there a way to do this without an external RTC (e.g. DS3231 etc.)? Some other MSP430s have a "VBAT" pin that helps in this, but not the FR5969... Thanks Nick

To be honest, I wasn't thinking so much about productisation, more about your safety. Even for personal use, I'd never use anything other than an X2 (you don't need X1 or Y-class) in this situation - you have a genuine fire hazard otherwise An X2 cap and a MOV are just a few cents, and could save you a world of pain ! Even better, use a Fairchild FSAR001B http://www.fairchildsemi.com/ds/FS/FSAR001B.pdf - cheap, small, no worries about capacitor types and does the job properly!

In London UK, recruiters get 18% or thereabouts - they ASK for 30%, but you'd have to be a pretty naive company to actually pay that - I've been recruiting staff for my teams for 30 years - we never pay more than 20%.

I just love clocks (especially cold-cathode and similar...)... Nice project... That's a good capacitor but not rated for this application - you should really be using an X1 or X2-rated cap for safety... not just for shock, but fire hazard etc. "X" capacitors are flame retardant and mandatory in Europe - don't know about US but both the Microchip App note and TI blog above also specify an X2-rated cap (as they should too!). A good one here would be VISHAY - MKP3382 X2, 4n7 @ 630VAC, p/n BFC233820472, Farnell p/n 121-5463 Also, you should probably have a MOV across the mains on

The compiler will in-line optimise the methods if required (helps if declared "inline") - if the ports definitions are const (which they are) the optimisations should be exactly the same as a templated class - you instantiate a static instance of the LCD class anyway... not sure what, if anything, is gained from using templates here other than a whole bunch of typing... just wondering... Further, using an initialiser list in the LCD constructor would allow class-local constants to be fixed during construction which is somewhat neater than using blank namespace or static consts and creates

Normally, wafers like this are stepped as the imagers can't maintain the super-fine focus over the whole wafer (this is certainly the case for fine-resolution chips such as modern CPUs). The wafer is stepped so that each die is imaged in turn - the tables cost an absolute fortune as they have to have phenomenal repeatability and the design of the lens is an enormously specialised art - only a few people in the world do it. Quoting a friend in another forum (who is a lens designer for these machines):

On some series of the MSP430, as we all know, there is a chip-series-unique serial number that can made from the lot/wafer ID plus the die X & Y positions - a total of 8 bytes. How are the X & Y positions & lot/wafer ID (and the other die-specific data) changed for each die - the masks can't be changed easily, so I would assume that some sort of fusible link was used that is programmed in after testing and before its sawn into individual die... are they fusible links or some other mechanism? e.g. the DS2401 uses a laser-programmed ROM.... Thanks