If you don't have time to read the whole article, the conclusion is worth reading on its own. Has some great advice on the importance of practice for improving skills.
So you want to build an embedded Linux system?
41–50 of 113 posts
Re: So you want to build an embedded Linux system?
#42Earlier quoted context omitted.
Why would you enable swap?
I assume he sees "virtual memory", and jumps to thinking "swap". Which is rather common, but arguably a mistake. Virtual memory is what allows for copy on write pages when forking. It is the preferred basis for implementing memory mapped files. It allows for sharing a single copy of shared library in ram, without causing everything to break if one program decides it wants to patch "its" copy of the library in memory.…
Correct, this was my (apparently very widespread) misconception that I just corrected with a bit o' googlin'
Re: So you want to build an embedded Linux system?
#43I especially liked the section on DDR memory PCB routing and how it is less complicated than people make it out to be. At least for this application. Makes one want to try something like this
The part not discussed is how many PCB layers (signal, ground, more signal, more ground, etc) you need when laying down DDR. If you are playing with a 2x2" EVK then 8 or 10 layers isn't a budgetary problem. When the board starts getting larger it's now it's a huge cost adder as opposed to low speed 2-layer PCB. This is why designers switch to doing it with SOMs. The SOM can be a high-speed part and the carrier PCB is…
He mentioned all the PCB designs were using 4 layer, which is pretty cheap even in prototype quantities.
Re: So you want to build an embedded Linux system?
#44> Because C doesn’t have good programming constructs for asynchronous calls or exceptions, code tends to contain either a lot of weird state machines or tons of nested branches. It’s horrible to debug problems that occur. Linux is in C though. So, what is really going on?
Linux uses a lot of kernel threads (as well as a lot of code which runs on application threads). It's pretty synchronous in style for the most part.
Re: So you want to build an embedded Linux system?
#45Earlier quoted context omitted.
Not really. Fedora IoT only supports x86_64, aarch64, and armhfp, which has some intersection with this space, but not a lot. Regardless, that wasn't really the point of the article.
There is lots of embedded that uses x86 or arm. Lots of embedded isn't significantly power or size constrained and volumes are very low so software development costs dominate over hardware costs. But agreed, those aren't the point of the article. "Embedded" is a big space.
Something that is not power nor size constrained doesn't really fit most people's definition of "Embedded."
Re: So you want to build an embedded Linux system?
#46Can someone more knowledgeable than me elaborate on this statement? > when compared to application processors, MMUless microcontrollers are horribly expensive, power-hungry, and slow. What is it about the lack of an MMU that causes a hunger for power?
I might be wrong, but the key point between a microcontroller and a application processor is deterministic execution. When controlling a motor say, it might be vital that your interrupt handler finishes in less than 100 clock cycles.
A microcontroller usually[1] doesn't have fancy out-of-order execution, fancy caches etc as that would make the execution less deterministic in time. A MMU would as well.
Lacking these features also make microcontrollers a lot slower, and I'm guessing he's thinking about cost/watts per MIPS or something like that. Yes the application processors draw more power overall, but (I assume) they are so much faster it more than makes up for it in dollars per MIPS or watts per MIPS.
So it appears more of a symptom than a cause. But again, I might be wrong.
[1]: https://en.wikipedia.org/wiki/ARM_Cortex-M#Silicon_customiza...
Re: So you want to build an embedded Linux system?
#47Can someone more knowledgeable than me elaborate on this statement? > when compared to application processors, MMUless microcontrollers are horribly expensive, power-hungry, and slow. What is it about the lack of an MMU that causes a hunger for power?
"MMUless" was intended as a nonrestrictive modifier --- I'll remove it to avoid ambiguity. Microcontrollers tend to be built on larger processes than microprocessors are, so they eat through more active-mode power. The point I'm trying to get across is while you can run Linux on a microcontroller (which doesn't have an MMU), there's not a lot of good reasons to do so. Thanks for the feedback!
Re: So you want to build an embedded Linux system?
#48> Yocto is totally the opposite. Buildroot was created as a scrappy project by the BusyBox/uClibc folks. Yocto is a giant industry-sponsored project with tons of different moving parts. You will see this build system referred to as Yocto, OpenEmbedded, and Poky, and I did some reading before publishing this article because I never really understood the relationship. I think the first is the overall head project, the…
FWIW, I still use ltib (originally a Freescale open-source build environment) and it's mostly great. Fewer layers of abstraction, builds all the source modules using essentially the "linux-from-scratch" system, with .rpm intermediaries that get installed to a rootfs.
I played with Bitbake, but the learning curve seemed much worse than ltib.
Edit: s/yocto/Bitbake/
Re: So you want to build an embedded Linux system?
#49Shouldnt you avoid malloc and free (after the startup phase of your application) completely in long running applications?
Re: So you want to build an embedded Linux system?
#50Jay also did a great rundown of $1 microcontrollers a few years ago: https://jaycarlson.net/microcontrollers/ This embedded Linux article is a really worthy followup!
Thanks for the link on microcontrollers. Embedded writeups and microcontrollers are super fascinating.