ARM

In the past I have written on the advantages of minimal development environments (read: Makefiles and GCC, no IDE, minimal abstraction layers) for ARM processors. One of the advantages of working this way is easy integration with existing processes such as build systems, production line, testing, etc. Using this in a virtualized environment also allows one to make sure every developer uses the same tools, and that the tools are tested and qualified for the intended project with a ready made virtual image available for each developer. They can then add their favorite editor and user interface, but the underlying build environment is fixed for everyone and archived as such on a per-project basis. This means that if a customer comes back a year or two later and wants to make a change, all the tools are there as we left them ready to make the change. In this blog post I'll write down a possible scenario for a typical STM32 project, in this case using a NUCLEO-L152RE board as a target. It should be easy to adapt to other STM32 boards/chips, and in general other ARM microcontrollers as well.

The STM32 line of microcontrollers offer a bunch of features in a nice package at reasonable cost, something I like. What I don't like as much are the development libraries around it provided by ST. For this reason, most of the time I stick to writing code using the 'Cortex Microcontroller Software Interface Standard' (CMSIS) and the datasheet, and this works nicely but can be slow to develop. While it's still my personal favorite, I recently checked out the other options to see where things are going to do the prep work for some ports of older projects built using the 'Standard Peripherals Library' to newer processors such as the STM32L4.

Some time ago we had a project which needed a simple transparent caching proxy for use in classrooms in Latin America. The classroom desktops consisted of ten of our Efika's, and we thought why not use an extra one of those to act as the proxy. This is not the kind of high bandwidth environment of a typical installation, so the performance limitations were not really an obstacle. The goal was rather to use the limited internet connection available as efficiently as possible. The configuration of the system using Squid is detailed below.

The Freescale Technology Forum is well underway here in San Antonio. We have a booth where Genesi are showing our latest developments and systems. I'll post some pictures later, but for now here is an interview with Konstantinos explaining some of the work we're doing on ArmHF.