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!
6. Make
Loading...
Del curso dictado por University of Colorado Boulder
Introduction to Embedded Systems Software and Development Environments
114 calificaciones
University of Colorado Boulder
114 calificaciones
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.
Conoce a los instructores
Alex FosdickInstructor
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.
