Very detailed article listing trade-offs, opinions about various SOCs, etc:
https://jaycarlson.net/embedded-linux/
It appears Jay actually designed a board for each one of these chips!
That’s a great article! That someone would spend enough time to custom design this many PCBs and document the things they found is great!
It’s clear that the author came at this from a hobby or junior engineer perspective rather than a “we are going to make a million of these” perspective, though. The comments about DDR3 routing being easy, partial understanding of some of the errata and differences between revisions of silicon, comparing things by Digi-Key pricing, and lack of willingness (and I’m sure time) to investigate the nuances of some of the chips shows though. But still a very impressive piece.
It’s unfortunate that there’s not better examples of how to really leverage the TI PRU cores. They’re supremely powerful and can even replace the need for some FPGA implementations, that you can get them in such a cheap chip that also runs Linux is just great. Plus, each iteration of the TI AM-series SoC mostly keep backwards compatibility as the PRU abilities increase (AM18xx->AM335x->AM437x->AM57xx->etc all have PRU and the core concepts of how they work are very similar but the abilities and instruction set does evolve over generations).
Interesting comment about the rPI in the above article:
What about a Raspberry Pi?
I know that there are lots of people — especially hobbyists but even professional engineers — who have gotten to this point in the article and are thinking, “I do all my embedded Linux development with Raspberry Pi boards — why do I need to read this?” Yes, Raspberry Pi single-board computers, on the surface, look similar to some of these parts: they run Linux, you can attach displays to them, do networking, and they have USB, GPIO, I2C, and SPI signals available.
And for what it’s worth, the BCM2711 mounted on the Pi 4 is a beast of a processor and would easily best any part in this review on that measure. Dig a bit deeper, though: this processor has video decoding and graphics acceleration, but not even a single ADC input. It has built-in HDMI transmitters that can drive dual 4k displays, but just two PWM channels. This is a processor that was custom-made, from the ground up, to go into smart TVs and set-top boxes — it’s not a general-purpose embedded Linux application processor, so it isn’t generally suited for embedded Linux work.
It might be the perfect processor for your particular project, but it probably isn’t; forcing yourself to use a Pi early in the design process will over-constrain things. Yes, there are always workarounds to the aforementioned shortcomings — like I2C-interfaced PWM chips, SPI-interfaced ADCs, or LCD modules with HDMI receivers — but they involve external hardware that adds power, bulk, and cost. If you’re building a quantity-of-one project and you don’t care about these things, then maybe the Pi is the right choice for the job, but if you’re prototyping a real product that’s going to go into production someday, you’ll want to look at the entire landscape before deciding what’s best.
There is much more to embedded systems than processing power and price. Some other things to think about:
- will the company support you? – companies like Microchip do this very well. Other companies won’t bother with you unless you are shipping a gazillion units.
- is support in mainstream repos? – are there ongoing efforts to upstream support for the processor? Otherwise it will likely be abandoned and you will be stuck with kernel version x.y.z forever.
- is the company open? – do they work in the open with public Git repos?
- is the processor well stocked in distribution? – if you can’t get it, it won’t do you much good!
NXP i.MX processors are a fairly safe bet, as is anything from Microchip. However, price, performance and other considerations sometimes prompt us to wander off these well traveled paths …
A SOM module also mitigrates some risk if the company building the SOM is willing to support you.
So I was asked recently about the rPI CM4 – what are your thoughts about this module?
Interesting comment about the PRU cores – I’ve not designed TI chips into projects for a long time (lately most projects have been i.MX). Does sound like a neat idea. You’re right though – tooling matters a lot – if stuff is a pain to use, no one will.
It’s interesting if you’re main goal is to drive a digital sign. They claim they’ll make them for quite a while and the form factor and IO break out seem to fit very nicely for connecting to a big screen to display digital media.
Obviously it’s not a good fit for anything industrial or many commercial specialized applications, but as a media processor for a lower volume manufactured product (ie <10k units/year) it’d be a decent choice.
That you can get a modular certified wifi, up to 8GB of RAM, and a decent selection of eMMC sizes only makes it more compelling for digital media use cases.
The TI PRUs have decent tooling around them, if you use TI’s Code Composer Studio and toolchain. There’s even pretty good documentation on how to code for them. TI has been happy to offer training at my previous company when we asked about it.
I think it’s just that many people haven’t really used the PRU and the way the PRU works is different enough from a normal microcontroller that not very many people have decided to write “open/free” code or to write about the PRU in general on blogs. The PRU can solve very interesting problems basically for free (it comes in the SoC and often you can’t buy the SoCs without them), but many times there’s other easier to understand ways to also solve these problems.
Jay discusses this article on the Amp Hour podcast:
It is pretty good!
Also, the original article continues to be updated along with comments at the end – a good place to get a feel for various Embedded Linux MPU options.