Silicon Labs Silicon Labs Community
silabs.com
Language
  • 简体中文
  • 日本語
  • MCUs
    • 8-bit MCU
    • 32-bit MCU
  • Wireless
    • Bluetooth
    • Proprietary
    • Wi-Fi
    • Zigbee & Thread
    • Z-Wave
  • More Products
    • Interface
    • Isolation
    • Power
    • Sensors
    • Timing
  • Development Tools
    • Simplicity Studio
    • Third Party Tools
    • Thunderboard
  • Expert's Corner
    • Announcements
    • Blog
    • General Interest
    • Projects
  1. Community - Silicon Labs
  2. Blog

Essential Best Practices and Debugging Tips for EFM32 Project Success - Part 1

01/18/2017 | 01:36 AM
lynchtron

Level 5


 debug_teaser.png

 

As a computer engineer of 20 years and a developer of EFM32 projects for over two years, I am lucky to have a vast background of experience from which to develop complex computer engineering projects.  That’s not required anymore, thanks to tools like Silicon Labs’ Simplicity Studio software and the wide availability of hardware debugger tools such as the EFM32 Starter Kits.  With platforms like these, anyone can get started on embedded development quickly and cheaply.  Within minutes of receiving your Starter Kit, you can be single-stepping through your very own hardware-enabled embedded solution.  My work on this book should give you a good idea of how to get started to make use of all of the bundled peripherals within the EFM32 line of chips.

 

However, just because you can follow some examples and get lights to blink and electronics to start to function in an example doesn’t always translate into success in your own projects.  My years of experience have guided me to make the correct upfront decisions on how the hardware should be connected, how the software should be architected, and my experience is right there whenever things go wrong, giving me intuition on what to do next in the debugging process to solve the problem.

 

But what if you don’t have years of experience to lean on?  How can you find success that won’t take years and years to master?  My answer to that question is in the following posts of this series, where I will attempt to distill as many golden nuggets of wisdom that I had to learn the hard way.   You may want to read this guide a few times, and then read it again later when you are stuck on a problem.  It could be the key to solving any number of issues that pop up along the way.

 

Some of these tips relate to the Simplicity Studio Integrated Developer Environment (IDE) bugs and nuances that may change as Simplicity Studio is improved over time.  But most of the tips in this guide are generic and should apply to all facets of your design from start to finish.

 

There are six parts to this series:

  1. Use a Version Control System
  2. Start Development on a Breadboard
  3. Plan a Prototype Build
  4. Code Well, and Everything Works Better
  5. Build Source Code Like a Pro
  6. Debug Issues Like a Genius

 

Part 1 - Use a Version Control System

Before you get started with a new design, take the time to set up a version control system for all of your design work.  This may seem obvious to many, since these systems are so widespread in software development.  But it is very important for embedded development, where a single character difference in a source code file can sometimes be the difference between a working solution and one that completely fails. 

 

1.      Find differences across revisions

Version control systems allow your work to be saved at various snapshots as the design progresses, and allows you to compare differences in your files from each snapshot.  These systems are freely available and can be installed on all types of operating systems (Windows, Mac and Linux).  The most popular tools today are SVN and Git.  I am a user of both systems but I prefer Git these days because it keeps the complete repository including all of the revision history available locally on your computer and you can work completely offline, and then “push” the changes to a remote server later.  SVN, on the other hand, only keeps the most recent revision on your local computer and requires an active connection to the server to fetch past revisions and other history information.

 

The code examples of this very book are stored in an online Git repository on Github, so it would make sense for you start by “cloning” that repository to your local hard drive and making changes, then experiment with the Git command line or GUI tools to look for the differences in the files.  Setting up and using Git is beyond the scope of this guide, but there are many tutorials out there from which to learn.

 

2.      (Optional) Set up Git in Simplicity Studio

Simplicity Studio can be configured to work with Git within the Simplicity Studio IDE.  This allows you to commit changes and look for differences across files right within the IDE.  Details of how to get that setup can be found on the Silicon Labs Community.  Note that the integration is not required to use revision control, and I don’t use the integration on my computer.  I simply run the command line version of Git or the GUI tool on my local folders to make my commits and review differences.

 

3.      Store all your files in a repo, not just source code

Whenever you start a new project, set up a new version control repository (called a “repo” for shorthand) to store all of the files that pertain to that project.  Go ahead and store all of your specifications and datasheets, design documents, spreadsheets, and so on, in that repo.   You never know when that document you are viewing online may become unavailable or changed by the manufacturer.  It’s good to have a copy in a safe place where it is bundled with the design files.  Don’t stop at documents either.  Store the schematics and layout files for your project in version control as well.

 

4.      Keep a backup of the repo online

It is best to get an online service such as Github, Atlassian, Google Drive, Microsoft OneDrive, or any other online backup service to keep an extra backup copy of the repo.   When your hard drive crashes or your laptop goes missing, cloning the last server copy of a Git repo is a very quick and easy option to get your design files back on your computer.

 

5.      Commit early, and often

Once you have your repo set up and keeping track of your files, make sure to “commit” your design files whenever you reach an important milestone in your project.  When you have just been able to communicate to some chip for the first time, make a commit of the code and specify in the log message exactly the current state of the project even if the source code is a mess of a hack to get it to that point (which it sometimes requires) . For example, “Got accelerometer device ID read out over SPI” is a great message to yourself letting you know that the code that is then committed to the repo basically functions.  What usually happens next is that you clean up the code to make it fancier, more readable and better performing, and sometimes that process breaks the code.  Sometimes the reason for why the code was broken is obvious and you are on your way, but sometimes everything you do to try to fix the issue doesn’t work and you are back at square one with a solution that no longer functions at all.  If you have a committed version of the working code in the repo, all you need to do is first commit your new code to the repo, then rollback your changes on your local drive and see if that original solution still works, which lets you know that at least you aren’t going crazy.  You can then use the difference tools of the revision control system to show differences from the first version to the second version and eventually isolate and fix the issue.

 

6.      Use version control to isolate hardware issues

One key difference between embedded development and pure software development is that hardware can change from run-to-run on an embedded application.  When you run the solution the first time, everything works, and then you make some changes and things stop working.  It may seem like the software, but perhaps a wire has wiggled loose somewhere?  By committing your changes to the repo, then rolling back to the last version that worked, you can be sure that the problem is not software, find and fix the loose wire, then update the repo back to the most current version and continue development.

 

Keys to Success with Version Control

  • Integrate revision control systems into all facets of your design methodology.
  • Keep a copy of the repository in an online backup for safekeeping.
  • Commit early and often, with descriptive messages as to the state of the code.

In the part two of the series, we will learn about the virtues of breadboarding your project before you make a PCB.

  • Blog Posts
  • Makers

Tags

  • Wireless
  • High Performance Jitter Attenuators
  • EFR32MG21 Series 2 SoCs
  • Blue Gecko Series 2
  • Zigbee SDK
  • ZigBee and Thread
  • Internet Infrastructure
  • Sensors
  • Blue Gecko Bluetooth Low Energy SoCs
  • Z-Wave
  • Micrium OS
  • Blog Posts
  • Low Jitter Clock Generators
  • Bluetooth Classic
  • Makers
  • Flex SDK
  • Tips and Tricks
  • Smart Homes
  • IoT Heroes
  • Reviews
  • RAIL
  • Simplicity Studio
  • Mighty Gecko SoCs
  • Timing
  • Blue Gecko Bluetooth Low Energy Modules
  • Clocks
  • Ultra Low Jitter Clock Generators
  • General Purpose Clock Generators
  • Industry 4.0
  • Giant Gecko
  • 32-bit MCUs
  • blue-gecko-xpress-modules
  • Bluetooth Low Energy
  • 32-bit MCU SDK
  • Gecko
  • Microcontrollers
  • News and Events
  • Industrial Automation
  • Wi-Fi
  • Bluetooth SDK
  • Community Spotlight
  • Biometric Sensors
  • General Purpose Jitter Attenuators
  • Giant Gecko S1
  • Flex Gecko
  • Internet of Things
  • 8-bit MCUs
  • Isolation
  • Powered Devices

Top Authors

  • Avatar image Mark Mulrooney
  • Avatar image Siliconlabs
  • Avatar image Nari Shin
  • Avatar image lynchtron
  • Avatar image deirdrewalsh
  • Avatar image Lance Looper
  • Avatar image lethawicker

Archives

  • 2014 December
  • 2015 January
  • 2015 February
  • 2015 March
  • 2015 April
  • 2015 May
  • 2015 June
  • 2015 July
  • 2015 August
  • 2015 September
  • 2015 October
  • 2015 November
  • 2015 December
  • 2016 January
  • 2016 February
  • 2016 March
  • 2016 April
  • 2016 May
  • 2016 June
  • 2016 July
  • 2016 August
  • 2016 September
  • 2016 October
  • 2016 November
  • 2016 December
  • 2017 January
  • 2017 February
  • 2017 March
  • 2017 April
  • 2017 May
  • 2017 June
  • 2017 July
  • 2017 August
  • 2017 September
  • 2017 October
  • 2017 November
  • 2017 December
  • 2018 January
  • 2018 February
  • 2018 March
  • 2018 April
  • 2018 May
  • 2018 June
  • 2018 July
  • 2018 August
  • 2018 September
  • 2018 October
  • 2018 November
  • 2018 December
  • 2019 January
  • 2019 February
  • 2019 March
  • 2019 April
  • 2019 May
  • 2019 June
  • 2019 July
  • 2019 August
  • 2019 September
  • 2019 October
  • 2019 November
Silicon Labs
  • About Us
  • In the News
  • Email Newsletter
  • Cookies
  • Contact Us
  • Community
  • Site Feedback
  • Investor Relations
  • Blog
  • Privacy and Terms
  • Corporate Citizenship
Copyright © Silicon Laboratories. All rights reserved.
粤ICP备15107361号-1