Adventures with a ATSAMA5D27 board
Recently, we brought up a new PCB (printed circuit board) a customer had designed based on the Microchip ATSAMA5D27C-D1G processor. We encountered several interesting challenges.
Blog
Drone for Continuous Integration
Recently, we have been evaluating Continuous Integration (CI) systems for a variety of projects (both OSS and customer). There are many OSS options to chose from. Because we already use Docker containers for Yocto/OE builds, Concourse and Drone made the short list. Both communities seem responsive and helpful.
Read More »Drone for Continuous Integration
Reflections on KiCad and EDA Tools
A recent interview with a KiCad developer prompted some reflection on KiCad and EDA (electronic design automation) tools in general. Below are samples of several PCB (printed circuit board) designs, created with KiCAD, and implemented as part of the SimpleIoT project in the last couple months.
The experience has been excellent. Above all, the tool is very fast, efficient to use, and stable. Schematic and PCB integration works well enough, and routing and copper pours are easy. Switching between inches and millimeters can be done on the fly. The KiCad library has many parts in it, and other organizations, such as DigiKey, Seeed, SnapEDA, and Ultra Librarian are also providing libraries. If a KiCad symbol/footprint for a part is not already available, it is relatively easy to create new symbols and footprints as needed. There is a good KiCad support forum. KiCad is a pleasure to use and production-ready for standard PCB designs.
Read More »Reflections on KiCad and EDA ToolsThe Humble Programmer
In 1972, Edsger W. Dijkstra published a paper titled The Humble Programmer. Dijkstra was trained in math and physics and was a university professor for much of his life. This paper is an interesting reflection on the history of computers and contains thoughts for the future. A few quotes are included below:
Read More »The Humble ProgrammerWhy are Go applications so reliable?
Go does a lot of things well (good performance, easy to learn, very productive, extensive stdlib, excellent tooling, etc), but after programming with Go for three years (both embedded Linux and cloud applications), stability is the characteristic that really stands out.
Auto-formatting/linting Go code
Some things in life you just have to experience to truly appreciate the value. One of these is auto-formatting/linting source code. When I started programming in Go in Vim, I naturally looked for editor support, and found the excellent vim-go project. Through this, I learned about gofmt and then goimports. These tools can be configured in your editor to automatically format your code when you save. goimports goes a step beyond and adds missing imports and removes unused ones.
Auto-formatting is quickly becoming the norm. The Javascript world also has an excellent formatter available named Prettier. There are formatters for many other languages as well including C/C++, shell, Elm, Rust, etc. The neoformat and ALE plugins add auto-formatting functionality to Vim/Neovim. An example of how to enable these plugins in Neovim is included in my dotfiles.
Read More »Auto-formatting/linting Go codeMicrocontroller (MCU) or Microprocessor (MPU)?
As technology advances, there are two basic processing platforms for implementing embedded systems. The first is the Microcontroller Unit (MCU). These devices have varying amounts of integrated Flash (<= 2MB) and RAM (<= 1MB), and are designed to run bare-metal code or a real-time operating system (RTOS), like FreeRTOS. The second is the Linux-capable Microprocessor Unit (MPU). An example of an MCU based system is most Arduinos, and an example of an MPU based system is the Raspberry PI. An MPU typically does not have embedded Flash and RAM — at least on the same die. The fundamental difference between MCU/RTOS and MPU/Linux systems is the memory architecture and the amount of memory in the system.
Accepting Constraints in Build Systems
As Embedded Systems become more complex, the complexity of the process to build the software for these systems also increases. As humans, our ability to deal with complexity is limited, so we develop tools and processes to manage the complexity. In the end, these tools and processes are about constraints and patterns. A well-designed tool or process encourages you to do things in a way that is consistent and maintainable, which leads to reliable and predictable results.
SD Card Write Speed Tests
During Embedded Linux development, we often need to write large operating system images to SD cards for testing. Recently, I purchased a USB 3.0 SD card reader from Plugable. Before that, I used a USB 2.0 SD card reader from IOGear.
Read More »SD Card Write Speed TestsGetting started with Embedded Linux
Recently I was asked by a developer, who has done windows development for 10 years, how to get started with Embedded Linux. Embedded Linux covers a lot of ground and includes a broad range of components/skills to put together an entire system. Below are a few suggestions.
Read More »Getting started with Embedded LinuxGit, Versioning, and Branching for Embedded Linux Development
When building a product using Linux, versioning and branching of your software is an important consideration. Everyone’s needs are different depending on the size of the team, culture, and testing requirements, so there is no one size that fits all. However, after working on a number of different projects for a dozen or so different companies, there are several practices that are often used.
Read More »Git, Versioning, and Branching for Embedded Linux Development
Separation of Source and Build Directories
As we work with larger and more complex systems (i.e. Linux), more and more of our time is spent on integration and pulling different pieces together. We often need to debug or understand code we did not write — especially in build systems. To work effectively in this scenario you must be able to quickly search through a lot of source code. Therefore, we are always looking for ways to make this more efficient.
Understanding the NXP i.MX6UL Pin Mux (Part 2)
In the previous post, it was noted that bit 30 needs to be set in the i.MX6UL pad config if you want to read the state of a GPIO output. Digging into this a bit more, we find the following text in the Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt file:
SION(1 << 30): Software Input On Field.
Force the selected mux mode input path no matter of MUX_MODE functionality. By default the input path is determined by functionality of the selected mux mode (regular).
Understanding the NXP i.MX6UL Pin Mux
(note, the article is also applicable to the i.MX6ULL as these processors are very similar)
The NXP i.MX6UL application processor has a very flexible pin multiplexer, that is somewhat difficult to understand at first glance. Most times when we’re configuring the pin mux in Linux, we modify Device Tree files, so perhaps that is the place to start. The pin mux options for the i.MX6UL are defined in the arch/arm/boot/dts/imx6ul-pinfunc.h file. The arguments to the macros in this file are defined as:
/* * The pin function ID is a tuple of * <mux_reg conf_reg input_reg mux_mode input_val> */
Why Git?
Some time back, I gave a presentation that included an overview of the Git version control system. I still occasionally get asked why Git should be used instead of Subversion, as it seems harder at first. Most developers don’t really understand Git until they have used it for awhile, and then they will have an “aha moment.” There are 3 features of Git that are especially interesting to me:
- many repositories (vs. one large repository)
- distributed development
- cheap branches