Here are some tips compiled from our seasoned engineers on what they wish they’d known about embedded linux back when they were “newbs”. Newcomers and seasoned veterans alike should get some good nuggets of information and possibly a fun perspective looking back at our own humble beginnings. We’ll try not to overwhelm you as we make our way through the list. We’re not here to rewrite the books, but do want to provide a personal perspective. If you’re in the camp of people who’ve been using desktop Linux, just be aware embedded Linux is a different animal, especially when it comes to space constraints, different CPU architecture (ARM), resilience to sudden power outages, and inability to install any mainline Linux kernel or distribution you please. And maybe you’re in the microprocessor camp moving towards a more generalized and capable embedded Linux system. Either way, we’ll assume you have at least some knowledge of Linux as we walk through this guide.
Continue reading “What I Wish I’d Known When I Was an Embedded Linux Newbie”
Tag jumping is immensely helpful when developing in a CLI environment such as Vim or Emacs. Simply place a marker over the function, variable, class, macro, etc. and with a keystroke jump to the declaration or view other references across multiple files. This productivity tool will help you develop and debug faster and get a better understanding of your codebase.
There are two main solutions for tag jumping: ctags and cscope. Both are very similar in how they function: scan a codebase and index keywords (tags) and their locations. Vim understands the index and provides you with an interface for jumping back and forth between the tags.
The differences between the two are small, but important to distinguish. With ctags, you can use autocomplete (aka omnicomplete) for function and variable names as you type, something cscope doesn’t give you. Also, there’s much less setup to get ctags up and running as it’s generally already installed. The downside is ctags doesn’t do as well as cscope with a conglomerated or mostly unknown codebase. The good news is, they can co-exist!
We’re going to take a look at setting up and basic usage of both in this guide. If you need a diverse codebase to try this out on, try cloning a random trending c repository from GitHub. I settled on grpc/grpc because it was large and varied enough to really put ctags and cscope to the test.
Continue reading “Tag Jumping in a Codebase Using ctags and cscope in Vim”
This is a developer’s note about rewriting the Application Programming Interface (API) for the TS-ADC16 and TS-ADC24 PC/104 peripherals. With the existing API being written in 2010 it was decided that a rewrite would be more effective than a comprehensive update. This article will cover the details of the development for the new API and also briefly describe the functions in the API.
Continue reading “Developer Notes on API Rewrite for TS-ADC16 and TS-ADC24”
If you’ve ever been concerned with or experienced disk and filesystem corruption in an embedded Linux environment, you’ll want to take a look at this whitepaper to help you understand and prevent it.
Preventing Filesystem Corruption in Embedded Linux
Almost any computer system is subject to unexpected power failures. For some embedded systems, this only occurs when the power grid goes down. For others, it may happen when a user decides to pull the plug instead of using a documented shutdown procedure. Automotive and remote systems need to anticipate that power will stop and start several times a day. If an embedded system is implemented without thinking about what happens when the power goes down it could lead to catastrophic failures down the road. Due to the nature of failures caused by unexpected power loss an embedded system may run for weeks, months, or years before users experience an unexpected and catastrophic failure. From the user’s perspective, their device worked fine yesterday and today it doesn’t even turn on, and they don’t tie it back to the unexpected power failure event.
One collection of failure types caused by unexpected power loss are those related to issues with the boot medium. Investigating the boot medium failure as a result of power loss may show an unclean filesystem, missing files, or more commonly a filesystem that only mounts as read only. The latter happens when the filesystem detects a serious problem with filesystem metadata during runtime that it cannot fix automatically causing it to remount read only to avoid writing to prevent further corruption on the disk. Many people turn to common journaled filesystems like ext3/ext4 to attempt to address these failures. While journaled filesystems like ext3/ext4 are less prone to corruption, they are far from immune.
Read the rest on Technologic System’s offical website, Preventing Filesystem Corruption in Embedded Linux
The question “How do I write a TS Image to an SD card under Linux / Mac OSX / Windows?” comes up quite a bit when dealing with embedded systems or any situation where you want to make an exact, bit-by-bit copy of a removable storage card or disk. While the following guide talks about our products, it can be applied generically. Read through it first to make sure you have a basic, core understanding of the instructions given, and then apply them to your situation. We’ll be looking at how to write to an entire disk and/or a specific partition on that disk using the dd command, a common utility found in most unix systems for low-level operations on hard disks. Jokingly, ‘dd’ stands for “disk destroyer” or “delete data”, so take care!
Continue reading “How to Write an SD Card Image (Linux, Windows, Mac OSX)”
Here’s an example program our engineers might find useful. Kris Bahnsen, a long time engineer for Technologic Systems, wrote this simple program to get the voltage input (Vin) on the 8 – 28 VDC power rail on the TS-7670 (Rev. D or later) or TS-7400-V2 (Rev. B or later). Without going into too much detail about implementation of the on-board supervisory microcontroller, there is a register which is used to store various ADC values, including Vin. This example program basically polls this 4 byte register via I2C interface, accounts for the voltage divider (see TS-7670 schematic or TS-7400-V2 schematic), and spits out the Vin value. So, without further ado, here’s the code:
Continue reading “Getting Current Voltage Input (VIN) on TS-7670 or TS-7400-V2”
We’re graduating from our Getting Started with Qt Creator on the TS-TPC-8390-4900 guide, where we ran an example program which came preloaded with Qt Creator on our TS-TPC-8390-4900, and moving into a more real world situation. This guide builds upon the foundations that we set up in the getting started guide and will walk you through building a simple human machine interface (HMI) for supervisory control and data acquisition (SCADA) applications. We’ll be controlling a register connected to a red LED as well as reading a temperature sensor connected to our CPU. This is about as basic as you can get to demonstrate both system control and data acquisition, and it’s not far from a basic real world use case. In the real world, you’d be toggling DIO or relays instead of toggling an LED. As an end user of the touch panel computer (TPC), you’d be transferring control signals or other data via RS-232 or Ethernet with the press of a button. Once you complete this tutorial it’s a small jump to toggle DIO and relays to control a remote system.
For this guide, a project file containing TS-TPC-8390-4900 specific code written in C++ called “HeatLaser” will be provided for you. It reads CPU temperature every second and toggles the red LED. You’ll simply download it and open the project within Qt Creator. By the end of this guide, you’ll be able to run and have a basic understanding of a Qt Quick Controls application. When you’re comfortable, you can make some edits to the project file to implement other similar tasks that may be more relevant to your needs.
Continue reading “Develop a Simple Qt Quick Interface for HMI/SCADA Applications”
Let’s take a quick look at an example C++ program which reads CPU temperature and controls an LED using sysfs. This example is a bit specific in that it’s only been tested on our NXP i.MX6 powered TS-4900 or TS-7970 running Yocto Linux, but the principles could be applied to other embedded systems as well. If you’re interested in the nitty gritty details about sysfs, take a look at The sysfs Filesystem by Patrick Mochel. Suffice it to say for our purposes, sysfs makes it easy for us to interact with system hardware using plain text files located in the /sys/ directory. The file to control the red LED is /sys/class/leds/red-led/brightness. The file to read the CPU temperature is /sys/class/thermal/thermal_zone0/temp. If we want to turn the red LED on, we simply write a ‘1’ to the file, and not surprisingly, writing a ‘0’ will turn it off. If you’ve booted up your TS-4900 or TS-7970, you can see this by running the shell commands:
Continue reading “Reading CPU Temperature and Controlling LED with C++ via sysfs”
In this getting started guide, we’re going to look at what it takes to get an example Qt Creator project running on the TS-TPC-8390-4900 or TS-TPC-7990. This will help pave the way for developing a human machine interface (HMI) for supervisory control and data acquisition (SCADA). We’ll start out by talking about the expected workflow and specific versions compatible with our chosen hardware, TS-TPC-8390-4900 or TS-TPC-7990. Next the TS-TPC-8390-4900 and Qt Creator will need to be prepared to work together. Finally, we’ll test our environment by running an example Qt Quick Controls Application. In a follow up guide, titled Develop a Simple Qt Quick Interface for HMI/SCADA Applications, we’ll look into what it takes to gather some system data and control DIO.
Continue reading “Getting Started with Qt Creator on the TS-TPC-8390-4900 or TS-TPC-7990”
The Dark Side
Weather is inevitable, downtime shouldn’t be. Per Information Week, in 2015 IT downtime alone costs $26.5 Billion in lost revenue. This does not take into account the loss of customer confidence, productivity, and supply chain interruptions that are a result of these outages. In a constantly wired world, service level agreements (SLAs) with online availability requirements of >99.9% is today’s de-facto standard. It is simply a fact of the new business model that downtime is no longer acceptable. Industry has done what it can to protect itself from these outages as much as possible, and a few of those options are laid out below. But the result is the same, enterprise level businesses can no longer operate without disaster recovery plan with as many contingencies in place as possible to ensure minimal rebound and recovery time should an outage occur. With embedded electronics permeating further into our everyday lives, partially in thanks to the Internet of Things, there are more and more devices that we need to worry about recovering once the lights come back on. So what can you do to fend off the darkness?
Continue reading “Who’s (Not) Afraid of the Dark?”