Category Archives: Embedded Systems

Embedding Software into Hardware Systems

Toolchain Setup

4 Replies

This is the third article in the series dedicated to the world of Embedded Systems.

<< Previous Article

“Shall we meet now to further our discussion?” was a text on Pugs’ mobile.

“Where?”, asked Pugs.

“Office Park”, was the reply back from Shweta.

I’ll be there in another 5 minutes.

In the park, “No-thanks, for your time”, were the first words from Pugs.

You won’t change.

Do you want me to?

“Let’s come to the topic – toolchain”, was a change of topic from Shweta, while opening her laptop. “So, your question was, why different toolchains, for different embedded types (BS or OS based), even if they are for same architecture”, she continued.

Wow! You remember my doubt.

Now, to understand that, let me first tell you a bit about the nomenclature (naming conventions) of the toolchain prefix. A native toolchain will have commands like gcc, as, ld, objdump, etc. However, as soon as it is a cross toolchain, a cross compile prefix is prefixed with all these commands as <prefix>-gcc, <prefix>-as, <prefix>-ld, <prefix>-objdump, etc

Yes Yes. I know, e.g. arm-linux-gnueabihf- is prefixed to provide commands like arm-linux-gnueabihf-gcc, arm-linux-gnueabihf-as, etc.

Yes. But the prefix is not random, it is derived based on some naming convention.

O really! What is it?

The prefix is typically created using the following format: <arch>-<vendor>-<os>-<abi>-, where <arch> represents the architecture for which the toolchain would generate the code, <vendor> would be the vendor who created the toolchain, <os> would be the operating system for which the toolchain creates the executable, <abi> denotes the application binary interface (ABI).

What is this application binary interface?

It is an understanding or protocol of interfacing / communicating between the C code (application), and the assembly / machine code (binary). As examples of this protocol, in which CPU register or how in stack would the corresponding parameters of a C function would be placed, where would the return value of a function be placed, floating point computations would be hardware based or in software, etc.

Okay. So, you mean to say, depending on the toolchain, this understanding may also change.

Yes. That’s why, you typically need to compile all software used together with the same toolchain. Examples of ABI are Embedded ABI (EABI), GNU’s EABI (gnueabi), GNU, ELF, etc. And if they incorporate hardware based floating point operations, an “hf” may be suffixed, e.g. gnueabihf.

Hmmm. Examples of <arch> in the prefix would be arm, aarch64, armv8l, etc, right?

Yes. And <os> could be linux or none, if it is for baremetal.

<vendor> could be linaro, right?

Yes. However, in the prefix, many a times the <vendor> is omitted. And even <os> could be omitted if it is none.

Wonderful. So, just by observing the prefix of the commands in a cross toolchain, we can deduce many things about it.

Yes. Just check out some examples here: https://releases.linaro.org/components/toolchain/binaries.

There are so many versions here. Which one?

Say 6.5-2018.12. So, go to: https://releases.linaro.org/components/toolchain/binaries/6.5-2018.12, and you’ll see the following:

Toolchain List

Yes. I see there are 3 ARM related toolchains. arm-eabi must be for baremetal, and arm-linux-gnueabi* are for Linux based builds – one with soft float and one with hard float gnueabi.

Excellent. Now, each one of them is available for various host systems – systems where we are going to run the toolchain. As my system is a 64-bit Linux system, I’ll download & install the corresponding arm-eabi and arm-linux-gnueabihf toolchains. One may choose other options in case of different host systems.

Why did you choose two toolchains?

You only wanted, to understand why two different toolchains for the BS and OS based embedded systems, right? So, I’ll setup both and then show you the differences by experimenting with them. And that would answer your question.

Okay. Okay. But, these are tar files, right? How to install?

Just untar them, say under /opt, as follows:

$ sudo tar -C /opt -xf gcc-linaro-6.5.0-2018.12-x86_64_arm-eabi.tar.xz
$ sudo tar -C /opt -xf gcc-linaro-6.5.0-2018.12-x86_64_arm-linux-gnueabihf.tar.xz

And then add their executables’ paths in the PATH variable, by adding the following lines in ~/.profile or ~/.bash_profile (as appropriate):

export PATH=~/GIT/bbb-builds/Downloads/gcc-linaro-6.5.0-2018.12-x86_64_arm-eabi/bin:${PATH}
export PATH=~/GIT/bbb-builds/Downloads/gcc-linaro-6.5.0-2018.12-x86_64_arm-linux-gnueabihf/bin:${PATH}

I guess in debian based systems like Ubuntu, we need to add in ~/.profile, and in other rpm based systems in ~/.bash_profile.

Typically, yes.

But these profile files get sourced only when we login, right?

Yes. And so, now after doing the above, I am logging out.

With that Shweta does a logout in her laptop, and then does a login back.

“Now see, the various commands are available on the konsole”, Shweta continued, while showing her screen, after typing arm- and pressing the tab key on her konsole:

Toolchain Commands

Good. Now, like I use gcc and other commands, I can just use these instead.

Yes. With this, we are all set to use the two toolchains, which I’ll use on a simple C program to demonstrate you the differences between the two toolchains, which will clarify “why two”. Meanwhile, why don’t you get your laptop and set it up, to explore alongwith me.

O Yes! That’s a good idea. Let me get it.

With that, Pugs’ goes to fetch his laptop.

   Send article as PDF   

Toolchain over a Cup of Coffee

2 Replies

This is the second article in the series dedicated to the world of Embedded Systems.

<< Previous Article

“Wow! You are already there”, pulled Shweta on Pugs.

“Has to be. As an obedient student, how can I keep my guru waiting for me”, was a naughty reply from Pugs.

Okay. Ok. So, what were we discussing about?

Two categories of Embedded Systems.

O yes! Baremetal Software (BS) based, and Operating System (OS) based. In BS based embedded systems, the firmware is the only software component. It has its own pros & cons. As being the minimal software, it typically yields better control of timing & performance. But the downside is that it is a development from scratch. Everything and anything needed has to be designed and developed – no software logic can be assumed to be there.

Wow! That would be amazing, right? One would get a feel of the days, when the first software was written.

Similar to that. But not exactly. As when the first software was written, it was written directly using the CPU instructions aka machine codes.

Yes. Yes. Nowadays, we write in C, or other higher level languages.

Yes. But even then, it ultimately needs to get converted into machine codes. So, for that we would use a compiler.

Yes that I know. But what is a cross compiler?

See in general, you run a compiler on your x86 desktop to generate the machine code for your x86 system only, i.e. you compile the code for your native system itself. However, embedded systems typically have non-x86 architectures like ARM, PPC, MIPS, etc. But we still wish to compile the code for them on our desktops, instead of compiling it on the embedded system.

Why is that so?

Because of the usual embedded system restrictions, and ease of development on our familiar desktops. In such scenario, we need to have a compiler which runs on a x86 system (typically referred as a host system), but generates the machine code for a non-x86 system (typically referred as a target system). And such compilers are called cross compilers.

So, a compiler where the host and target are not same is called a cross compiler.

Exactly.

So, say I am somehow able to do compilation for my ARM based target system, on the target system itself. Then, wouldn’t it be a cross compiler?

Yes, it wouldn’t be – it would be just an another native compiler, though ARM based. As then, your compiler would run on an ARM system and generate code for the same system. And why somehow? When you have a complete Linux distribution running on an Embedded System, you can easily have the ARM based native compiler in there.

Got it. Then, what is this so called (cross) toolchain all about?

When we talk about a (cross) compiler, we are referring to a single software (tool) that converts say C into machine code. But typically to do that there are many other related tools, which are used, like an (cross) assembler, (cross) linker, etc. Moreover, there are many other related utilities, which are useful in development, like (cross) objdump, (cross) nm, etc, grouped together as binary (lowest level output) manipulating utilities aka (cross) binutils. All these set or chain of tools put together is called a (cross) toolchain.

O! That’s all – just for the name of a toolchain.

It’s not, that’s all. A toolchain is a topic in itself. Developing a specific toolchain involves many things, and multiple iterations. Just to give you an idea. Toolchain is after all a software. So, what do you think it is written in?

C, I guess.

Nowadays, yes. So, we need to have a toolchain, to compile a toolchain.

That’s okay. We may use other already built toolchain, right?

Not that straight forward. There may incompatibilities with that. As a toolchain consists of a set of libraries, OS dependent headers, etc, which may be different for different versions.

So, what do we do then?

We first build a minimal version independent toolchain using an existing toolchain, and then use that to build the complete toolchain.

Interesting.

And involved.

But then, how would have been the first toolchain built?

Possibly using a C compiler not written in C, but assembly.

And that would have been assembled using an assembler. And then continuing down further, the first assembler would have been written in machine code itself.

Excellent.

That’s why. Rather than building toolchain ourselves, we typically, get these ready-made from some websites, right?

Yes but they are not just websites, rather full-fledged companies built around toolchains. For example, Linaro.

Makes sense.

However, there are full-fledged build systems to build complete Linux distributions, like buildroot, yocto, etc, which in turn build their own toolchains in an automated fashion, taking care of all the complications involved.

Wonderful. Based on our discussion, what I understand is that irrespective of the embedded system type (BS or OS based), we would need a toolchain for its software development. And it is upto us, whether we download the pre-built ones, or build ourselves – manually or preferably using build systems.

Yes. But depending on the type, the toolchain may vary. And note that the build systems may be able to generate the toolchain only for an OS based embedded system.

“Yes, I can see there are broadly two types of toolchains on the Linaro website”, quipped Pugs browsing the above link. “But why do they need to be different. Finally, they are going to be generating the machine code for the same architecture – isn’t it?”

I need to go now. Some other time on that.

When?

I’ll message you.

Next Article >>

   Send article as PDF   

Embedded Systems for your Boy Friend

3 Replies

This is the first article of the series dedicated to the world of Embedded Systems.

<< Previous Story

“Hey Pugs!”, was a slow whisper from Shweta from her cubicle.

“Shweta!!!”, was the only word which came out of Pugs, as he turned around in the aisle.

“What a surprise! After so long! How come you are here?”, came out a burst of statements from Shweta. It was not unexpected, as she has seen Pugs after a long gap of 6+ years, since they have graduated out from the college.

“How … how come you are here?”, stumbled out some words from Pugs.

What “how come”? I work in this office. What about you?

I just joined today, and HR was just taking me around.

Great! I don’t have words to express my feelings seeing you after so long. Do you mind if I take you around, rather?

I don’t have one to mind.

Pugs, you haven’t changed a bit.

You too look the same.

Thus went on, a seemingly unending chat between the duo, while strolling in and around the office.

And then, “What are you working on?”, asked Pugs.

Embedded Systems.

Wow! Where do you embed the systems into?

Are you joking?

Not really. I have been majorly working in the desktop world. Heard about this and other related jargons. But not really very clear about what really it is all about so called “Embedded Systems”. So, could you please teach me?

That was surely a joke. I remember our college days, how I used to learn from you.

So what? Knowledge and Learning knows no gender, time, and place. Anyone can teach. Anyone can learn. Whenever they want. Wherever they want. So, you are my Embedded Systems mentor.

Okay, dude – as you wish – you haven’t stopped giving gyaan. So, as such, any hardware system which is intended to do a specific task, or a specific set of tasks(, with some software embedded in there) can be called as an Embedded System.

You mean to say my hand watch, cafeteria’s micro wave oven, this printer, etc are all embedded systems, as they are meant to do their pre-designated specific tasks.

In a way, yes. Also, typically when we refer to something as an embedded system, it implies that it has some kind of software embedded in there as well.

Hmmm! And that is where the name “Embedded Systems” comes from. So, if it is purely hardware like the watch, then we may not call it an embedded system, right?

Traditionally yes. But nowadays the line has become so thin, that even a system seemingly to be a pure hardware system, has some software (embedded) in it, in some form or the other. For example, your watch itself is not a pure hardware – it has enough software to say, sync it with your mobile.

I see. So, what about the mobile phones? Can we call them embedded systems? They have both hardware and software. But they are not meant for any specific tasks. They are like a desktop only.

In its initial evolution, a mobile definitely used to fit in the above mentioned definition of an embedded system – hardware plus software meant for specific task, as it was specifically meant for telecommunication only. But as the world of such embedded systems evolved, the definition also evolved to encompass a wider variety.

And with this new definition, can mobile phones be still called embedded systems?

Yes.

I know. In this expanded definition, any hardware plus software system which needs to operate under constraints of limited resources is called an embedded system.

Correct. Now, how do you know this?

I keep reading many articles around. But now I have a doubt. Nowadays, we see that even such constraints are possibly going away with embedded systems having huge memories, powerful processors, etc, comparable to the desktop world. So, should they be still called embedded systems?

Even with those, don’t forget that, at the least, the constraint of miniaturization is day by day increasing only. Hence, this current definition should be good enough for at least some more time to come.

That seems reasonable. Now, when you say all embedded systems have some kind of software in it, I assume it need not be an operating system based one, right?

Yes. In fact, it can’t be. As many such systems have very limited memory and storage, not enough for an OS. And that is where, all embedded systems can be broadly classified into two categories:

  • Baremetal Software based, i.e. the ones without the Operating System
  • Operating System based, i.e. the ones with the Operating System whether RTOS, or a full-fledged one

RTOS meaning Real Time Operating System, right?

Yes.

What is then this so called “Firmware”?

The baremetal software, i.e. the software in the OS-less systems is often referred to as “Firmware”.

Oh I see! So much for that jargon. You have just de-jargonified it for me. No thanks to friends.

Good to hear that.

Can you also give me an overview of the software development process in these two categories of embedded systems – with and without OS?

Sure. But not now. I need to finish some of my work. How about discussing that over a cup of coffee?

My pleasure.

Next Article >>

   Send article as PDF