SixSixSevenSeven

The [extremely sophisticated] benchmarks I have will port easily to MSP432 and STM32L4.  Atmel will be later in the year, but I have low hopes for Atmel, and I might not bother.
 
Warning: Rant ahead.
 
Anyway, Atmel uses more BS in their datasheet and marketing than TI does, and TI uses *slightly* more than ST.  
Atmel's marketing numbers are unrealistic, best case figures where all the peripherals are off, the integral DC-DC is running, the chip is running at 12 MHz only, and it is running specially crafted code from a small region of SRAM.  Practically, it does 100uA/MHz.  Look at the datasheet, it's all there, albeit somewhat hidden.  Moreover, it's CM0+, so you really should multiply all figures by 66% to compare to CM4: 100 --> 166. TI's numbers are more honest.  A benchmark library is running from FLASH, the clock is 48 MHz, peripherals are mostly on, but the DC-DC is running with input 3.0V.  TI provides a great amount of information about what the power figures are when running with LDO, and they are still quite good (~160uA/MHz). ST is running Dhrystone benchmarks with all the peripherals going, clock at 80 MHz, code from flash, 128 KB of SRAM active, and there is no DC-DC on the device, so it's just LDO.  112 uA/MHz.  I have to guess they have implemented a mixed-size process with the core at 65nm, because they are a "quantum" ahead of the TI and Atmel offerings. I do wireless IoT, at "low" frequencies (sub 1-GHz), and with low power.  I tend to shun DC-DC converters because they kick up a lot of noise that does affect my radios (I've measured, it can be seriously bad).  It takes a lot of design time to cut-down the noise of DC-DC converters, and it's not always possible (if you can control the switching frequency in software, it's a whole lot better though).  Moreover, the input voltage limit of MSP432 and SAML21 is 3.7 and 3.6V respectively, so IT'S USELESS. It needs to be 4.3V at least, so we can use Li-Ion.  Otherwise, I need to make my own step-down from the Li-Ion, and I'm inclined to use my own DC-DC, with a totally vetted analog design and low EMI, that feeds 1.8V to my system.
 
I really don't need the M4F, but the truth is that I really do prefer the M3/M4 to the M0+.  M0 is a "red-haired step child."  It doesn't fit into a good standard (it's ARMv6+ vs the gold-standard ARMv7).  Compilers are worse.  It only has 8 registers that can be batched to the stack, whereas all the regs in M3/M4 can be (so threading sucks on M0).  It has a crippled NVIC, and on and on.  Basically, it's a low cost hack.  For low power, you actually do better with M3/M4.  For performance, M3/M4 also.
 
M4F gives the MSP432 (and STM32L4) a really good entry point into sophisticated signal processing apps.  Hell yeah, we're going to do FFT on these things.  I think it is ridiculously cool to do FFT -- fast -- with 4-8 mA.  Not everyone here realizes the kinds of possibilities this opens-up.  You might not think you need FFT, but the best Reed-Solomon algorithm uses FFT, and RS is awesome for error correction and data integrity in lossy IoT networks.  So it's a completely legit thing to talk about.
 
I want to reiterate that I only hate Atmel because they make me hate them by being disingenuous.  If they changed their ways, I would have no issue.  I have "no dog in this fight."
 
Anyway, I can tell you now that any performance difference between MSP432P4 and STM32L4 will almost certainly be outweighed by the difference in the development packages, features, and peripherals.  But I still think it is worth the time to explore all the little things that don't get marketed, which actually do have a huge impact on low-power RTOS functionality.  These will be in the official review, coming sometime in May or June I would guess.

The IRRemote library uses Timer1. The 2231 and 2452 devices do not have a Timer1.

229 little swarm robots

you do need ir.resume() else it won't pick up the new command.
 
You can easily hop back and forth between 2 energia sketches too while you isolate issues.
 
 
I'd actually take a slightly altered approach from your code. Have a variable to store the current mode, in loop() a switch statement executes the right action for each mode (with a stop mode being included). Then when IR data is available, set the mode variable accordingly, if you are in a mode already, switch to the stop mode else go to whichever one the IR command dictates.

I like the addition of a 5v pad on the launchpad. Wasnt entirely needed but its a nice touch. LED1 shared with TX though, yes I see the utility of it but I would have preferred the user LED to not be shared with the TX pin and instead to have a separate TX LED. But from what I can see, neither of the 2 user buttons or LED2 share connections with the LCD or boosterpack headers which is also a very nice feature to me, no interfering of buttons with boosterpack functionality or LCD functionality and no random blinking of the LED unexpectedly when interacting with boosterpacks or the LCD.
 
I believe the IR functionality previously referred to is the format used by TV remotes which are not IrDA. Also a nice feature to have though.
 
 
 
 
 
Dunno if I am going to pick one up, but I like it.

I like the addition of a 5v pad on the launchpad. Wasnt entirely needed but its a nice touch. LED1 shared with TX though, yes I see the utility of it but I would have preferred the user LED to not be shared with the TX pin and instead to have a separate TX LED. But from what I can see, neither of the 2 user buttons or LED2 share connections with the LCD or boosterpack headers which is also a very nice feature to me, no interfering of buttons with boosterpack functionality or LCD functionality and no random blinking of the LED unexpectedly when interacting with boosterpacks or the LCD.
 
I believe the IR functionality previously referred to is the format used by TV remotes which are not IrDA. Also a nice feature to have though.
 
 
 
 
 
Dunno if I am going to pick one up, but I like it.

I would add the ICSP header. As of arduino 1.0, shields which want to use SPI should do so via the ICSP header and not via the digital IO pins, this allows for a workaround to the otherwise inconsistent SPI pin locations between different processors.
 
This would also allow you access to more of the XL boosterpack pins on the arduino shield if you removed SPI from the main digital pins too (or alternately if this is aimed at the tiva boards, they have multiple SPIs so maybe one in the traditional uno location and a 2nd on the ICSP may work)
 
Technically you dont need level translation for a proper 1.0 shield either, there is an IORef header which is meant to run at whatever voltage the host processor runs at and shields are meant to adapt to that, any level translation is supposed to be shield side and i2c pullups on shields should be done to IORef. Its probably an idea to keep the level translation though, there will probably be alot of shields released which will ignore IORef and there are a ton of pre-1.0 shields out there which of course dont even have a connection to IORef.

Please have a look at Allow I²C 400-kHz Fast-mode (Fm) #282 https://github.com/energia/Energia/issues/282 and http://forum.stellarisiti.com/topic/1592-energia-library-i2c-api-on-energia/

Normally you should factor in the air temperature too but the BMP180 does feature temperature sensing already so you're fine on that front, just needs a slight code alteration. But for your purposes the formula given within the datasheet (which only uses current pressure and a pre-recorded pressure at sea level) should suffice.
Looking at it, the maths is indeed pretty complex to go from raw pressure data to an altitude.
Altitude = 44330 * ( 1 - (p/p0) ^ (1 / 5.255))
Altitude in meters. p = current pressure in hPa (which the sensor returns). p0 = pressure at sea level in hPa.
 
As it stands right there you have 2 divisions, a multiplication, a subtraction and raising a number to a power, and all in floating point. The G2553 isn't great at maths, it cannot do floating point and instead does it in a much slower software implementation. You can define a constant in your program for 1/ 5.255, then it will only need calculating once and in future the code can fall back on this precalculated value to save time, I'd highly advise that if you were to go down the route of calculating the altitude on the aircraft instead of @@chicken's method.
 
It apparently takes 7.5ms for the sensor itself to get a reading, so your MSP430 does have that long to calculate an altitude if you really want to and you probably don't need to retrieve the altitude at much more than 1 or 2Hz anyway. The maths will be slow, but you don't need it to be executed particularly fast.
There is this thing in embedded electronics on whether or not you need to optimise your code for fastest performance, smallest memory footprint or "pure accuracy" (or a better way of saying neither). All depends on the application. I'd say the memory footprint of this thing will be small anyway leaving you with speed vs accuracy. Upto you.
 
Oh, very good writeup on maths on microcontrollers and processors in general here: http://letsmakerobots.com/content/help-your-robot-do-its-math-homework

I do have 2 propeller boards. On paper its very interesting to have 8 cores running simultaneously, but the reality is that you don't get to use those 8 cores fully. Each core has 2 counter modules which are simply somewhat basic timers (no interrupts or output abilities from them) and that is it for peripherals on the entire chip. PWM, Servos, communications all need bitbanging and that will usually use up a few of your cores in a project. Its still useful, but it would have been a better product with some actual on chip peripherals. One of my boards I will be fitting with VGA, RCA and PS/2 connectors and using it as a slave device for graphics and input, thats a genuine project I think it is well suited to (they can drive VGA signals quite nicely as well as PAL and NTSC) but I'm honestly not too sure what to do with the other, maybe a hexapod?

I cannot disclose whether a few may or may not have had incidents involving sledgehammers, only that any that did were dead prior to that.

With a cheap chinese towerpro SG90 clone the second code didn't quite work.
The servo twitches enough that you can feel an ever so faint vibration as you hold it on board reset, not quite a full blown spasm, even the haptic feedback from my phone is more noticeable. After awhile it will center and stay there.
 
I won't blame the code without a proper logic analyzer or oscilloscope to test the output though. Ultimately the servo did something and it is hardly a high quality known brand so it could itself be the fault here (its actually a very cheap and nasty servo, I have no branded ones)

its TI, they seem to be the only big corp that care about the little guy

its TI, they seem to be the only big corp that care about the little guy

its TI, they seem to be the only big corp that care about the little guy

I've been reading up all I can on the galileo and its workings, of course just about everything out there so far assumes the default setup with the galileo having the yocto linux distro preinstalled and supposedly being programmed from the modified arduino IDE which won't be so useful. Still, learning all you can about it can't do any harm.
 
Considering intel seem to want the quark being used as a microcontroller, its a bit odd it has none of its own GPIO, but then I guess it is x86 and its not like x86 is world renowned for having GPIO. The galileo uses a GPIO expander on the i2c bus instead. Apparently the chip itself has some sort of high speed mode, but the arduino software doesnt support it out of the box, it has been the cause of many concerns among the arduino users as I/O is otherwise quite slow (some LCD's dont work for instance), whether we will be stuck with the same issue with microsofts tools or not remains to be seen.
Onboard level translation between 3.3v and 5v, jumper selectable to run at 3.3v native if you wish. A bit of an odd one, the IORef pin will be set by the 3.3/5v jumper. The analogInput range will also match the state of this jumper so in 3.3v mode you can only record upto 3.3v without damage supposedly. Yet the ADC will always reference signals to 5v (the AREF pin is non functional). That could have resulted in some headscratchers if I hadn't read it beforehand.
The onboard EEPROM is also an i2c device. That is an odd choice to me, I'm sure they could have emulated the EEPROM in a file on the flash instead although I guess most people are hardly short of i2c addresses.
There is also a VIN jumper. There is no onboard 5v regulator on the galileo so the VIN pin is instead connected to 5v. Of course if you have a shield which genuinely uses VIN this will cause problems so there is a jumper to disconnect it. Personally I'd have preferred if it wasnt connected in the first place, but I am not everyone. If I do get the board, the jumper will be coming off and staying off.
Under the boards own arduino firmware, mPCIe cards are not supported, you have to use the larger SD card install to access them. Even then only the intel N135 and N6205 cards are supported (and the N6205 is a half size card requiring an adaptor), its possible to install more though. This information is less relevant to us, remains to be seen what the situation will be with microsofts tools.
 
I'm interested to see what microsofts setup is going to be with these boards. Then it will be time to come up with some project ideas.

I've been reading up all I can on the galileo and its workings, of course just about everything out there so far assumes the default setup with the galileo having the yocto linux distro preinstalled and supposedly being programmed from the modified arduino IDE which won't be so useful. Still, learning all you can about it can't do any harm.
 
Considering intel seem to want the quark being used as a microcontroller, its a bit odd it has none of its own GPIO, but then I guess it is x86 and its not like x86 is world renowned for having GPIO. The galileo uses a GPIO expander on the i2c bus instead. Apparently the chip itself has some sort of high speed mode, but the arduino software doesnt support it out of the box, it has been the cause of many concerns among the arduino users as I/O is otherwise quite slow (some LCD's dont work for instance), whether we will be stuck with the same issue with microsofts tools or not remains to be seen.
Onboard level translation between 3.3v and 5v, jumper selectable to run at 3.3v native if you wish. A bit of an odd one, the IORef pin will be set by the 3.3/5v jumper. The analogInput range will also match the state of this jumper so in 3.3v mode you can only record upto 3.3v without damage supposedly. Yet the ADC will always reference signals to 5v (the AREF pin is non functional). That could have resulted in some headscratchers if I hadn't read it beforehand.
The onboard EEPROM is also an i2c device. That is an odd choice to me, I'm sure they could have emulated the EEPROM in a file on the flash instead although I guess most people are hardly short of i2c addresses.
There is also a VIN jumper. There is no onboard 5v regulator on the galileo so the VIN pin is instead connected to 5v. Of course if you have a shield which genuinely uses VIN this will cause problems so there is a jumper to disconnect it. Personally I'd have preferred if it wasnt connected in the first place, but I am not everyone. If I do get the board, the jumper will be coming off and staying off.
Under the boards own arduino firmware, mPCIe cards are not supported, you have to use the larger SD card install to access them. Even then only the intel N135 and N6205 cards are supported (and the N6205 is a half size card requiring an adaptor), its possible to install more though. This information is less relevant to us, remains to be seen what the situation will be with microsofts tools.
 
I'm interested to see what microsofts setup is going to be with these boards. Then it will be time to come up with some project ideas.

I've been reading up all I can on the galileo and its workings, of course just about everything out there so far assumes the default setup with the galileo having the yocto linux distro preinstalled and supposedly being programmed from the modified arduino IDE which won't be so useful. Still, learning all you can about it can't do any harm.
 
Considering intel seem to want the quark being used as a microcontroller, its a bit odd it has none of its own GPIO, but then I guess it is x86 and its not like x86 is world renowned for having GPIO. The galileo uses a GPIO expander on the i2c bus instead. Apparently the chip itself has some sort of high speed mode, but the arduino software doesnt support it out of the box, it has been the cause of many concerns among the arduino users as I/O is otherwise quite slow (some LCD's dont work for instance), whether we will be stuck with the same issue with microsofts tools or not remains to be seen.
Onboard level translation between 3.3v and 5v, jumper selectable to run at 3.3v native if you wish. A bit of an odd one, the IORef pin will be set by the 3.3/5v jumper. The analogInput range will also match the state of this jumper so in 3.3v mode you can only record upto 3.3v without damage supposedly. Yet the ADC will always reference signals to 5v (the AREF pin is non functional). That could have resulted in some headscratchers if I hadn't read it beforehand.
The onboard EEPROM is also an i2c device. That is an odd choice to me, I'm sure they could have emulated the EEPROM in a file on the flash instead although I guess most people are hardly short of i2c addresses.
There is also a VIN jumper. There is no onboard 5v regulator on the galileo so the VIN pin is instead connected to 5v. Of course if you have a shield which genuinely uses VIN this will cause problems so there is a jumper to disconnect it. Personally I'd have preferred if it wasnt connected in the first place, but I am not everyone. If I do get the board, the jumper will be coming off and staying off.
Under the boards own arduino firmware, mPCIe cards are not supported, you have to use the larger SD card install to access them. Even then only the intel N135 and N6205 cards are supported (and the N6205 is a half size card requiring an adaptor), its possible to install more though. This information is less relevant to us, remains to be seen what the situation will be with microsofts tools.
 
I'm interested to see what microsofts setup is going to be with these boards. Then it will be time to come up with some project ideas.

I've been reading up all I can on the galileo and its workings, of course just about everything out there so far assumes the default setup with the galileo having the yocto linux distro preinstalled and supposedly being programmed from the modified arduino IDE which won't be so useful. Still, learning all you can about it can't do any harm.
 
Considering intel seem to want the quark being used as a microcontroller, its a bit odd it has none of its own GPIO, but then I guess it is x86 and its not like x86 is world renowned for having GPIO. The galileo uses a GPIO expander on the i2c bus instead. Apparently the chip itself has some sort of high speed mode, but the arduino software doesnt support it out of the box, it has been the cause of many concerns among the arduino users as I/O is otherwise quite slow (some LCD's dont work for instance), whether we will be stuck with the same issue with microsofts tools or not remains to be seen.
Onboard level translation between 3.3v and 5v, jumper selectable to run at 3.3v native if you wish. A bit of an odd one, the IORef pin will be set by the 3.3/5v jumper. The analogInput range will also match the state of this jumper so in 3.3v mode you can only record upto 3.3v without damage supposedly. Yet the ADC will always reference signals to 5v (the AREF pin is non functional). That could have resulted in some headscratchers if I hadn't read it beforehand.
The onboard EEPROM is also an i2c device. That is an odd choice to me, I'm sure they could have emulated the EEPROM in a file on the flash instead although I guess most people are hardly short of i2c addresses.
There is also a VIN jumper. There is no onboard 5v regulator on the galileo so the VIN pin is instead connected to 5v. Of course if you have a shield which genuinely uses VIN this will cause problems so there is a jumper to disconnect it. Personally I'd have preferred if it wasnt connected in the first place, but I am not everyone. If I do get the board, the jumper will be coming off and staying off.
Under the boards own arduino firmware, mPCIe cards are not supported, you have to use the larger SD card install to access them. Even then only the intel N135 and N6205 cards are supported (and the N6205 is a half size card requiring an adaptor), its possible to install more though. This information is less relevant to us, remains to be seen what the situation will be with microsofts tools.
 
I'm interested to see what microsofts setup is going to be with these boards. Then it will be time to come up with some project ideas.

I've been reading up all I can on the galileo and its workings, of course just about everything out there so far assumes the default setup with the galileo having the yocto linux distro preinstalled and supposedly being programmed from the modified arduino IDE which won't be so useful. Still, learning all you can about it can't do any harm.
 
Considering intel seem to want the quark being used as a microcontroller, its a bit odd it has none of its own GPIO, but then I guess it is x86 and its not like x86 is world renowned for having GPIO. The galileo uses a GPIO expander on the i2c bus instead. Apparently the chip itself has some sort of high speed mode, but the arduino software doesnt support it out of the box, it has been the cause of many concerns among the arduino users as I/O is otherwise quite slow (some LCD's dont work for instance), whether we will be stuck with the same issue with microsofts tools or not remains to be seen.
Onboard level translation between 3.3v and 5v, jumper selectable to run at 3.3v native if you wish. A bit of an odd one, the IORef pin will be set by the 3.3/5v jumper. The analogInput range will also match the state of this jumper so in 3.3v mode you can only record upto 3.3v without damage supposedly. Yet the ADC will always reference signals to 5v (the AREF pin is non functional). That could have resulted in some headscratchers if I hadn't read it beforehand.
The onboard EEPROM is also an i2c device. That is an odd choice to me, I'm sure they could have emulated the EEPROM in a file on the flash instead although I guess most people are hardly short of i2c addresses.
There is also a VIN jumper. There is no onboard 5v regulator on the galileo so the VIN pin is instead connected to 5v. Of course if you have a shield which genuinely uses VIN this will cause problems so there is a jumper to disconnect it. Personally I'd have preferred if it wasnt connected in the first place, but I am not everyone. If I do get the board, the jumper will be coming off and staying off.
Under the boards own arduino firmware, mPCIe cards are not supported, you have to use the larger SD card install to access them. Even then only the intel N135 and N6205 cards are supported (and the N6205 is a half size card requiring an adaptor), its possible to install more though. This information is less relevant to us, remains to be seen what the situation will be with microsofts tools.
 
I'm interested to see what microsofts setup is going to be with these boards. Then it will be time to come up with some project ideas.

I've been reading up all I can on the galileo and its workings, of course just about everything out there so far assumes the default setup with the galileo having the yocto linux distro preinstalled and supposedly being programmed from the modified arduino IDE which won't be so useful. Still, learning all you can about it can't do any harm.
 
Considering intel seem to want the quark being used as a microcontroller, its a bit odd it has none of its own GPIO, but then I guess it is x86 and its not like x86 is world renowned for having GPIO. The galileo uses a GPIO expander on the i2c bus instead. Apparently the chip itself has some sort of high speed mode, but the arduino software doesnt support it out of the box, it has been the cause of many concerns among the arduino users as I/O is otherwise quite slow (some LCD's dont work for instance), whether we will be stuck with the same issue with microsofts tools or not remains to be seen.
Onboard level translation between 3.3v and 5v, jumper selectable to run at 3.3v native if you wish. A bit of an odd one, the IORef pin will be set by the 3.3/5v jumper. The analogInput range will also match the state of this jumper so in 3.3v mode you can only record upto 3.3v without damage supposedly. Yet the ADC will always reference signals to 5v (the AREF pin is non functional). That could have resulted in some headscratchers if I hadn't read it beforehand.
The onboard EEPROM is also an i2c device. That is an odd choice to me, I'm sure they could have emulated the EEPROM in a file on the flash instead although I guess most people are hardly short of i2c addresses.
There is also a VIN jumper. There is no onboard 5v regulator on the galileo so the VIN pin is instead connected to 5v. Of course if you have a shield which genuinely uses VIN this will cause problems so there is a jumper to disconnect it. Personally I'd have preferred if it wasnt connected in the first place, but I am not everyone. If I do get the board, the jumper will be coming off and staying off.
Under the boards own arduino firmware, mPCIe cards are not supported, you have to use the larger SD card install to access them. Even then only the intel N135 and N6205 cards are supported (and the N6205 is a half size card requiring an adaptor), its possible to install more though. This information is less relevant to us, remains to be seen what the situation will be with microsofts tools.
 
I'm interested to see what microsofts setup is going to be with these boards. Then it will be time to come up with some project ideas.

the little 3.3v module I am kinda interested in, looks perfect for my setup (and well, most breadboards in general). The breadboardable MSP430, not so much I must say, its not that its a bad board (it isn't) but I do have my own plans for a small form factor MSP430 board and on a breadboard I am perfectly happy with a regular MSP430 DIP, otherwise it does look like a nice small form factor MSP430 breakout.

I agree with @@spirilis and would have to say no to both 1 and 2. This is a link to a good article about running uClinux on Cortex-M3/M4 devices: http://electronicdesign.com/embedded/practical-advice-running-uclinux-cortex-m3m4

Value Line is a specific lineup of chips.  Most of the Value Line chips come in different packages; DIP being the popular one that works with MSP430G2 LaunchPad.  All those same chips available in DIP are available in a TSSOP (surface mount 0.65mm pin pitch) and QFN variations.
 
My understanding is of course the Value Line isn't just for hobbyists, it's meant to be an affordable option for TI's professional customers too, and many probably do use them in small gadgets & toys and such.  Last year TI released an expansion of the Value Line, but only offers the chips in surface mount (TSSOP, QFN) variations of the package, no DIP so they won't work with the MSP430G2 LaunchPad without installing the chip on a separate carrier board.  These chips have notably expanded memory (flash & SRAM) and are much more comfortable to code for since you're far less constrained--the chips' resources are closer to what Arduino has been using for years (and exceeds it, in the case of the MSP430G2955).  But TI doesn't have any easy LaunchPad-style boards for them, so a couple of us have built our own.  That said, it all became a somewhat moot point when TI released the MSP430F5529 LaunchPad, whose resources far exceed even the highest of the new Value Line chips.  So enthusiasm for the higher-end Value Line chips (e.g. MSP430G2955) has waned a bit.  I personally feel there's a place for them in my projects though.