I am looking to add a section in the newsletter that would be titled 'Quick Tip of the Week for the Embedded Systems Engineer' or something similar (any suggestion?).  The basic idea is to see if we can come up with short bits of useful advices (between 20 and 100 words) that would fit well in a newsletter and make it a quick and interesting read.

If you have ideas, please use this thread to share them.  If your tip is selected for a newsletter, 10 beers ($20) will be awarded and full credit will be given in the newsletter (24k recipients!).  Not bad for maybe 10 minutes of your time?

And of course, please make sure to 'thumbs up' your favourite tip(s) so I can know which one(s) you think should be featured in the newsletter.  

A tip could start like this:

When doing something, always make sure to do something else before

or

When you encounter some error/problem, maybe it is because of some cause.

or any other form you can think of.  As long as the information has the potential to be useful and fit within 100 words.

Thanks!

A general truth is that the systems are as good as the test suites ran on them.

Always design with test-ability in mind, the first thing to develop is the trace/debug mechanism, it can be service channel also. So that you can immediately access the sub-modules (units) and see if your OS/Stack has the problem or something in the underlying firmware or maybe the hardware.

This is crucial for bring-ups, when you are starting from scratch a new product.

One real-life example:

(battery charger) IoT device, controlled over BLE, accessing some peripheral IC's over I2C. By using a simple UART-I2C bridge IC and accessing the peripheral IC's directly from the PC via scripts, we speeded up the evaluation of the whole product and also the development of the functionality logic. In parallel the OS and the IoT part was developed then later one having the possibility to port the already available functionality(running via some pearl/python scripts) to the OS.

When performing back to back debugging, it's useful to have your software output a version identifier (over serial or LCD, etc.) so you can immediately tell what version of the software you're seeing desirable or undesirable behavior in.

When working with CMOS logic, always make sure that unused inputs are pulled high or low. Really weird things can happen if you don't.

And rather than taking the unuseds pin directly to a ground or power plane, run a short surface layer trace to a via.   Then if you find out you actually needed to use that pin, you can quickly cut and jumper, and carry on debugging the prototype board(s) and fix it on the first revision.

if you have room in a board layout, connect a couple of adjacent through holes to ground. A U shaped piece of wire (clipped component lead) then makes a handy place to clip a scope probe. This is even handier with SMT boards, where finding a place to clip in can be a real pain.  Even just one hole with a lead helps, but the U resists tugging the ground clip off better.

If you want to fast develop an IoT device make sure to select a platform that have the software and drivers ready for your application.  Free (or proprietary) Operational Systems, Communication Drivers and Libraries could save a lot of time (and money)!

Embedded coder must think how to apply state machine, intelligently select HW for Serial or parallel programming, write an optimized code with lower memory and lower number of instructions to squeeze out max speed within the limited speed available and use extensively HDL, ASM, and C.

Distributed Intelligence cuts down costs

The usual strategy adapted by most embedded systems engineers is to use a complex mcu to control the entire functionality of their project/product. While this strategy, undoubtedly, helps in reducing costs, pcb real estate and confines the entire code into one mcu, the timelines could suffer a lot. Whether required or not, every miniscule revision demands verification of entire code, almost everytime.

Another painless technique would be to use simple focussed mcus with a task-specific approach. These simple, may be small, mcus can be delegated various tasks while a main mcu ( not so complex as is in the earlier case ) could co-ordinate the entire operation. Very importantly, sometimes, you can avoid using expensive ASICs. For example, in a medical device, we used an inexpensive RL78/G10 mcu from renesas to charge Lithium Ion battery. The code was few lines and it works flawlessly with a few external components. We also could send battery status to main mcu and display it.

In another instance, we had to implement a LCD Module display for an existing design and sufficient MCU pins were not available. A simple UART based design with RL78/G13 MCU + LCD Module, made the job easier.

When a processor supports multi pin functionality on the same pin, before using any interface make sure that the required pinmux is selected or enabled. For example when working with ADSP-BF707 processor and using SPI2 interface select the required pins from the system.svc file graphical tool, after the project is opened from CCES (Cross Core Embedded Studio).

Use the compiler to catch your errors before running the code on the target. Create and use "static asserts" to catch common code maintenance issues during compile time. Some examples here:  Favorite Tricks: Static Assert