The other day, I was browsing Embedded.com and came across Trends in embedded development: a Mouser perspective by Mark Patrick, who’s a UK-based technical marketing manager for Mouser, a major distributor of semiconductors and electronic components. This is a topic of obvious interest to me, so I thought I’d share a Critical Link perspective. (I don’t know Mark, but we are partners with Mouser, which distributes some of our SOMs and Development Kits.)
The growing chip- and board-level integration trend
In the first section of his piece, Mark talks about key aspects of the growing chip- and board-level integration trend. It’s hard to argue with his opening line that “any embedded design today is significantly different from those twenty years ago.”
Think back those twenty years. Yes, the Internet, as predicted, was already starting to change everything. And, yes, the term “Internet of Things” had already been around for a while. But the IoT as we came to know it didn’t really start taking off until the mid-2000’s. Now, well, just about everything is connected (or at least could be). And users are more demanding of the interface look and feel. So I think Mark nailed it by focusing on connectivity and display requirements.
Firstly, connectivity is paramount, which adds extra functionality and emphasizes security. Also, as users, the level of interaction we expect from an embedded system is high, whether with our smart devices, in our car, or at work. No longer will a couple of LEDs suffice; some form of sleek display, no matter how small, and a functionally rich user interface, have become the norm. These two features alone – connectivity and a display – introduce many conflicting design constraints, such as minimal size and power consumption.
As well as budget and time-to-market pressures. Mark discusses a couple of ways that engineers deploy board level integration to satisfy these constraints: the use of wireless (RF) modules, wireless systems on chips (SoCs), and DC/DC converters. Another obvious answer is System on Modules (SOMs).
Connectivity and display both directly drive the need for a microprocessor (as opposed to a microcontroller). And this drives the need to design a dense SoC device with difficult escape routing and DDR. DDR is both a routing and a signal integrity challenge, which can put working with it above the skill level of an engineer who has only designed with microprocessors in the past. A good answer: design with a SOM!
Connectivity and display requirements can drive the need for a higher-level operating system, like Embedded Linux, which may also be new ground for an embedded engineer.
What to look out for when it comes to connected devices
When it comes to connectivity, Mark’s focus is on wireless.
From a user’s perspective, we take connectivity for granted and expect it to work reliably. For the engineering team, however, provisioning wireless connectivity opens a checklist of requirements. Questions include the range, how much data, how frequently, interoperability, and how the application will be powered. In turn, this helps guide the choice of wireless protocol and topology.
There is a lot to selecting a technology to use for a wireless solution, and matching requirements to different protocols can be a challenge. Accessing experience in these areas is definitely helpful. This is where s can help a lot.
Another key consideration when developing wireless is FCC certification. If you’re doing your own ground-up design, this is an expensive and time-consuming endeavor. Wireless modules come with this certification which can be a big time and money saver for designers.
It’s a big open field that engineers can choose from for the technologies they’re going to use. As Mark notes, engineers will tend to go with what they know and what’s comfortable for them. We see this with repeat designs for customers using our SOM modules. Not only do they get to know how to use our module, but they get to know us and how we support them through the process.
How virtual working will impact the future of embedded development
In the final section of his article, Mark notes that embedded development lends itself well to collaborative (virtual) work, and offers a roundup of the tools available to those working virtually: GitHub, PlatformIO, Microchip’s MP Lab X, Arduino’s ‘Arduino Editor,’ Edge Impulse, “’low code’ pseudo languages such as Node-RED that supplement traditional embedded development languages like C,” and MikroE’s Planet Debug service.
The issue I see is not any lack of development tools for remote, virtual working. Many of them have been around for a while. I see the issue being more one of “is everyone on the same page”, with the same understanding of the requirements. Are the requirements even well fleshed out? This is much more about team communication and remote teamwork, which is being tackled across all industries and functional areas – not just embedded development.