I have been programming since the old days when assembler was the king (good old days when you had absolute control of the CPU), nowadays with C programming and huge ROM memories the programs are becoming a huge mess difficult to read and follow.

I used to have an elephant memory, when debugging, I could know which line of code contains the bug according to the watch variable. Now try to remember a 32-bit register set by magic numbers.

Becoming a middle age man with a lower ram, I must optimize my framework to perform in “this project is for yesterday” days.

This is my list that will help you to continue motivated and love the embedded world!

A. BE ORGANIZED:

-Organize your work in folders. This sounds silly but is very important, having a folder with the chip’s documentation, libraries, application in a single place will save you a lot of time. Do not be afraid to have file duplicates this is just for organization purposes.

-Backup your work. Even if you work in a share environment, make your own copies. Remember, hard drive space is cheap and if you follow a good folder structure you just, right click, zip and name day_month_year_version.zip; I do at the beginning of the day, so if the today version contains a lot of bugs, I can come back in time to compare with the working code from yesterday and last week.

-Code revision. Once you have a working code, commit your code and add a version review. For future versions add change log. Here you can delete your old copies and zips or put old copies in an external hard drive.

B. BE DISCIPLINED: (You can follow, or you can create your own rules!)

-Follow a programing code standard. Check if your compilers are compliant to C99, ANSI C, etc., in that way you can port your code to different compilers and/or toolchains.

-Follow a code coding standard. The compiler is not almighty bugs appears and could be hard to track. By following a code standard, you could reduce bugs, your code is easy to read and gives that feeling of “this is a work of a good professional”. Read Embedded C Coding Standard by Michael Barr or follow MISRA-C directives. For example. Add _t to structure names (my_structure_t) or p_ to pointers, p_my_pointer; by doing that the code speaks for itself.

-Use static coding analysis software. Do you use lint to check your code? This tool could teach you how to code C/C++ like a pro.

-Do templates and use code completion tools. Do you know that you can create your own Code Snippets?

C. BE COMMUNICATIVE

-Document your work. The documentation is not for someone else. Have you try to reuse your own code or PCB design and think “what I was trying to do here?”. Writing code is like writing a novel, it follows your mind state.

-Use pseudo-code and the “to do list”. Someone can thank you later, even your own self.

D. Adaptability:

Do not stick to one MCU or manufacturer, having the ability to choose from abroad catalog gives you the advantage, to do that, you have to read datasheets and try different MCUs, sensors, OPAMPS, etc. Go to a job interview and answer I only know how to do it with apples! I mean Arduino. I mean…you know what I mean? Do you?

Once you get use to read datasheets you can develop your psychic powers. Those psychicpowers will help you to understand the documentation. Have you read a page in a datasheet and ask to yourself “Say what?” (this can be very frustrating).

E. Conflict Resolution.

Go to a meeting with software engineers, electronic engineers and CEOs, then you know what I am talking about.

Try to show how the skills from A to D are useful for you.

(Skill A) Ask yourself if this is only a problem of organization, can we implement a software strategy (share folder, server, etc) to put all the information together, so everyone can track the project? Can we schedule a project revision? Can we commit our changes and check if the electronics follow the software? Can we schedules small test? Do we required review the client requirements? Are we in the good route? .

(Skill B.) Ask to the team, which standards are following and make sure that we are following. Standards and rules can be changed so is good to be updated or ask for changes.

(Skill C.) Check if other teams are doing the documentation, share your to do list and make sure that other teams know your requirements and make sure that you understand theirs.

(Skill D.) Don’t be the gear that do not want to fit, sometimes changes must be done and because you can adapt your programs or reuse your work you can be the one that solve the problem or the one that offer a better solution.

F. Self-motivation

This is me most important skill. You need it because the embedded world is so dynamic and you need to adapt to new trends, new coding ways (HALs , RTOs), software tools, etc.

So, keep yourself motivated and do not be afraid to try new stuff. Some software developers hate electronics, and I know electronic engineers that do not like to do a line of code, they do not even read the software library code and/or documentation, they just plug'n play (#define) and then say, “this is not working!”.

Keep moving and update your skills, don’t be the assembler almighty that hates C, or the C developer that hates C++, or the we must buy Proteus because is the one I know.