Best MSP430 for low-power but high i/o

The best universal MSP is IMHO the 5438A. Lots of I/O (up to 87 I/O pins), three timers for 10 PWM outputs, lots of space (16k of ram, 256k Flash) and four hardware UARTs.

If you like it cheaper, you can go for the version with 192 or 128k Flash. But this doesn't drop the power usage, only the price.

A smaller version wiht only two UARTs and 67 I/Os is also available.

The current consumption depends on what you do with it. With 1mA you can run it continuously with ~4MHz. On 1MHz it goes as low as 0.33mA. Plus whatever is needed by the active components. This does not count periods in low-power mode (CPU on 0MHz)

About monitoring I/Os, almost every MSP has two interrupt-capable ports which can 'monitor' up to 16 digital lines for changes with the CPU being off. However, on many of the smaller MSPs, the PWM outputs are multiplexed with the pins of these two ports.
Since the PWM runs in hardware when neither frequency nor DC change, this is quite low-power. Of course if you have to change the DC on every PWM cycle, then you'll need some more CPU power. But not too much if you're using lookup tables.

Hi Connor,

The MSP430 isn't particularly adept at generating lots of PWMs each at its own frequency.  The "best" MSP430s in this regard have only four timers.  Even though each timer has multiple PWM outputs, a single timer typically generates all of its PWMs at the same frequency -- only the duty cycle differs.  So in the typical case, that gives you four total frequencies.

You would be directly in the MSP430 wheelhouse if you were to encode all 15 digital inputs into just a few PWM outputs, where the duty cycle indicated the state of some of the outputs.  Perhaps each PWM output could encode 5 of the digital inputs or something.  The MSP430 can do something like that with < 250 uA average current.  Plus you could use a smaller, cheaper MSP430 this way.

But going back to your original requirements, I don't know of any good way for MSP430 to generate 15 independent frequencies on output pins.  The timers give you four, the USCI modules can give you perhaps four more, SMCLK and ACLK maybe a couple more.  After that I start running out of ideas.  Especially since you probably want minimal aliasing.

If you are open to other solutions beside the requirements you posted originally, maybe you could post more about the original problem or goal.  MSP430 may have other tricks up its sleeve to help.

Jeff

Hi Jeff,

I think perhaps we had a miscommunication on exactly what I'm trying to do. I need to communicate continuously which of the 15 inputs are currently active. I was planning on using a single PWM port with a varying duty cycle to generate an analog wave that has several frequencies embedded in it (one frequency for each active input). With a 1MHz clock speed, I'm having trouble generating fast enough frequencies, precisely enough, because I have to use CPU cycles on balancing all of the active frequencies so I need higher but it doesn't seem like anything over 4MHz is even possible with my energy constraint. 

Is there a way of making it more accurate? When I do generate a frequency, currently it seems to have a ~250kHz falloff. Is there anyway to increase this besides increasing the PWM resolution and/or clock speed?

Also, @Jens-Michael, it seems like the 5438A is a good fit, but if I looked up its price correctly is seems to be ~8 times more than the value series. Since I'm looking at manufacturing >100K of these, obviously that is important. Are there any cheaper ones that can handle everything? If I use an interrupt port for PWM, does that compromise all of its individual pins from being inputs?

Thanks guys!!

Hi Connor,

Sorry about misreading your first post.  You were perfectly clear I just didn't read it right.

Direct synthesis of a complex waveform is CPU-intensive stuff.  Your power budget frowns on CPU-intensive stuff.

Is the waveform already defined and set in stone?  Is the waveform eventually going over RF?

Jeff

Hi Jeff,

The waveform isn't set in stone. Do you have any better suggestions? We basically have 16 frequencies we are generating (each frequency signals one of the buttons being pressed) that are toggled depending if the corresponding button is pressed. It's not going over RF, but will be processed by another device which needs to know which buttons are being pressed. This side has access to much more computing power and is currently doing FFT to check (so it is flexible and doesn't need too high quality of a signal).  

Can you think of a better way to do this? Thanks

So you have a wired connection?  In that case, would a digital interface work for you?  How about UART or I2C?

I think even a value-line MSP430 could handle this problem if you use UART or I2C to send the button states every 100ms and after any change.  And that's super low power.

If that doesn't work, how many signals can you have going from the MSP430 to the other system?  (Are you limited to 1 signal and 1 ground?)

Jeff

Yes, I'm actually interfacing into the mic jack of an iPhone that's why I don't think a UART of I2C solution would work(?).

And I need to have reaction time probably down to at least 50ms. 

OK, makes sense now.

The raw data from the mic should be ADC values.  So maybe use dc voltages as symbols.  Then create a data frame.  For example:

START symbol = 500mV for 1ms.

ON symbol = 250mV for 1ms.

OFF symbol = 0mV for 1ms.

A "frame" would be a start symbol followed by 15 ON or OFF symbols in pre-arranged order.  The frame is only 16ms long, which gives you the response time you need.

No sine waves, no FFT, very low power on MSP430, and you can use a cheap value-line MSP430.  Still need to filter the PWM output before sending it to the iPhone.

Jeff

I'm not sure how I could get that accurate of scanning on the iPhone though. The clock doesn't seem to be nearly good enough...

http://atastypixel.com/blog/experiments-with-precise-timing-in-ios/

Do you have access to the raw ADC samples that feed the FFT?  If so, you should have enough.  The samples are taken at a "precise" sampling rate, and that rate is known by the FFT software too.  Therefore you can determine the time of any sample relative to any other sample when they are part of the same buffer or recording.

In the most basic implementation I can imagine, you would record a 16+ ms wave file, scan/process/decode it, then repeat.  But I really don't know anything about the iOS audio API.

Jeff

Jeff Tenney said:

So maybe use dc voltages as symbols.  Then create a data frame.

Good idea. I was thinking of something similar: just use the timing of one PWM: low-time is an 8 bit time that represents the lower 8 port pins (100µs..25.6ms) and high time the other 8 bits. So a frame is 200µs to 51.2ms, depending on the port state. Requires 5kHz input bandwidth on the microphone.

However, why not going one step further and connect the mike diretly to the MSPs UART TX line and send it as simple UART data. 1200Bd with parity will take 22bit/1200Bd = 18,3ms for sending 16 bit status information. On the iPhone, this must be decoded properly, of course, but it should be simpler than mixing frequencies and decoding them with FFT.

Thanks guys. Doing it that way is definitely possible and we've implemented that software (which is actually much much easier). 

In terms of the MCU program, it's pretty simple. Are there any best-practices to minimize power consumption? My code so far (haven't implemented buttons yet, but I'm guess ing it's not a ton more right?) is here: http://pastebin.com/CUPFU8PG 

I guess I don't really understand how to control the timer, but it seems like I am currently using a 1MHz timer which is more than enough so if I make the PWM resolution 1000, I get a pulse every 1ms. Are there more efficient practices for all of this or some good reading material? Thanks!

Well, there are lots of threads in this forum regarding how to do PWM with a timer. And yes, on 1MHz timer clock, every 1000 timer ticks make 1ms. So a PWM cycle time of 1000 cycles gives you 1kHz PWM frequency with a maximum resolution of 1µs for the duty cycle.

However, I think the UART aproach will be even simpler. Maybe there's already a software uart available for the iPhone? Due to the start/stop bit and parity bit mechanisms, it will also prevent you from getting aliased (bit-shifted) messages.
Actually, this has been done 30 years ago, when sending digital data through radio, recording it on audio tapes and then reading it into the C64, Sinclair, Atari etc. If these old and (in terms of computation performance) weak devices were able to do it after the signal has gone through radio receiver and audio tape, it really shouldn't be difficult to get a 100% reliable data transfer when you have a direct electrical connection between the two :)

very interesting! 

So UART is super low power too? I know nothing about it at all...is there a resource you can think of off the top of your head to help me along with it? Thanks!

Connor Zwick said:

So UART is super low power too?

UART power consumption depends on hardware inplementation. On MSP430, it is CMOS. That means, there are only two things drawing power: state changes and output loads.
With 1200Bd, you have not many state changes at all. Except for the baudrate divider stage. The only thing that might draw a significant amount of power is the external load - the current the port pin output driver has to drive to pull the line up or down. This depends on the iPad mic jack input impedance and the line connection capacitance. And is the same for any signal you send :)

I dare to say that using the MSPs UART for the signal generation doesn't draw more, bu tlikeley even less power than using a PWM method. And requires definitely much less CPU work (and therefore less power too).

About using the UART, there are the TI sample codes. But there's not much about it. Set it up properly (see users guide) and then write to TXBUF what you want to send. Just ensure that you do not write to TXBUF when the last byte is stil in there (a simple chek, as the UART signals an empty TXBUF with a flag).

If your send interval is large enough, you don't even need this check at all, but that's an optimization detail :)