bobnova

@@altineller not really, no. It's something of a hidden function.
 
You have to include wiring_analog.c (#include <wiring_analog.c>) to kick things off. That includes the PWMWrite function.
 
Then you can call it thusly:   PWMWrite(PIN,numberOfSteps,dutyCycle,frequency);
For example:   PWMWrite(PD_1,500,250,6000);
Would start PWM on pin PD_1, 500 steps from 0 to 100%, 50% duty cycle (500 / 2 = 250), 6000Hz frequency.
It's worth noting that the function call does glitch when you call it on a pin already putting PWM out. It's not enough to hear driving a speaker, but it could cause you issues if you're calling it a lot. There's a thread around here somewhere on that subject.
 
The frequency cap is very high, if I recall correctly I'd tested it to work >1MHz. I could be thinking about a different MCU, I've tested sort of a lot of them.

Minor update, did some very preliminary work on getting a FRx9x9 (currently, 5969) set up and timers running for pulse width counting / display update intervals / etc.
These things are far more complicated internally than the 2553s, that's for sure. It's been a bit of a headache, but I'm making headway.
It doesn't help that I've been almost entirely using Energia up to this point. Using CCS-level code inside Energia is all well and good, but Energia still takes care of all the basic setup, so I've had to figure out how to get all that going.
I think I've gotten most of it at least.
 
I start a new job on Monday, so things may go slowly. I really want to have this for my car (as I think I mentioned, my car has no tach at all, which frustrates me), so it will get done!

I wasn't able to get a NRF24 working with a MSP430G2452, let alone a 2231.
Not really sure what the 2452's problem was, easiest guess is RAM of course, as I don't know how much the library consumes.
I did a quick count and it seemed like enough, and went through the library a bit looking for references to HW at the 2452 doesn't have, but never really found much.
 
Doesn't surprise me much that it won't fit a 2231, those things are tiny as I recall.
 
 
 
As a note, when the library says that the NRF24 is in low power mode it really means it.
I have one outside right now running off a AA Power Board from Jeelabs (boosts >0.9v to 3.3v), connected to a 2553. It checks temp and light and battery level then sends out a packet containing that plus a count plus an ID number every ten seconds and sleeps the rest of the time. I hacked things up a bit to allow LPM3 in energia and set a timer running to wake it back up every ten seconds.
 
I put it outside in a plastic bag (rainy season) with an alkaline AA I found lying around that had ~1.32v unloaded.
After about eight weeks or so (more?) it's still running and the battery has gone down by about 30mV according to the node.
 
Very happy with the library am I.

Breadboard/long wire related inductance is the majority of it I'd guess. You get some of that just from the transistor(s) itself too.
A very small cap between the blue trace and VCC or GND (doesn't matter as long as they're both clean. I'd probably use GND) will eat a lot of that spike without slowing the rise/fall times too much.
My experience has been that even 10nF is enough to damp down spikes like those if there is some resistance in series with the incoming voltage (there is in this case, inside the touchscreen). That may even be too much, it's worth playing with.
You mileage may vary of course. It's hard to say how long the spikes last on that scope setting.\
If they're the sub-microsecond-duration sort I'm thinking of they are very easy to kill with small caps. The longer they last the harder they are to kill.

That userguide is not my friend.

That userguide is not my friend.

if(value >= (oldValue-sensitivity) || value <= (oldValue+sensitivity)) This will always return true.
This method will do what you want if you switch things around a little bit. You want to check to see if the new number is less than X - sensitivity or more than X + sensitivity, and if it is then you run your code.
If it isn't then you return false as the number is still within the sensitivity range.
 
[code]if(value <= (oldValue-sensitivity) || value >= (oldValue+sensitivity)){    doStuff();    return true; } else{   return false; } Just as an example. Please do note that the above has not actually been compiled/run.
 
 
Or do what abec. suggested, the end result is the same.
 
I'm not sure you need to check for 0 and 1023 specifically. If the last read was 1023 and the next read is also 1023 that will fall within the sensitivity range and be ignored.
Maybe I'm missing something there.
 
 
 
If you have time, do a few more samples with a bit of time between them.
If I can I like to sample decently often over a ~17ms time period to get rid of the 60Hz background EMI.
A running average can be a nice tool for this sort of thing too. Take value and add the last-read value then divide by 2. Very low memory usage, with decent long term averaging.
A small cap between the ADC input pin and GND or VCC can go a long way too, especially if it's a high resistance slow changing (relatively) input.

if(value >= (oldValue-sensitivity) || value <= (oldValue+sensitivity)) This will always return true.
This method will do what you want if you switch things around a little bit. You want to check to see if the new number is less than X - sensitivity or more than X + sensitivity, and if it is then you run your code.
If it isn't then you return false as the number is still within the sensitivity range.
 
[code]if(value <= (oldValue-sensitivity) || value >= (oldValue+sensitivity)){    doStuff();    return true; } else{   return false; } Just as an example. Please do note that the above has not actually been compiled/run.
 
 
Or do what abec. suggested, the end result is the same.
 
I'm not sure you need to check for 0 and 1023 specifically. If the last read was 1023 and the next read is also 1023 that will fall within the sensitivity range and be ignored.
Maybe I'm missing something there.
 
 
 
If you have time, do a few more samples with a bit of time between them.
If I can I like to sample decently often over a ~17ms time period to get rid of the 60Hz background EMI.
A running average can be a nice tool for this sort of thing too. Take value and add the last-read value then divide by 2. Very low memory usage, with decent long term averaging.
A small cap between the ADC input pin and GND or VCC can go a long way too, especially if it's a high resistance slow changing (relatively) input.

Even less time! Amazing!
 
Did figure out exactly what I want to do with the ESI bits though. I'm thinking that their ability to start/stop a timer to measure a pulse width is going to be used to collect ON time of a fuel injector.
For the early going I'll just measure fuel in seconds of flow per distance, or seconds of flow per trip. It won't be something that can be converted to MPG, but it'll be easy to see the difference driving style/etc. makes.
 
Having the ESI do the timer running means not having to use CPU cycles to do it but still getting a good solid time on it, which I like.
 
 
Spent some time trying to get the UART transmitting for debuging. Didn't manage to. I need to pry the setup out of the Energia FR5969 setup bits and try that.

Got mine too. Also a new job.
Would like to get started this weekend, we'll see how it goes.

OK, I have two three different projects that the ESI could be used with, I'm going to list 'em from least ambitious to most ambitious. The more ambitious the less likely I'll actually manage to do it, but who knows.
 
Possible project one:  Digital tachometer, speedometer, and intelligent shift light.
Uses the ESI to read either the ignitor's tach output (one pulse per ignition event, so two per engine revolution) or the vehicle speed sensor's square wave (whichever is more difficult to do with interrupts/timers, unknown at this time) as well as the throttle position sensor.
Displays engine RPM via either LCD screen or RGBLED bars (or both, plenty of GPIO here), also vehicle speed with LED indicators for common speed limits.
Based on throttle position, engine RPM and vehicle speed (and gear, calculated via engine RPM and road speed) it will also have a pair of shift lights, one to indicate for downshifting and one to indicate for upshifting.
Example: On the freeway behind someone at 60MPH in a 65 zone in 5th gear, left lane opens up and you can accelerate. If you give the engine a little bit of gas to accelerate slowly, no lights. Stomp on the gas and the downshift light comes on (perhaps blinking, to indicate multiple gears downward are indicated, as full throttle 60MPH is best done in 3rd gear on this car). If/when you downshift, the light goes out. Let off the throttle to maintain your new speed and the upshift light comes on, as 65MPH in 3rd is lousy for cruising.
Also indicates upshifts based on engine RPM directly, given a 6750 redline and high throttle angle the upshift light would come on around 6500RPM.
I may make the MCU learn the rev limits, may not.
ESI and FRAM are not specifically needed for this project, but using ESI for either tach or road speed would eliminate timing artifacts that would happen if the road speed and tach signals happened simultaneously, something that is guaranteed to happen eventually.
 
 
Possible project two:  Battery-free bicycle telemetry
Bicycle telemetry, read road speed via multiple magnets attached to one rim and a coil attached nearby.
Trick is, I want to make said magnet/coil arrangement power the MCU as well as give it a timing signal.
Both FRAM for its low power consumption and the ESI module for its ability to grab rotational information while the CPU sleeps would be useful.
Once it has this information, display it on low power LCD screen and save it to FRAM blocks for later downloading to computer, possibly via radio module. No radio for normal operation, radio module also contains a battery. Plug the radio module into the bike and it detects the external power and radio, and contacts a home base unit attached to a computer.
Possible bonus features include a second sensor on the crankset, and shifting suggestions similar to project #1.
Alternatively a battery+SD card for data transfer, done more or less the same way.
I'm not positive that enough power can be generated this way, if not then I'll use a more classic power method, but the ESI and FRAM low power abilities will still be useful. Solar maybe, with a small rechargeable backup battery. Most bike riding is done during daytime after all.
 
Possible project number three:  Digital tach/speedo/intelligent shift light, with advanced fuel consumption monitoring.
Same as project #1, but put the ESI on injector monitoring duties (start timer on injector fire leading edge, stop on trailing edge, calculate fuel injected based on time) and calculate instant and average fuel consumption. Display current MPG, average MPG, cruise MPG and town MPG (buttons to switch between display modes are now needed).
Ideally run some calculations internally with some learning ability, to allow the MCU to suggest cruise speeds/gears for better mileage.
Also a route mode. Push "start" button, drive to where you're going, push "end". Display tells you both MPG and how much fuel you actually used. This can be used to figure out what the most efficient routes from point A to point B are, as MPG does not tell the whole story (20 miles at 30mpg, is worse than 10 miles at 20mpg, for an extreme, but not unreasonable for direct city vs indirect freeway example).
 
#1 is quite doable.
#2 may have power issues, but is doable as well.
#3 is further out there, but something that I would like to do and more importantly has a feature that I've not seen anywhere else.
 
 
 
Will I actually do any of these if I win? I plan to do them anyway. Free parts help, though.
Are the FR6989 chips necessary? Not really, a FR5969 would work just as well, or a LM4C for the automotive ideas. Considering that I can't find a place to buy fewer than 1000 FR6989 chips, I'll either be getting by with free samples or using a different MCU. Certainly don't have $4500 to throw down on 1k FR6989s, that'd be overkill even for me.
Will I blog/log about the project(s)? Definitely.

Got my strip and played with this a bit. It works great!
Here's all 60 LEDs in my one meter strip with flowing colors. Max duty cycle is limited to 40, partly because these things are quite bright and partly because at full burn the strip eats ~1.2 amps and my regulator starts getting rather toasty. The LEDs are supplied with 5v (actually 4.5v after the LDO after coming out the USB3 port) from a seperate power board, the MSP430G2553 is on a standard Launchpad.
 

#include <WS2811Driver.h> byte leds0[180]; WS2811Driver ledStrip; // uses P1_7 as datapin connect to DIN on strip void setup(void) { ledStrip.setLEDCount(60); // setup for 60 leds on a strip ledStrip.begin(); // configure P1.7 for output for (byte x = 0 ; x < 180 ; x++){ leds0[x] = 0; } } void loop() { for(byte x = 179; x >= 5 ; x--){ leds0[x] = leds0[x-3]; leds0[x-1] = leds0[x-4]; leds0[x-2] = leds0[x-5]; } leds0[0] = random(0,random(10,40)); leds0[1] = random(0,random(10,40)); leds0[2] = random(0,random(10,40)); ledStrip.write(leds0); // write to the LEDs delay(100); }
 
Thanks for the library! It made this FAR easier!

You need to drive pin 5 HIGH, not just set it to OUTPUT.

It seemed high to me too, it's on the high end of normal, but within the normal range.
Under ~30PSI is frowned on, most systems aim for 40-60. There's some more data here: http://www.cpuc.ca.gov/NR/rdonlyres/A172EAE5-8520-468E-85D8-67E9BA3FC984/0/WaterSupplyRequirements.pdf page 7 gives some example numbers.
 
If the generator is on the nozzle side of the valves rather than the mains side of the valves you're absolutely correct, it'll never see anything close.
I was thinking of using it on the mains side of the valves, not sure why.

Check your water pressure first, it says it's rated for ~79PSI maximum and ~65PSI normal operating. That may be plenty, but my house is in the lowlands and runs 68-73PSI, pretty close to the maximum.
 
Other than that it looks perfect, tons of current, plenty of volts.

Minor update, did some very preliminary work on getting a FRx9x9 (currently, 5969) set up and timers running for pulse width counting / display update intervals / etc.
These things are far more complicated internally than the 2553s, that's for sure. It's been a bit of a headache, but I'm making headway.
It doesn't help that I've been almost entirely using Energia up to this point. Using CCS-level code inside Energia is all well and good, but Energia still takes care of all the basic setup, so I've had to figure out how to get all that going.
I think I've gotten most of it at least.
 
I start a new job on Monday, so things may go slowly. I really want to have this for my car (as I think I mentioned, my car has no tach at all, which frustrates me), so it will get done!

Minor update, did some very preliminary work on getting a FRx9x9 (currently, 5969) set up and timers running for pulse width counting / display update intervals / etc.
These things are far more complicated internally than the 2553s, that's for sure. It's been a bit of a headache, but I'm making headway.
It doesn't help that I've been almost entirely using Energia up to this point. Using CCS-level code inside Energia is all well and good, but Energia still takes care of all the basic setup, so I've had to figure out how to get all that going.
I think I've gotten most of it at least.
 
I start a new job on Monday, so things may go slowly. I really want to have this for my car (as I think I mentioned, my car has no tach at all, which frustrates me), so it will get done!

NEW FEATURE folks will want to be aware of!
 
For msp430 and lm4f (Tiva/Stellaris), there are three new ways to pause or halt the CPU-
 
void sleep(uint32_t milliseconds);
void sleepSeconds(uint32_t seconds);
void suspend();
 
and a complementary function: wakeup()
 
For the lm4f/tm4c platform, these are mostly just placeholders that do not consume any less power than usual; in the future I'd like to explore the ARM's low-power features to make them workable.
 
For msp430 though, the first two use LPM3 modes, and the third enters LPM4.
Energia tests XT1 osc. fault on reset to see if a 32.768KHz XTAL is present; if so, ACLK is set to that and it's noted that ACLK is being driven at 32.768KHz.  If not, VLOCLK is used and its nominal frequency is assumed to be its speed.
 
When sleep() is called, the WDT is reworked to fire every ~1.9ms (varies XT1 vs VLO) using WDT_ADLY_1_9 while incrementing millis() and micros() as accurately as it can (which isn't always accurate... particularly with VLOCLK).  Alas, it does give you true LPM3 mode!
 
sleepSeconds() uses WDT_ADLY_250, which is a much more coarse sleep interval but allows the chip to spend a whole lot more time asleep.
 
suspend() just runs LPM4.
 
The catch here is that normally IRQs firing won't wake up the chip permanently, and since Energia occupies the ISRs with its own routines, it's not possible for a user's ISR (registered via attachInterrupt() or similar) to run __bic_SR_register_on_exit to cancel the LPM mode.
 
Enter wakeup().  The wakeup() function sets a volatile global flag which signals to the sleep(), sleepSeconds() or suspend() function that sleep mode should be aborted.  Moreover, many of the ISRs have been reworked to check for a change in this flag after it executes the user's ISR in order to determine if it should run __bic_SR_register_on_exit(LPM4_bits) itself.  This allows the user's ISR to cancel LPM mode.
 
These functions (sleep(), sleepSeconds(), suspend() and wakeup()) also exist on the lm4f/tm4c platform, they just don't use any particularly low-power modes yet.  But still, the code should port over, and it does give you as a programmer a simple way to "halt" the CPU or pause with the option of aborting it early.
 
Also note, LPM3/LPM4 will cause any Serial input to be corrupt, since the SMCLK isn't running for the UART module to correctly detect the bits.  This isn't the case for the Tiva/Stellaris yet, but will be once we implement true low power modes over there.
 
The wakeup() handler has been added to the I2C ISR handler too, so it is (in theory) possible to configure the chip as an I2C slave with the Wire library and then suspend() to enter LPM4, then wakeup() upon receiving a request, since I2C is clocked externally.  (I haven't actually tested this yet...)
 
I never got around to adding these functions to the cc3200 port, but will do so by the next release (or maybe offer a patch for it in between).
(I just added the suspend() and wakeup() stuff, all props go to @@energia for the sleep/sleepSeconds/ACLK implementation )

Another thing I discovered, not about Energia but noteworthy for folks using the new CC3200 - ADC inputs are measured against a 1.46V reference, the analog input buffers are only supposedly tolerant up to 1.8V.  That could be a problem if you have some 3.3V-level analog inputs.
 
This doesn't seem to apply with digital I/O mode for these pins, but as the datasheet cautions, having the digital I/O output buffers enabled & set high while the ADC mode is configured for the pin could cause the MCU to blow up its own ADC buffers.  Since Energia uses the CC3200 driverlib I assume there's no risk of that here...

I am happy to announce that release 0101E0013 just went up on http://energia.nu. This release adds support for the awesome CC3200 WiFi LaunchPad and CC3100 BoosterPack for MSP430 and TivaC.
 
I want to thank everybody for their support and contributions. Energia would not have been possible without such an awesome community!
 
Details of the release can be found on http://energia.nu

Cool project. I've been eyeballing water consumption monitoring as a project I want to try sometime, so I'll definitely be watching this!
 
On the electrical side there will probably be enough space and free processing power on the MCU that sits in the electrical box (or on the wiring) with the sensors to chew on the data and spit out either a hall effect style "tick" every X watt/seconds (watt/minutes, watt/hours, whatever your units end up being), or send a packet every X seconds saying that Y watt/whatevers have been used. That would leave the ESI bits on the base station free to deal with the water sensors.
My basic thought process is that anything that can run a radio should be able to turn even a basic amps/volts over time sine wave into a digitally storeable / transmittable number in the ~16ms period a 60Hz sine wave gives you. Monitor one full cycle, spend the next cycle calculating, send the data off every 60 cycles. Something like that.
 
I'd love to see water sensors powered by water flow.

Everybody has probably already come across these, but just in case, TI has reference designs for several sensor solutions using ESI:
http://www.ti.com/product/MSP430FR6989/toolssoftware#TIDesigns

Recently there was a contest for applications using TI's ESI hardware rotation/flow sensing peripheral, I was one of the winners of that. Actually TI did a pretty cool thing and gave the prize (target board and programmer) to everybody who entered rather than just their favorite five. Go TI!
In any event, here is product pitch I submitted:
 
 
 
I also submitted a more advanced version that ties into the fuel injectors and computes instant and average mileage, but I may or may not get to that in a reasonable time period.
 
This is my project thread for this project, if you hadn't guessed.
I'll be updating this first post as progress continues, as well as making more posts in the thread.
I welcome any/all input, feature ideas, suggestions, comments, etc.
 
I'm hoping to begin work on prototype code later today, I'll probably start off using a MSP430G2553 rather than a FRAM w/ESI chip, as I'd much rather blow up a $2.70 chip than a $25 launchpad or a FRAM MCU that isn't available for sale yet. I do have a FR5969 launchpad, which has the ESI bits in it as well, that will go into use once I make sure the inputs are at the voltage(s) I think they are.
 
 

I don't think the FR5969 has ESI fyi ... just the FR6989 or whatever.  The header files (grepping/searching for MSP430_HAS_) elucidates this.

Recently there was a contest for applications using TI's ESI hardware rotation/flow sensing peripheral, I was one of the winners of that. Actually TI did a pretty cool thing and gave the prize (target board and programmer) to everybody who entered rather than just their favorite five. Go TI!
In any event, here is product pitch I submitted:
 
 
 
I also submitted a more advanced version that ties into the fuel injectors and computes instant and average mileage, but I may or may not get to that in a reasonable time period.
 
This is my project thread for this project, if you hadn't guessed.
I'll be updating this first post as progress continues, as well as making more posts in the thread.
I welcome any/all input, feature ideas, suggestions, comments, etc.
 
I'm hoping to begin work on prototype code later today, I'll probably start off using a MSP430G2553 rather than a FRAM w/ESI chip, as I'd much rather blow up a $2.70 chip than a $25 launchpad or a FRAM MCU that isn't available for sale yet. I do have a FR5969 launchpad, which has the ESI bits in it as well, that will go into use once I make sure the inputs are at the voltage(s) I think they are.