6. Make

Loading...

Del curso dictado por University of Colorado Boulder

Introduction to Embedded Systems Software and Development Environments

107 calificaciones

University of Colorado Boulder

Introduction to Embedded Systems Software and Development Environments

107 calificaciones

Welcome to the Introduction to Embedded Systems Software and Development Environments. This course is focused on giving you real world coding experience and hands on project work with ARM based Microcontrollers. You will learn how to implement software configuration management and develop embedded software applications. Course assignments include creating a build system using the GNU Toolchain GCC, using Git version control, and developing software in Linux on a Virtual Machine. The course concludes with a project where you will create your own build system and firmware that can manipulate memory. The second course in this 2 course series , Embedded Software and Hardware Architecture, will use hardware tools to program and debug microcontrollers with bare-metal firmware. Using a Texas Instruments MSP432 Development Kit, you will configure a variety of peripherals, write numerous programs, and see your work execute on your own embedded platform!

De la lección

Compilation with GCC and GNU Make

Module 2 will introduce the learner to the software development build system. Most software engineers are very knowledgeable about their build system as we need them to translate our high-level software languages to our architecture specific implementations. There are some important platform and architecture concepts that are introduced in the build system to help enforce good software design techniques. Learners will create their own build systems and utilize build tools to analyze their embedded software implementations.

1. Introduction to Build Systems using GNU Toolsets6:49

2. Compiling and Invoking GCC11:23

3. Preprocessor Directives10:10

4. Creating Header and Implementation Files9:53

5. Linkers11:03

7. Makefiles Part 17:02

8. Makefiles Part 210:27

9. Other Useful GNU Bin Tools5:41

Conoce a los instructores

Alex Fosdick
Instructor
Electrical, Computer, and Energy Engineering

Welcome back.

In this video we'll be talking about how to create a build system to simplify and

improve our process of building a software target.

The process software teams used to create a software product

using a lot of tools to build, test, and version and develop code.

Teams usually consist of many engineers trying to build software in a similar or

consistent way.

However this process can be very tedious.

So far, we have learned that there are numerous commands and

many flags that are needed for our advanced use of the command line tools.

To memorize all of these options is not feasible.

Next, software companies and projects usually support multiple build targets and

architectures, both of which affect how we build.

Now the concern has to do with the large number of source files

a typical software project will contain.

Let's look at the example of the Linux Kernel.

This software repository contains over 40,000 software

files involved in the built process.

It is because of these reasons and more that the process of iteratively

building a file by file is not scalable for large teams or software rebus.

A chance for human error to produce inconsistent builds increases greatly as

developers are spending more time in generating builds and

less time in development.

If we compare these concerns with our IDE build process,

we do not see any differences.

Behind the scenes the IDE is running any other same compile commands for

every single source file you have added to your project and each with many options.

Each compile or

link command that is issued takes hundreds of characters with over ten flags.

Luckily there are tools that hep simplify both command line and

IDE building with the help of build automation using make.

Build management software functions to provide a simple mechanism to control and

build consistent target executable images for your software applications.

Build management, build generation and

build automation are all terms that can be used in a changibly to meet this function.

As you recall,the build system in campuses the process of preprocessing,

assembling,compiling,linking and relocating.

No difference from our previous tool use is our build generation to our

use make Make is yet another free tool we get from the GNU

tool chain that is utilized from the command line in the exact same way as GCC.

It lives in the executable program binaries folder on Linux and

has many options just like GCC did.

One big difference is that it is not part of the GCC tool chain

as it is independent of the Compiler or the architecture you're using.

Therefore there is no arm-none-eabi prefix to the command.

This is a good thing since it provides more examples of software abstraction and

independence for our course as we want to build a tool

that can support many types of compilers and architectures.

The GNU Makers formally defined as a tool that controls generation of executables

and non-source files of a program, from the program source files.

This is very important because we can use GNU Make to do more than just compile but

also generate software dependencies, statistical information and

many other items.

Best of all it's free.

Careful and educated use of this tool can help you create an extremely consistent

software built With very low developer time for compiling.

Let's look at applying Make to a typical GNU Toolchain and

the software development environment.

GNU Make can be thought of as an extraction interface to building.

You still have all your source files, your linker file and libraries.

You still need to produce an executable image.

What major difference here is the use of one or more Makefiles.

This Makefile provide special directions and procedures

to make in order to create an executable file from a multitude of input files.

Each make file contains specific recipes for building particular targets.

These recipes usually have some dependencies and

produce some type of output.

Think of including header files and C files as dependencies for

a recipe to build a particular object file.

These dependencies can be auto-generated and output to .dep or

.d files automatically by make.

In order to build a particular target, you can do so

if it's a symbol of two words at the command line.

This method of building is similar to scripting.

We could invoke make and

we can execute many define targets with just the single command.

Each target can follow a particular recipe depending on how you defined your targets.

Typical targets you might see are direct object partilation, complete build and

a clean which removes all generated files Make can be configured to

use whichever Complier Toolchain and build process of your choosing.

You could use vendor provider toolchains or

continue to use GCC as the toolchain with the same process

to generate files that we did with our five steps of building.

Make could even be configured to support multiple versions of a compiler or

even multiple compilers with the same Makefile.

Further, the same object files, Dependency Files and Map File

can output from the process of Make with careful structure of your Make system.

You might be asking, how does the command-line Make system

differ from what we did with our integrated development environments?

A fundamentally did the exact same thing

IDEs provide multiple Makefiles filled with many options and targets.

And they compile many source files producing an executable output file.

The one difference in writing our own Makefiles versus using an IDE

is that the IDE is going to auto-generate their Makefiles depending on

how you configured your software project.

Meaning it will generate all of the specific flags and linker files for

the guards to your architecture.

This is good for parading a very simple interface for

developers wanting to start fast.

But very bad for maintainability and portability.

Most software teams implement their own make system, and version control, so

they have a method of controlling when a portable, consistent build system,

that can work over a variety of architectures of their own design.

Here we have a short demo on how simple make is used.

In the following video's I'll go into details about what is exactly happening

because of that makefile.

But we're going to keep this demo simple.

Listing all the files in this directory see that we have three sources,

two headers and two Makefiles.

One Makefile is used as our main Makefile and

the other is used to track what are target source files are.

This makefile supports a small set of targets including all clean and

individual file built.

Each of these build files that are associated with that build process or

recipe when you run them and this is listed inside the make file.

In addition, I provide inside this make file a subset of

options to run with each of these GCC commands.

If I run make all,

this will perform a complete build to create an executable output file.

The term all which uses an arbitrary name for a compile all type of target.

As you can see all individual compile command were run for each file.

In addition a final link command was run.

We can see that the current directory now contains of these output files

from the build process.

Next I'll run make clean command.

Which will remove all of my generated files,

thus cleaning my build directory from all of my non-source files.

This will run a basic remove command that deletes all of the generated files.

You must be careful with how you implement clean,

because you do not want it to remove source files or other important files.

After running this the director has been cleaned.

Last we can also define our build targets to run individual build files

like the generation of the main.o object file.

We could do this by running make main.o,

as you can see only a single command was issued for the build and

all the appropriate command options were put in there.

Leaving in this folder a single main.o file.

Built systems are very important for software teams.

Without them, the process of creating a complex target executable

would be very tedious and error prone for typical developer.

There are many build generation systems out there besides make but

make is still widely used today.

Build systems allow for abstraction from the target software and architecture, so

that they are portable and can be added to version control.

This provides a mechanism for teams to create consistent builds over time

without loosing any information about what the configuration of their build was.

Next, we will look into how to create our own name files.

[BLANK_AUDI O]

Explora nuestro catálogo

Inscríbete de manera gratuita y obtén recomendaciones personalizadas, actualizaciones y ofertas.

Coursera brinda acceso universal a la mejor educación del mundo, al asociarse con las mejores universidades y organizaciones, para ofrecer cursos en línea.

© 2018 Coursera Inc. Todos los derechos reservados.

Descargar en la App Store

Consíguelo en Google Play