They last longest when stored at 40% of capacity. That is why everything you buy with lithium batteries comes charged to about that. Avoid storying batteries at elevated temperatures too. It is ok to freeze them, just warm them up before charging. Charging a frozen battery can destroy it.

Lithium batteries really don't like being kept at 100% state of charge (it degrades them). The way most people use a laptop ensures premature battery failure. My laptop spends 99.9% of its time plugged into a docking station (constantly charging the battery). I doubt if my battery will last any longer than yours. Laptop makers should add an on-line battery mode that charges (or discharges if needed) the battery to 30% state of charge. At this level of charge a lithium battery has a greatly extended shelf life. When you need to travel, you charge the battery to 100% and off you go. They wouldn't be able to sell as many replacement batteries if they did this so I don't ever expect to see anything like this. Phil Ouellette, BSEE

Embedded programming is antithetical to pretty much every programming trend of the last 20 years. Note: If you are programming on a board that runs Linux or Android then this discussion is not really aimed at you. Deeply embedded systems are often built on severely resource constrained hardware. The typical embedded system uses only the memory built into the processor which can be a lot less than you expect. Cortex M0 processers for example come in variants with as little as 32KB FLASH and 2 KB RAM. Note the K vs M. The primary embedded programming languages is C (not C++ even though your compiler will claim to be C/C++). You will also need assembly code if you do board support packages. If you are not a proficient C coder, then get a good book and teach yourself. Book recommendations: All of these are older than dirt, but they are classics for a reason and will help you develop the mindset of an effective embedded programmer. Some of these are available as free downloads. * "Practical C Programming" by Steve Oualline for learning C coding in general. * "The Art of Embedded Systems" by Jack Gansslle for the general philosophy of embedded programming. * "Math Toolkit for Real-Time Programming" by Jack Crenshaw for complicated math. * "Insiders Guide to the Phillips ARM7 based Microcontrollers" by Trevor Martin for using processor resources. Martin's book on Philips ARM7 is the very best hardware tutorial book I have ever read. Hitex did a great thing for embedded programmers when they released this book as a free download (I think Philips paid for this book). I wish they had done the same thing for Cortex M processors, but life happens and money is not infinite. https://perswww.kuleuven.be/~u0068190/ARM7/lpc-ARM-book\_srn.pdf Embedded systems can go years between reboots and memory usage management is up to the programmer. Automatic memory allocation (malloc, new, etc.), or anything object oriented can be dangerous. Be wary of any library code that uses these kinds of things. This is one of the reasons why I want the source code for all libraries I use. Ring buffers are your friend. If properly implemented, buffer overflow exploits just became a thing of the past. You will need to be able to deal with missing data. I use packetized messages with error detection and missing message detection built into the communication protocol (I have been using my own processor to processor packetized protocol that I have used and extended over the last 2 decades). Every embedded product needs a r

The ternary operator is in C. I use it. It is not any more efficient than a simpler if else construct, but visual scope matters as well. Being able to see more of the code on the screen at the same time can make coding/debugging faster and easier.

I do embedded C mostly also. However I had a fairly hairy embedded project that I ended up writing a C# wrapper around to permit faster testing (I was processing recorded data files). The only thing I really missed from C is the preprocessor. Why is this not a thing in C#? #define FOOT_PER_MILE 5280.0 #define INCH_PER_FOOT 12.0 #define INCH_PER_MILE (FOOT_PER_MILE * INCH_PER_FOOT) double miles = 12.54; double inches; ... inches = miles * INCH_PER_MILE; In a lot of embedded applications you don't have GB of ram to use. Sometimes you are stuck with KB of RAM. It is hard to beat inline constants when squeezing a program into a resource limited processor.

Depends. Dropping USB 5V to 3.3 with a linear throws away 1/3 of the power as heat (67% efficient). A good switcher can provide 90%+ efficiencies. They can also operate off lower voltages, like 3.7V lithium ion cells supply. 2.5V to 5.5V input range, 3.3V out. I use them in my designs. If you want a specific recommendation, list the specs you need to meet. Analog Devices and TI both have excellent options. Analog Devices has all of Linear Techs IP. Those guys make some amazing parts, especially if you need low noise. Big thing for LDOs is input ripple rejection. TI's TSP7A family LDO's reject input ripple out past 2 MHz. Analog Devices has a similar (better) part, but it costs 2-3 times as much.

Look at your power supply design. Consider replacing LDOs with DC-DC converters. Don't forget electrical emissions requirements if you make this change. Buck converters radiate out their inputs.

Totally correct. There is the Allman style and everything else. I am so retentive about this, I surround single line indented lines like this. if (foo) { single_line(); } Sometimes real world function get longer than will fit on one or even two screens. Being able to clearly see and understand the organization of a complicated bit of logic makes it more likely the code is doing what you actually wanted it to do. And don't get me started on Hungarian notation. I guess if you are coding on paper or a chalkboard it makes sense. Otherwise, what a ridiculous concept.

That is the answer I came up with also.