Safety rules
The boards comprising the Embedded System (ES) development
sets used
in the laboratory need to be handled with care to avoid mechanical
damage and electrostatic discharge (ESD) problems. Therefore, a number
of additional safety precautions need to be observed:
- Before the board is touched one needs
to remove extra charges
accumulated in the body and clothes by putting both hands on a grounded
conducting element (e.g. refrigerator). Especially, one need to perform
grounding procedure after taking off a wool sweater.
- The
development set must be connected BEFORE the power is turned on.
- Under no circumstances it is allowed to place the boards on
a
conducting surface, such as the foil the boards are usually wrapped up
in, or the metal box enclosing the set.
- The
devices should be assembled in the following order:
- Connections
in the ES development set.
- Connections in the
PC or notebook.
- Additional power supply, if
needed.
- ES
development sets need to be returned neatly packed with cables rolled
up.
- The whole group will be held
responsible for any damage to the devices they used in the
classes.
Project requirements
In order to successfully pass the laboratory of Embedded
Systems
it is necessary to design and implement an application
for arbitrary
embedded system using (arbitrary) high-level programming
language (C or C++ preferable due to prevalence in the
industry). The example project topics are listed below. By no
means the list should be treated as complete or compulsory. Individual
ideas are welcome and highly appreciated. Similarly, one does not have
to limit himself to the devices available in the lab - it is possible
to use own ES set.
The projects are realized in 3-person groups with
a selected team leader.
Evaluation
:
- Difficulty level
- At
least 7 functionalities of MCU: IO ports, ADC, DAC, PWM, UART, Timer,
Interrupts, I2C,
SPI, Signal counter, CAN, embedded
Ethernet controller, USB - counts as 2, etc.; or peripheral devices:
diodes (e.g. over an extender), MMC/SD cards, displays, accelerometer,
gyroscope, external network controller, buzzer,
joystick, etc.
- Additional points can be granted
for incorporating custom electronic devices (one needs to be
prepared to explain their principle of operation).
- If the group consists
of less than 3 people it still needs to fulfill the minimum
requirements of a larger team.
In
the final grade, a multiplication factor is applied. If a group fails
to incorporate one functionality, the final result is multiplied by
6/7. If a group implements an additional functionality which
is planned in the proposed schedule
the final result is multiplied by 8/7. Should a group plan to
incorporate an additional functionality, but fails to implement it, the
result is multiplied by 7/8.
- Program evaluation
according to the assumed schedule. In order to obtain the maximum
grade, all the planned functionalities must
be
implemented.
If a
group decides to change the plan after the deadline for schedule
presentation, the grade is lowered.
- Implementation
correctness - whether the program operates without errors or flaws.
The delivered program must compile.
- Code
readability. Consistent indentation,
comments, meaningful
variable and function names, limited length of functions and procedures
(unless there is a justified reason to use longer functions), etc.
- Team work. It is verified
if all group members actually participated in the project.
The grade is lowered if some members
seem not to have contributed to the project (see also the comments
regarding the project report).
- Keeping the
deadlines - each missed deadline lowers the grade by 0.5. The
dates
given in the table are the hard deadlines (each task can be completed
earlier, but not afterwards):
| |
Task |
|
Deadline |
|
| 1. |
Choosing
the project and
delivering the schedule |
|
2nd meeting |
|
| 2. |
Mid-term
checkpoint |
|
7th meeting |
|
| 3. |
Project
delivery with complete documentation |
|
13th meeting |
|
The deadline for Task 1 is understood as the end of ES lab classes on
that day. In the other cases the deadline
is 08:00, i.e. by 08:00
the appropriate files need to be uploaded to the moodle
platform. --> The schedule needs
to incorporate the description
of individual tasks and when they will be
completed. It is insufficient to write just the
task name! An example (minimalistic) schedule is
given here.
- Quality of documentation.
- Bonus for student project idea.
Final report
In addition to the general guidelines of
creating documentation,
the following aspects should be covered:
- The description of extra hardware
incorporated by the group
together with datasheets (in separate files) and explanation
of design choices. If a group does not introduce own hardware, it must
be stated explicitly.
- The functionality
description of incorporated
elements, e.g. for
digital inputs and outputs of LPC one should specify PINSEL (in the
applied range), IODIR, IOSET, IOCLR, IOPIN; the same for other
functionalities [UART, SPI, I2C, PWM, ...], interfaces [display, MMC/SD
card, Extender, network card, accelerometer, ...],and interrupts (those
that are used, for LPC2xxx - FIQ,VIRQ,IRQ). The description
should cover MCU and peripheral registers, not the library
functions.
If a group incorporates in the
program unused functionalities (e.g.
after modifying examples), they also need to be covered in the
documentation.
- Clear specification of the
incorporated
functionalities.
- Example documentation can be found here.
The point "team work" should cover the duties and
responsibilities of each group member.
The final report (but also the checkpoint files)
should be uploaded by the team leader to the moodle
platform together
with:
- complete program source code
- executable file (hex)
- additional
files (e.g. datasheets)
How to succeed?
The chances of successful completion of the project increase
if:
- You start working on the project right
away at the first class (not halfway through the semester).
- The responsibility for implementing functionalities is
distributed among different team members (e.g. Member 1: diodes,
buttons, Bluetooth; Member 2: LCD, joystick; Member 3: UART, memory).
- You come prepared, i.e. appear in the class already
familiarized
with the specific technology or device (documentation and code samples
analyzed), bring preliminary code snippets to test in the lab, etc.
- You start working on more involving functionalities early
enough.
How to fail?
The chances offailure increase if:
- You start working on the project with
delay (not from the first class).
- Everyone does
everything.
- You
come unprepared (begin thinking of the project during the class).
- You leave the hard stuff for the last week.
- You
spend to much time on things not related to the project itself,
e.g. preparing programming environment, configure different
platforms,
etc.
Helpful literature
In order to familiarize oneself with the programming concepts
of LPC2000 family of microcontrollers, one may look into The Insider's Guide to the
Philips ARM7-based Microcontrollers, or The Insider's Guide to the
NXP LPC2300/2400 Based Microcontrollers (registration
required). In Polish, one may refer to the book Mikrokontrolery
LPC2000 w przykładach (Emil Stawski) [available in the Institute's
library].
Other
O'Reilly Programming Embedded Systems With C and GNU
Development Tools 2nd ed. Oct.2006
Building
Bare-Metal ARM Systems with GNU
Description
of LPC microcontrollers (user guides, datasheets)
Initialization
code generator for MCU with the ARM core
Development tools
It is recommended to use the development environment and tools
installed in the laboratory. Below you will find the list of tools for
those wishing to set up the environment at private computers.
| Compiler, linker, etc. (toolchain) |
| GNU
#1 "Files" section. |
Version compiled
with eabi#0 |
| GNU #2
"Files"
section. |
Version compiled with eabi#0
Occasionally, the page is redirected to yagarto project. |
| Version
installed in the laboratory |
Set appropriate
paths!!! |
In
the system, only ONE version of the cygwin1.dll
library is permitted. |
| yagarto
|
Version compiled without eabi. |
| www.codesourgery.com
|
Reference compiler version (installed in the
laboratory). Compiled with eabi#5. |
| In all the cases, one must
install
version big endian and libraries to the thumb
mode. |
|
|
Additional
tools (program make and utilities) |
| cygwin |
Front-end of Linux ported to MS Windows. Version
prepared for
the ES laboratory can be found here
- one only needs set the paths. It is recommended to place cygwin
directly in the main drive. In any case, the folder name must not
contain spaces. |
| cygwin
version lite |
Remember about the cygwin1.dll
library. |
| Freddie
Chopin version |
Version not requiring
cygwin libraries. |
|
|
| Eclipse |
| Eclipse |
Lab
version of Eclipse (with all the requirted drivers). Workspace can be
found here. |
|
|
| VirtualBox |
| VB |
The
archive contains disk image. After unpacking you need to:
- set the swap file,
- move appropriate USB devices to the virtual
machine environment
- launch.
|
|
|
| Operating systems (not really
indispensable) |
| System
Embedded Artists |
Example programs
prepared by EmbeddedArtists
use the indicated system. |
| www.FreeRTOS.com |
Free OS. Educational program for 2148 microcontroller
ported
to the system in version 5.1.1 can be found here.
Executing the «thumb» or «arm»
loader will
create appropriate image for the microcontroller if
«make»
utility is installed properly. |
| ChibiOS/RT
|
Very good (and small!) OS for microcontrollers with the
ARM
core. |
| CooCox
OS |
Very good (and small!) OS for microcontrollers with
the Cortex core. |
| Salvo
OS |
Compact OS for microcontrollers with Cortex and
ARM7TDMI
cores. |
|
|
Drivers and utilities
Example project topics
The project should incorporate communication between different
devices, e.g. PC, PDA,
mobile phone (WM2003, Symbian, etc.), but it is recommended to
incorporate an ES development set. Different groups may choose the same
project topic, but it must be implemented on different devices.
- Morse
code decoder, appropriate relations among dots, dashes, and
spaces should be found in documentation
-
Reflexes,
check player reaction (pressing appropriate button, or selecting
joystick position) to diode (or display) signal, ES should measure the
time and quality of the player performance, and send statistics to a
server. The values should be displayed an the ES screen.
-
Alarm
clock, setting of the date, time, and alarm time using short
and long button pressing, use RTC clock.
-
Arkanoid
with communication
-
Boulder
Dash
- Snake
-
Shift,
see here
-
Twin
Spin, see here
- External
memory, install appropriate card in the SD module
and provide access to the card contents through an USB interface
-
RADIUS
server with configuration on an SD card
Common materials for ES based
on the ARM
microcontrollers
You can find description of
the
available equipment here.