Fred

2N7000

A command parser/dispatcher example from my CO2 laser engraver codebase, using a struct array containing the commands and associated  pointer to functions. A lot cleaner (and easier to maintain) than switch/case statements or if/else constructs...
Functions get called with a pointer to the command tail for local parameter parsing.
The struct array data are all placed in flash.
typedef struct { char const *const command; bool (*const handler)(char *); const bool report; } command; bool query (char* params); bool start (char* params); bool moveXrel (char* params); bool moveYrel (char* params); bool moveZrel (char* params); bool XHome (char* params); bool YHome (char* params); bool ZHome (char* params); bool XYHome (char* params); bool zeroAllAxes (char* params); bool laser (char* params); bool setLaserPower (char* params); bool setImageDPI (char* params); bool setPulseDutyCycle (char* params); bool enableCoolant (char* params); bool enableAirAssist (char* params); bool setMode (char* params); bool getPosition (char* params); bool setPPI (char* params); bool setPulseWidth (char* params); bool enableExhaustFan (char* params); bool setEngravingSpeed (char* params); bool getStatus (char* params); bool setEchoMode (char* params); bool setAMode (char* params); bool setPWROffset (char* params); bool loadProfile (char* params); bool setXBcomp (char* params); void exeCommand (char *cmdline) { static const command commands[] = { "?", &query, true, "Power:", &setLaserPower, true, "DutyCycle:", &setPulseDutyCycle, true, "PulseWidth:", &setPulseWidth, true, "DPI:", &setImageDPI, true, "Start:", &start, true, "X:", &moveXrel, true, "Y:", &moveYrel, true, "Z:", &moveZrel, true, "HomeXY", &XYHome, true, "HomeX", &XHome, true, "HomeY", &YHome, true, "HomeZ", &ZHome, true, "ZeroAll", &zeroAllAxes, true, "Laser:", &laser, true, "Coolant:", &enableCoolant, true, "Air:", &enableAirAssist, true, "Mach3:", &setMode, true, "Pos", &getPosition, false, "PPI:", &setPPI, true, "Exhaust:", &enableExhaustFan, true, "Speed:", &setEngravingSpeed, true, "Status", &getStatus, false, "ASelect:", &setAMode, true, "PWROffset:", &setPWROffset, true, "LoadProfile:", &loadProfile, true, "XBComp:", &setXBcomp, true, "Echo:", &setEchoMode, false }; bool ok = false; uint32_t i = 0, numcmds = sizeof(commands) / sizeof(command), cmdlen; while(!ok && i < numcmds) { cmdlen = strlen(commands[i].command); if(!(ok = !strncmp(commands[i].command, cmdline, cmdlen))) i++; } if(ok) { ok = commands[i].handler(cmdline + cmdlen); if(commands[i].report) serialWriteLn(ok ? "OK" : "FAILED")); } else serialWriteLn("Bad command"); } For further reading see http://www.barrgroup.com/Embedded-Systems/How-To/C-Function-Pointers
 
 
 

I'd suggest taking a look at the schematic of the G2 Launchpad. There's no magic going on.
 
Ignore the EMULATOR side. On the side labeled MSP-EXP430G2 there's nothing scary - just a couple of buttons, LEDs, some decoupling capacitors and pull up resistors. I've found that an appropriate Launchpad is a good starting point when designing your own board.

I'd suggest taking a look at the schematic of the G2 Launchpad. There's no magic going on.
 
Ignore the EMULATOR side. On the side labeled MSP-EXP430G2 there's nothing scary - just a couple of buttons, LEDs, some decoupling capacitors and pull up resistors. I've found that an appropriate Launchpad is a good starting point when designing your own board.

I'd suggest taking a look at the schematic of the G2 Launchpad. There's no magic going on.
 
Ignore the EMULATOR side. On the side labeled MSP-EXP430G2 there's nothing scary - just a couple of buttons, LEDs, some decoupling capacitors and pull up resistors. I've found that an appropriate Launchpad is a good starting point when designing your own board.

Things I would do:
Check voltage on VCC and RESET. Bodge on some sort of SBW header. Try to find a place where RESET and TEST are available. Maybe solder some temporary wires on the bottom of the IC socket's pins. Check the obvious again - continuity to GND, VCC, etc. When you eventually find it, it will probably seem stupid and obvious!  
I believe it's just VCC, ground, RESET pulled high.

@@Rickta59 True. Although above he did say it's not working on the board. I must admit I'm still a little confused as to what @@yyrkoon is asking. A photo will definitely help.

In which case, I'm with the guys who say to add a SBW header. Don't forget the pull up resistor and capacitor. That's the only other thing that the Launchpad part adds to the DIP chip.
 
You will be able to disconnect the jumpers on an unmolested Launchpad and use that for programming and debugging. No need for cutting.

I think there's a really simple solution to this, so the chances are I've misunderstood what your asking!
 
You can physically cut and separate the FET part of a G2 Launchpad from the target device. All you need to do it cut carefully along that dotted line. Leave the target half in your project. Connect them back up for programming and debugging. Test this out by just removing the jumpers before you cut. If you don't feel destructive, just use 2 Launchpads.

Hello All,
Here is some feedback. Apologies on the late reply.
 
There was approximately an hour to field our questions/requests.
On a few questions that were not asked, I have an open channel with them.

Energia
- This was my primary focus. I am aware most of you don't care much about it, but there are alot of users coming in from the Arduino world to the TI family.
A couple of others in the room and myself were concerned about the future of Energia and its support. We were assured that more was being done and we'll know
more in some time.

Higher RAM chips on the value line
- Let them know that higher RAM on the chips shipped with the Launchpad is invaluable. It keeps us from implementing the cooler stuff.

USB on MSP on the lower end devices
- Let them know about it. They are aware about the lack of this feature. From my view, low power and USB do not go hand in hand... it may be a challenge.
EDIT: Just wanted to confirm... that it is my view that USB and low power may be a challenge... not TI's.. They may already have something in the works. I don't know.

MSP432 DMA
- Feedback given. They will take this back to the chip architechts.

Driverlib
- This is becoming mainstream in a lot of their devices and is quite popular. I left this discussion off.

TI EStore International Shipping
I was not able to get to the person incharge of the Store. But they do know of the issue. I'll push this again.

Energy Trace requests
- The team would like a list. I'd suggest someone start with a list in the forum and build up on it.

CCS bugs
- A list would be good. I'll have someone from TI look at it and post it in their CCS forums.

MSP software
- More improvements

Grace
- Something new/revamped.
 
Other comments. They were interested in how we used the TI site, the forums and social media. They were looking for feedback on their datasheets, block diagrams,examples and newsletters. There was also a chat with the calculator group and the TI-Innovator system.

If you have an issue with TI's tools, the best place to put them is in their E2E forums. If it is a long list/request list post it here.
 

I'm really trying not to buy Launchpads when they come out just because they sound cool. I have way too many already, some of which have hardly been used.

Improved homing cycle has led to (near) perfect registration of solder mask.
 

 
Layer registration mark, lines are ~0.1mm wide.
 

 
Part of TSSOP 20 footprint, mask is way past "use before" date so some problems with spots appearing.
 
I have started to apply the Riston film on wet PCBs, dust problem nearly gone - easier to handle.
 
Terje
 

Free shipping at TI Store through 26-JUNE-2016: http://www.ti.com/lsds/ti/store/power-week-deals.page?HQS=corp-tistore-null-powerweek-adh-lp-null-wwe
 
 

WTF is an of-the-shelf IoT gateway anyway? Just an rebranded ordinary router? An edge router for every protocol they thought of - Zigbee, 6LoWPAN over various frequencies, etc.? Sounds like a scary idea.
 
By the way, there's now an OWASP for IoT. Not great but better than nothing. Not sure where I heard about it. Apologies if it was here!
https://www.owasp.org/index.php/OWASP_Internet_of_Things_Project

I'd say the main (perhaps only) reason for making your own PCBs is if you enjoy it. Whilst in theory I could make a board in a couple of hours, it would take me 2 weeks to find those spare hours!

I'd say the main (perhaps only) reason for making your own PCBs is if you enjoy it. Whilst in theory I could make a board in a couple of hours, it would take me 2 weeks to find those spare hours!

I'd say the main (perhaps only) reason for making your own PCBs is if you enjoy it. Whilst in theory I could make a board in a couple of hours, it would take me 2 weeks to find those spare hours!

If you've been set this as coursework then I'd suggest you start with what you've been taught. There are plenty of helpful people here that will be glad to assist if you're stuck on something specific and have tried working it out yourself first. What you won't find are people to do your assignment for you.
 
This assignment has probably been given for a good reason. If someone creates a solution for you that doesn't use any of the principles you've been taught then it'll be fairly obvious and you'll probably fail. Also, 43oh is about the most prominent resource for MSP430 information. Your teacher may well know this and notice if you hand in an assignment someone else did for you here.
 
Good luck with it. Don't be put off asking if you have something you get stuck on.

That also sounds very specific and a bit like it's your coursework.

I've just started playing around with the CC3200 Launchpad as I'm also finding it tricky. I think it's definitely the CC3200 that's difficult as playing with the TM4C1294 Connected Launchpad and TI-RTOS beforehand wasn't too bad.
 
Here are some things I seemed to have to find out the hard way. Please correct me if you know better I've got anything wrong.
 
Flashing with CCS Uniflash
Connect using CC3x Serial (UART) Interface, not Stellaris In-Circuit Debug Interface. The SOP jumper must be set to 2 You must power cycle the whole board if you change the jumper. Not just the reset button. You can set the WLAN profiles in Uniflash. No need to use the "SmartConfig" which I had problems with. Select the profiles tab and check the "Update" box. Enter details for Profile1, etc. /sys/mcuimg.bin is what's run when the board is powered up. Always this. Not the last debug session like on the MSP430 or TM4C.  
Debugging
Remove the SOP jumper if you've been flashing. Power cycle. Not just reset. The dubugger is "Stellaris In-Circuit Debug Interface" UART output is "CC3200LP Dual Port". Sometimes you can't start debugging if this is connected first. You can attach once debugging. Your debug session is temporary. On reset it'll run mcuimg.bin code again. Some examples use SSID defined with "#define SSID_NAME" (e.g. WLAN Station). Some use the config in flash (e.g. httpServer). Beware. Other
Watch that jumper to select station or AP (on P58). Stuff will hang if you set it wrong. There's a new SimpleLink WiFi Starter Pro android app. A bit more usable, but it's still easy to screw up profile settings and get it to misbehave if you flashed anything other than the OOB code. I think I've got my head round it now. Probably. The documentation is there but not easy to find and digest. The TM4C is much easier if you have an ethernet cable nearby though!
 
I have found examples that can be done with FreeRTOS or TI-RTOS. A bit of a pain to tweak things to compile, but if you follow the guides under SDK/docs/example you'll get there.

CC2650 is 2.4GHz. I would assume that OpenThread is independent of the underlying frequency. Not sure why I thought the Nest implementation was using 2.4GHz - probably either a poorly researched article on it or just my assumption.
 
I understand exactly what you mean about it seeming "green". This is the best I've found - a blog by a TI employee but not the easiest to follow. I'm sure he'll do some CC1310 stuff too.
http://sunmaysky.blogspot.co.uk

Recently I took a trip to the US, which offered a good opportunity to test my altitude logger by recording a profile of the whole journey there. The trace revealed some interesting details about the flights I took, and airline operations in general.

Here's the profile for the entire trip:
 

 
The x-axis shows elapsed time in minutes. The altitude is shown in metres, measured relative to the start of the trace (not too far above sea level). Despite that I'll be using feet as the unit of altitude here, since that's the standard used in aviation. Because the logger calculates altitude based on air pressure, it is affected by cabin pressurisation. Instead of recording the true altitude of the aircraft it gives a trace of the effective altitude inside the cabin.

The first big peak at the blue cursor is a flight from Edinburgh to London Heathrow. Comparing the cabin altitude trace against real altitude data makes it easier to pick out the main features, so here's a chart showing this flight's altitude as broadcast over ADS-B:
 

 
And this is a closeup showing what my altitude logger recorded for the same flight:
 

 
The cursors mark where I think the flight started and finished, based on the fact that the plane was in the air for 70 minutes. From takeoff the pressure falls steadily until the effective altitude in the cabin is about 7000ft, at which point the aircraft is actually at 37000ft. After cruising there for 12 minutes the plane descends and cabin pressure steadily increases.

The cabin pressure reaches ground level before the plane actually lands, so the trace stays flat for the next 12 minutes. In fact, this section of the trace is effectively below ground level while the plane approaches landing. The plane's environmental control system has deliberately overshot and pressurised the cabin to higher than ambient pressure at the destination. At the orange cursor marking the end of the flight you can see a slight increase in altitude. This is when the flight is over and the controller opens the pressurisation valve to equalise with the external air pressure.

It seems this extra pressurisation is done before takeoff and landing to help the system maintain a steady pressure. There's a detailed explanation of the reasons for this here: http://aviation.stackexchange.com/questions/16796/why-is-cabin-pressure-increased-above-ambient-pressure-on-the-ground

Now on to the second flight, which was from Heathrow to Dallas Fort Worth. First the ADS-B trace:
 

 
And the altitude logger's version of events:
 

 
Again, the cursors mark the start and end of the flight and line up with the reported duration. The "steps" along the top of the trace match up with changes in cruise altitude from 32000?>34000?>36000ft. Maximum effective cabin altitude is about 5500ft, lower than the first flight even when the lower cruise altitude is taken into account. I think that's down to the use of a newer 777 on the international flight compared to the A319 on the domestic route. Modern planes are increasingly designed to offer lower effective cabin altitudes for passenger comfort.

The stepped flight profile is used to maximise fuel efficiency. Flying higher reduces losses to air resistance, but early in the flight the aircraft is heavy with fuel and climbing is expensive. As the fuel is burned off the optimal cruise altitude increases, so ideally the plane would climb to match. In fact the plane can't climb gradually because modern air traffic control regulations restrict aircraft to set flight levels. The best option under these restrictions is to perform a "step climb" up to a higher level when it's more fuel-efficient than the current one. The flight levels are multiples of 2000ft for flights from the UK to the US, which is why the steps are 32000->34000?>36000ft.

Wrapping up, one of the things I hoped to test by recording this journey was high rates of altitude change. The altitude logger can currently handle rates of change up to

Yeah my understanding was OpenThread was targeting sub-GHz anyhow (CC26xx is 2.4GHz IIRC) 
CC1310 will probably be the platform for OpenThread. I have two of the CC1310 LP's, even they feel a little "green" on the examples and code so far. Seems like an awesome chip so far though. Tiva-like peripherals and all.

Today Hackaday featured someone that replaced the innards of a Casio watch with an MSP430FR6972
http://hackaday.com/2016/05/30/gutting-and-rebuilding-a-classic-watch/

 
Very well documented on GitHub, including more pictures:
https://github.com/carrotIndustries/pluto
 
If the author is on 43oh:

Your comments about a vacuum pickup tool reminded me that I want to build this manual pick and place rig for myself:
 
http://vpapanik.blogspot.ca/2012/11/low-budget-manual-pick-place.html