spirilis

Here's a simple custom tokenizer that modifies data in-place (I wrote this in C for execution at the command line in Linux, but, the code can be ripped into an MCU just the same):
#include <stdio.h> #include <stdint.h> #include <sys/types.h> #include <string.h> void run_callback(const char *, const char *); int main(int argc, char *argv[]) { size_t i; char text[] = "cmd=load&color=red&bg=blueα=0.56"; size_t tlen = strlen(text); char *key=NULL, *value=NULL; for (i=0; i < tlen; i++) { if (text[i] == '&') { // end of key/value pair text[i] = '\0'; if (key != NULL) { run_callback(key, value); } key = NULL; value = NULL; continue; } if (text[i] == '=') { // end of key, start of value text[i] = '\0'; value = &text[i+1]; continue; } if (key == NULL) { key = &text[i]; } // otherwise do nothing, keep incrementing i } // end of string, we might have a loaded key/value pair to process at the very end if (key != NULL) { run_callback(key, value); } return(0); } void run_callback(const char *key, const char *value) { // do something with key & value - replace these with something more relevant to your application if (key == NULL || value == NULL) { printf("key=ptr[%p], value=ptr[%p]\n", key, value); } else { printf("key=[%s], value=[%s]\n", key, value); } } If it's absolutely mandatory that the original text NOT be modified (you should qualify this restriction though, since if it can be modified, this solution works fine), you can modify this tokenizer to copy the key & value into buffers:
#include <stdio.h> #include <stdint.h> #include <sys/types.h> #include <string.h> void run_callback(const char *, const char *); #define KEYVALUE_BUFFER_MAXLEN 32 int main(int argc, char *argv[]) { size_t i; char text[] = "cmd=load&color=red&bg=blueα=0.56"; size_t tlen = strlen(text); char *key=NULL, *value=NULL; size_t keystart=0, valuestart=0, tmpsz; char keybuf[KEYVALUE_BUFFER_MAXLEN], valuebuf[KEYVALUE_BUFFER_MAXLEN]; for (i=0; i < tlen; i++) { if (text[i] == '&') { // end of key/value pair // copy value into buffer tmpsz = i-valuestart; if (tmpsz > KEYVALUE_BUFFER_MAXLEN-1) { tmpsz = KEYVALUE_BUFFER_MAXLEN - 1; // minus 1 to provide space for the '\0' terminator } memcpy(valuebuf, value, tmpsz); valuebuf[tmpsz] = '\0'; if (key != NULL) { run_callback(keybuf, valuebuf); } key = NULL; value = NULL; continue; } if (text[i] == '=') { // end of key, start of value // copy key into buffer tmpsz = i-keystart; if (tmpsz > KEYVALUE_BUFFER_MAXLEN-1) { tmpsz = KEYVALUE_BUFFER_MAXLEN - 1; } memcpy(keybuf, key, tmpsz); keybuf[tmpsz] = '\0'; value = &text[i+1]; valuestart = i+1; continue; } if (key == NULL) { key = &text[i]; keystart = i; } // otherwise do nothing, keep incrementing i } // end of string, we might have a loaded key/value pair to process at the very end if (key != NULL) { // copy value into buffer tmpsz = i-valuestart; if (tmpsz > KEYVALUE_BUFFER_MAXLEN-1) { tmpsz = KEYVALUE_BUFFER_MAXLEN - 1; } memcpy(valuebuf, value, tmpsz); valuebuf[tmpsz] = '\0'; run_callback(keybuf, valuebuf); } return(0); } void run_callback(const char *key, const char *value) { // do something with key & value - replace these with something more relevant to your application if (key == NULL || value == NULL) { printf("key=ptr[%p], value=ptr[%p]\n", key, value); } else { printf("key=[%s], value=[%s]\n", key, value); } } Note the cost here .... extra code.  Being able to modify the data in-place tidies things up a bit.  What I wrote up above could be reworked to use strtok, but I don't see much point since replicating strtok's code is reasonably compact anyhow (and we're doing a purpose-built version that acts as a state machine unique to your particular data).

I programmed the following into a MSP-EXP432P401R LaunchPad with Energia V17
void setup(){   pinMode(RED_LED, OUTPUT); } void loop(){   float f;   digitalWrite(RED_LED, HIGH);   for(f = 0; f < 720; f = f + 0.0001){     sin(f);   }   digitalWrite(RED_LED, LOW);   delay(3000); } So it wastes time in a loop doing floating point and burning the red LED for a couple of seconds. Then it goes into a 3 second delay.

Then I unplugged it, and removed the 3.3V and 5V isolation jumpers between the emulator side of the LaunchPad and the MSP432. I used another LaunchPad to power the MSP432 LaunchPad from the 3.3V and GND pins on the MSP432 side with a 1.5 ohm (measured) resistor in the middle. Then I read the voltage drop across the 1.5 ohm resistor with my cheap DMM as the program ran.

The results are as follows:

When it is not in the delay and the LED is on I read 18.3 mV. So, current is 18.3/1.5 = 12.2 mA. The MSP432 uses 90 uA per MHz when active per the datasheet or 4.3 mA at 48 MHz. The LED is probably using around 10 mA, so in the ballpark.

This arrangement can't see any voltage drop when the delay is on and the LED goes off (less than a mA). I put it on my oscilloscope and see essentially the same thing. So something about your arrangement or measurement seems to be off.
 
EDIT: Reposted the Energia code so that it can be read.  Also, to clarify, it looks from my experiment that delay() does put the MSP432 into LPM on the LaunchPad.  When you figure out why you are getting different results, let us know.

Ok:
#include <wiring_private.h> void setup() { // put your setup code here, to run once: pinMode(PF_0, OUTPUT); } void loop() { // put your main code here, to run repeatedly: PWMWrite(PF_0, 256, 200, 15000); while(1) delay(100); } Saleae Logic16 shows a waveform with width=52.1uS, period=66.68uS, frequency = 14.997KHz.  Pretty close.  52.1/66.68 = 0.781343, 256*0.781343 = 200.02 so that looks right.
 
Running this:
#include <wiring_private.h> void setup() { // put your setup code here, to run once: pinMode(PF_0, OUTPUT); } void loop() { // put your main code here, to run repeatedly: PWMWrite(PF_0, 256, 200, 15000); delay(100); } ...produces ALMOST the same thing, but every 100ms there's a single pulse whose width is 101.65uS instead of the typical 52.1uS.
 
Running this:
#include <wiring_private.h> void setup() { // put your setup code here, to run once: pinMode(PF_0, OUTPUT); } void loop() { // put your main code here, to run repeatedly: PWMWrite(PF_0, 256, 200, 15000); } Produces no waveform at all; the signal goes HIGH after Energia starts and then stays there with no transitions.

https://education.ti.com/en/us/products/micro-controller/ti-innovator/tabs/overview

A new dev kit with RGB LED, light sensor, talks to TI calculators, and a nice enclosure!
 
Available Fall 2016

I've managed a few. Swapping VCC and VSS on my first etched PCB was a good one. I'm glad I'm not the only one who's done that.
 
I also noticed that a TS430RGC64USB target board that I had supported the F5510 that I was coding for. Great! So I stuck it in and wondered why it didn't work. It turns out that a LQFP48 will fit in a QFN64 socket. It might not fit that well or work, but it goes in.
 
Amazingly neither of these (and probably worse that I've forgotten) damaged the MSP430.

Got an email yesterday about some deals TI is offering this week. The MSP432 launchpad is selling by USD 4.32 again, plus some other cool stuff.
 
I am tempted by a CC3200 LP, but I think I have to stop kidding myself and do something with the stack of LP's I already have before buying more...
 
http://www.ti.com/corp-tistore-null-engineersweek2016-bhp-lp-null-wwe

Found a nice app note by TI, and wrote some thoughts on it:
 
Just recently read an app note that targets your same circumstances. Using power solutions to extend battery life in MSP430 applications By TI's Michael Day. While it uses the MSP430 as its target, the same applies to any MCU.
 
Depending on the MCU's Current vs Voltage, and Voltage vs Clock Speed, using an LDO with a low Quiescent Current will be much better than powering the MCU directly off the battery. The example uses 2x AA, and a TPS780xx regulator with 0.5

The idea is that when you check "use external editor" you are no longer able to edit the Sketch in Energia. You then open the .ino in say notepad++ and edit the Sketch. When you hit "Verify" button in Energia, you will see that the content in Energia changes to match the changed you did in the external editor.

I think @@energia caught this bug a while back but the fix isn't in the latest Energia release.  It was a test routine that's superfluous IIRC.

Dear TI geeks,
 
Ulrich Hoffman found a bug while using multitasking in Mecrisp-Stellaris on TM4C1294, which, after a long search, could be tracked down and turned out to be a silicon bug. I wish to share this with you, just in case you run into similiar trouble.
 
Matthias
 
 
  LDMIA and some other opcodes with a register list can be interrupted and
  continued afterwards in M3 and M4 cores.

  Unfortunately, there seems to be a silicon bug in some chips / core revisions
  that causes an interrupted LDMIA opcode to fail.

  The error has already been observed in LM4F120, TM4C1294, STM32F407
  when using the multitasking example. M0 chips and EFM32GG990 are fine.

  It could affect other M4 chips and maybe M3, too.

  So if you get mysterious crashes when using Interrupts on M3/M4,
  try disabling preemption capabilities with this workaround:

  1 $E000E008 !

  Drawback is that this increases interrupt latency.

  Manual snipplets:

  B1.5.10 Exceptions in LDM and STM operations

       In order to allow implementations to have the best possible interrupt response, an interrupt can be taken
       during an LDM or STM and continued after the return from the interrupt. The continuation state of the LDM or
       STM is held in the ICI bits in the EPSR (see The special-purpose program status registers (xPSR) on
       page B1-8). It is IMPLEMENTATION DEFINED when interrupts are recognized, so the use of the ICI bits is
       IMPLEMENTATION DEFINED.
       The ARMv7-M architecture supports continuation of, or restarting from the beginning, an abandoned LDM
       or STM instruction as outlined below. Where an LDM or STM is abandoned and restarted (ICI bits are not
       supported), the instructions should not be used with volatile memory. To support instruction replay, the LDM,
       STM, PUSH and POP instructions are required to restore/maintain the base register when a fault occurs (no base
       register writeback update) during execution.

  M3: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0552a/CHDCBHEE.html
  M4: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0553a/CHDCBHEE.html
 
  Address     Name   Type  Required privilege  Reset value  Description
  0xE000E008  ACTLR  RW    Privileged          0x00000000   Auxiliary Control Register

  Auxiliary Control Register

  [0]    DISMCYCINT     Disables interruption of multi-cycle instructions.
         This increases the interrupt latency of the processor because load/store and
         multiply/divide operations complete before interrupt stacking occurs.

  M7: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0646b/CHDCBHEE.html
  Does not have this bit.
 

For those interested, I also have a pretty cool (if I must say so myself...) Processing <-> "Arduino/Energia" library on GitHub: https://github.com/sopgenorth/MSOE_ROV_2015 . It communicates a set of variables to/from the two devices over UDP, and is pretty easy to use and get going. 

Thanks for the starting point there. The calls to Swupdate don't seem to be working since the LM Flash Utility still hangs on the "trying to connect". Starting the MAC/PHY with the "SoftwareUpdateInit()" function, my callback function is called as expected. I get the same behavior with the Energia UDP/Ethernet libraries where I can see the "magic update packet". 
 
I suspect that the issue is that I don't have the proper Ethernet Bootloader installed, but can't seem to find any information on how to install/build it. Any idea how I can install the Ethernet Bootloader/include it in my projects?
 
 
Comment block from SoftwareUpdateBegin():
 
//*****************************************************************************
//
//! Passes control to the bootloader and initiates a remote software update
//! over Ethernet.
//!
//! This function passes control to the bootloader and initiates an update of
//! the main application firmware image via BOOTP across Ethernet.  This
//! function may only be used on parts supporting Ethernet and in cases where
//! the Ethernet boot loader is in use alongside the main application image.
//! It must not be called in interrupt context.
//!
//! Applications wishing to make use of this function must be built to
//! operate with the bootloader.  If this function is called on a system
//! which does not include the bootloader, the results are unpredictable.
//!
//! \note It is not safe to call this function from within the callback
//! provided on the initial call to SoftwareUpdateInit().  The application
//! must use the callback to signal a pending update (assuming the update is to
//! be permitted) to some other code running in a non-interrupt context.
//!
//! \return Never returns.
 
EDIT:
 
I got the Ethernet update to work by making a few modifications to the SwUpdate.c file. For whatever reason (I didn't really bother looking into this part...), the defines aren't set to use the ROM based Ethernet bootloader in the SoftwareUpdateBegin function, and the ROM Ethernet functions aren't defined in Energia 017's "rom.h" file. The latest version of TivaWare (TivaWare_C_Series-2.1.2.111) does provide the proper definitions for it. I simply added the necessary defines to call the ROM_UpdateEMAC and forced the code to use that, instead of the flash bootloader based update system. It also seems to be important that the MAC address set by the Ethernet library matches the MAC address programmed into user registers (by default this is what is on the sticker on the board).
 
Anyways, I've attached a working Energia example with support for updates over Ethernet. 
EthSwupdate.zip

Hi @@spirilis
thank you very much for your help. Today when I restarted looking at the problem after work, strangely everything worked with the F5529, I didn't change any code or upload the program, so it's a bit of a mystery as to why it wasn't working yesterday, maybe the adc was stuck in reset for some strange reason?
 
I connected 2 V to the first differential pair of inputs and went into continuous acquisition mode (-> t -> 8) and got the expected result:
528090 -1.970356 0.004046 -0.001466 0.000032 0.000062 -0.000001 0.007246 -0.005542 528113 -1.968118 0.000920 -0.000300 -0.000445 0.000017 -0.000172 -0.000202 0.000260 528135 -1.909522 -0.000111 0.000010 0.007555 -0.008118 -0.000058 -0.000406 0.000018 528157 -1.964004 -0.000027 -0.000020 0.001926 -0.004517 0.000055 0.003017 -0.000562 528180 -1.962540 0.004390 -0.000310 -0.000463 0.000017 0.000001 0.006405 -0.000039 528202 -1.944292 0.000204 -0.000108 0.000015 0.000408 -0.000148 -0.000106 0.000029 528224 -1.985303 -0.000022 -0.000022 0.002268 -0.001038 -0.000189 -0.000210 0.000058 528246 -1.959754 0.000209 0.000307 -0.002600 -0.000274 0.000928 0.000506 -0.000055 528269 -1.909710 0.007601 -0.000086 0.000000 0.000322 0.007256 -0.007181 0.000065 528291 -1.991854 0.015968 -0.000342 0.000013 0.000016 -0.000230 0.000001 0.000121 528313 -1.991457 0.000289 0.001266 -0.005775 -0.000045 -0.000485 -0.000028 0.000108 528336 -1.884752 -0.000025 0.005335 -0.009485 0.000186 0.006303 -0.002317 0.000064 528358 -1.942423 -0.000205 -0.000521 0.000004 0.000016 0.009694 -0.001051 -0.000129 528380 -1.991979 -0.000029 -0.000215 0.000301 0.000619 -0.000118 -0.000002 0.000814 not too bad for the flying lead connections and Vref set to AVCC (which is 5.000 V from a rigol dp832 via long leads).
 
So the next steps are now to look into the fast USB mode and then to design a pcb with the adc and some amplification between the MUXOUT and the ADCIN.
 
Thank you very much for your help! I'll tidy the code up some, and will put the newest version back up on github in the next few days.
 

Getting much closer then!  Now the question is why DRDY never gets asserted after init... if I'm reading that right, DRDY is always HIGH?

This is the first PCB that I have designed and sent off to be manufactured.  Yesterday I received the boards, soldered them up, and they work!

This write-up outlines the process I used in the hope that it will be useful to other hobbyists and builders.  There are links at the end which provide additional detail. 
 
Selecting a Project
The project consists of a small board with a MSP430G2553 microcontroller and an nRF24L01 radio.  I started with a radio attached with jumpers to a LaunchPad quite some time back and then built one on a proto-board.  The photograph below shows a G2553 with radio powered by a buck-boost converter attached to a super capacitor and solar panel.  I used it for a while with my weather station which never was quite completed.

Although I could have started with that, I actually chose to start with something simpler.  The goal was to focus on the PCB design process and to minimize the issues associated with a new or technically challenging project.  The objectives, strategies, and constraints I decided on included the following:
Inexpensive

Try the attached Sketch as a starting point. I only made it compile you will need to fill in the setup/loop portion.
 
 
EthSwupdate.zip

So I'm assuming it's hanging on waitforDRDY?  What state is DRDY in when you test it?
Keep in mind, if DRDY is low when attachInterrupt() runs, I don't think the interrupt will fire - it only triggers on FALLING conditions, not "level" conditions.
 
In ads12xx::begin, after your attachInterrupt function call, I would do something like:
 
DRDY_state = digitalRead(_DRDY);
 
just to "set" the right initial condition.  Also be sure attachInterrupt is modified to use _DRDY instead of the hardcoded '2' you have in the github file: https://github.com/baettigp/ADS12xx-Library/blob/master/ads12xx.cpp (since you have changed the DRDY pin to something that is interrupt capable)

Nope - pin#2 in Energia on the F5529 is P6.5, and only P1, P2 are interrupt capable.  P6.5 is P6.
 
Take a look at the pin maps page for F5529 - http://energia.nu/pin-maps/guide_msp430f5529launchpad/ - and select an unused pin assigned to P1.x or P2.x

So I'm assuming it's hanging on waitforDRDY?  What state is DRDY in when you test it?
Keep in mind, if DRDY is low when attachInterrupt() runs, I don't think the interrupt will fire - it only triggers on FALLING conditions, not "level" conditions.
 
In ads12xx::begin, after your attachInterrupt function call, I would do something like:
 
DRDY_state = digitalRead(_DRDY);
 
just to "set" the right initial condition.  Also be sure attachInterrupt is modified to use _DRDY instead of the hardcoded '2' you have in the github file: https://github.com/baettigp/ADS12xx-Library/blob/master/ads12xx.cpp (since you have changed the DRDY pin to something that is interrupt capable)

Nope - pin#2 in Energia on the F5529 is P6.5, and only P1, P2 are interrupt capable.  P6.5 is P6.
 
Take a look at the pin maps page for F5529 - http://energia.nu/pin-maps/guide_msp430f5529launchpad/ - and select an unused pin assigned to P1.x or P2.x

It's .sslConnect, not .connect to do SSL.
 
Another user was having trouble connecting to Azure Event Hub with .sslConnect BTW.  I was able to confirm this behavior but still have no idea why it's happening.  Probably requires a deep dive that I don't have time to do (i.e. spin myself up on what Microsoft's SSL restrictions might be, what the CC3100/3200 supports, etc...)

My two cents...
 
The sleep, sleepSeconds, suspend() function calls should perform the analogous functions with the CC3200 Cortex-M4 MCU, but have hooks in addition to activate a WiFi library "sleep" mode which is configurable.
 
Perhaps something like WiFi.setSleepMode(...) with an option:
 
WIFI_SLEEP_ONLINE
WIFI_SLEEP_OFFLINE
WIFI_SLEEP_HIBERNATE
 
The sleep, sleepSeconds, suspend functions should check a public boolean of some type in the WiFi library indicating whether it's even in use (no point in bothering with it if the user isn't using the WiFi at all), then run a WiFi.sleep(boolean) function that acts based on the current setting.  I would say the "default" setting should be WIFI_SLEEP_ONLINE (#1 in your options above).
 
As a side benefit, the user can run WiFi.sleep(boolean) by themselves if they don't intend to put the Cortex-M4 MCU in deep sleep mode at the same time.  The idea would be to run WiFi.sleep(true) when they expect the NWP to go out to lunch, then WiFi.sleep(false) to wake it up.
 
Just a rough idea... would like to hear others' input!  @@bluehash Any way you could make a 43oh blog post with a "call for questions" pointing here?
 
On Hibernate mode...
Hibernate erases all memories inside the CC3100 NWP, so the WiFi.sleep(false) would probably have to run WiFi.begin() before it exits if WIFI_SLEEP_HIBERNATE were the selected mode.  But the user would have to know that they need to re-establish the WiFi link with their AP and obtain IP address/etc anew.
 
Actually I wonder if there is much functional difference between Hibernate and the NWP LPDS (your #2 option).

Yes, that's the one. I had it in my original post that got lost and forgot to include it in the post below.
Also forgot to mention that I have both scenario's prototyped and the work pretty great but need to be properly fitted into API's.

My two cents...
 
The sleep, sleepSeconds, suspend() function calls should perform the analogous functions with the CC3200 Cortex-M4 MCU, but have hooks in addition to activate a WiFi library "sleep" mode which is configurable.
 
Perhaps something like WiFi.setSleepMode(...) with an option:
 
WIFI_SLEEP_ONLINE
WIFI_SLEEP_OFFLINE
WIFI_SLEEP_HIBERNATE
 
The sleep, sleepSeconds, suspend functions should check a public boolean of some type in the WiFi library indicating whether it's even in use (no point in bothering with it if the user isn't using the WiFi at all), then run a WiFi.sleep(boolean) function that acts based on the current setting.  I would say the "default" setting should be WIFI_SLEEP_ONLINE (#1 in your options above).
 
As a side benefit, the user can run WiFi.sleep(boolean) by themselves if they don't intend to put the Cortex-M4 MCU in deep sleep mode at the same time.  The idea would be to run WiFi.sleep(true) when they expect the NWP to go out to lunch, then WiFi.sleep(false) to wake it up.
 
Just a rough idea... would like to hear others' input!  @@bluehash Any way you could make a 43oh blog post with a "call for questions" pointing here?
 
On Hibernate mode...
Hibernate erases all memories inside the CC3100 NWP, so the WiFi.sleep(false) would probably have to run WiFi.begin() before it exits if WIFI_SLEEP_HIBERNATE were the selected mode.  But the user would have to know that they need to re-establish the WiFi link with their AP and obtain IP address/etc anew.
 
Actually I wonder if there is much functional difference between Hibernate and the NWP LPDS (your #2 option).

This is the CC3200 low power management document right?  http://www.ti.com/lit/swra462