Tag Archives: firmware

Toolchain over a Cup of Coffee

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

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