Things to Know
We’re going to be walking through how to prepare a Yocto build for use with our i.MX6 products, specifically the TS-4900 which we have a special build recipe for. A build recipe is a friendly term to describe the scripts and environment variables required to build a Yocto distribution. There are many other build recipes available which work on a more generic level as well, so this guide can be applied generally as well. This guide is both an echo and extension of the TS-4900 Build Yocto Distribution wiki page. I’ll be mostly echoing (aka copy/pasting) the steps, but I’ll also add a few notes along the way. I’m going to assume you’ve landed here because you’re using search terms that make you at least familiar with what Yocto is and the terminology that surrounds a basic software development environment. If you have questions, I’m happy to try and answer them in the comments that follow.
Continue reading “Building a Yocto Image for NXP i.MX6 Products”
How Technologic Systems is preparing for the transition to ISO 9001:2015
ISO 9001 was designed to help organizations ensure that they meet the needs of customers and other stakeholders while meeting statutory and regulatory requirements related to a product or service. ISO 9001 deals with the fundamentals of Quality Management Systems, including the eight management principles upon which the family of standards is based. However, with the advent of ISO 9001:2015 upon us, it is clear that the paradigm regarding quality is changing as words and phrases like “Risk-Based Thinking”, “Leadership”, and “Evidence-based Decision Making” make their way into the forefront of Strategic Business Planning.
The new ISO 9001:2015 standard moves the subject of Management Systems into the boardroom. While this will be a cultural change, it is also a great opportunity for the enterprise leaders to improve their business overall. Continue reading “Risk Based Thinking, Transition to ISO9001:2015”
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”