EEE3074W: Embedded Systems
|Times and Venues||Outcomes and Syllabus||Recommended Books||Details|
Scope: This page tells you
course structure and syllabus for EEE3074W.
I'll take the risk of scaring you right from the "get go", with one
of my favourite quote by the naturalist
and conservationist, John Muir:
"When we try to pick up anything by itself
we find it is hitched to everything else in the universe."
-- John Muir
I think this quote nicely expresses the challenges that an embedded system engineer encounters on a daily basis... both at the job, in the park, and especially after a coffee break. This quote, by no coincidence, also captures the broad concept of General Systems Thinking (GST), also known as (aka) General Systems Theory. I favor a symbiotic systems view of systems, as apposed to resorting immediately to Knut and company's mechanistic paradigm that involves deconstruct first, and ask questions later. Consequently, my chosen definition of a system is as follows:
The telecommunications network is one of my favorite examples to illustrate this "symbiotic systems" view: consider the many different cell phone companies in this country, and Telkom. It is vital that the systems managed by these desperate network providers operate together effectively, in order to ensure that any one company can provide their clients with the functionality that they require (in this case the main requirement is that the client needs to be able to place a call to any phone in the network).
EEE3074W follows a systems* approach to embedded system development: the course is considered to be a system; the method we use to develop embedded systems is considered a system; the way you learn for an exam and answer the exam questions is a system; and the way you are evaluation, is a system as well. In all, EEE3074W is a complicated system of systems, and I hope these systems will corroborate with each other to result in you, the student, achieving an excellent learning experience.
EEE3074W is about designing and developing embedded systems. The aim of this course is to provide the principles of doing embedded system development effectively in order to produce professional, highly maintainable and robust systems. The course is part theory, part practice, and part participation. Each of these parts are summarized below:
The theory aspect of this course attempts to cover the field of embedded system development broadly, but without going into great detail. Students are encouraged to explore, on their own, particular subfields of embedded system which interests them (the essay assignment is intended to ensure that students do take a closer look at least one of these subfields, or to look at a particular type of system, component, or development tool, that they are interested in).
|Introduction to Systems Thinking||General Systems Thinking (GST) or "systemics" is an interdisciplinary field that studies systems as a whole. I consider it a relevant starting point to frame the bigger picture of embedded system development.|
|Lifecycle of an embedded system||Overview of the lifecycle of an embedded system, from requirements and product specification, through hardware and software partitioning, and eventually to retirement.|
|Planning embedded system projects||Planning from product conceptualization, through requirements, partitioning, design, implementation, acceptance testing and upgrades. We look at what an R&D project is, and the needs, research activities, the person power that they involve.|
|Choosing hardware and tools||Embedded systems often involve custom hardware. You need to choose the microcontrollers, peripherals, and how to connect them up, in addition to which development tools, be they physical implements or software, that are needed to develop the product.|
|SoCs and ASICs||The trend is towards Systems On a Chip (SoCs), and Application Specific Integrated Circuits (ASICs), and the Intellectual Properties (IP) which constitutes the firmware on these. These technologies are particularly important for high-performance, or high-volume.|
|Partitioning: hardware or software?||In many cases, functionality can be provided in either hardware, or software, or both (e.g. redundancy for fault tolerance systems). We look at the implications of these choices, and good practices in making these decisions.|
|Embedded software engineering concepts||Embedded Software is becoming an increasingly larger part of embedded system development. Indeed, you may argue that in the case of projects using ASICs and VHDL code for hardware, is making the distinction between software and hardware foggy.|
|Hardware design for embedded systems||We look at some of the hardware design issues. This course does not cover VHDL or Verilog, or programming FPGAs; but these technologies are discusses. A prac and the project involves developing a prototype circuit on a breadboard (unless you want to do something more fancy and permanent).|
|Overview of co-design theory||Co-design is about the hardware and software teams working closely together, especially using specialized tools to facilitate software and hardware design activities done in parallel. We do not go into this in detail (that's more suited to graduate study).|
|Cost optimization for high volume||If you're dealing with high-volume, a major priority is to minimize the cost of components, be they physical hardware components, embedded operating systems, or licensed IP.|
|COTS: advantages and disadvantages||The use of commercial off-the-shelf (COTS) software and hardware components can be extremely useful in the development of prototype systems, or, in some cases, production systems. We discuss the advantages and disadvantages of this approach.|
|RT-UML for modeling||Modeling is a major part of embedded system design. Modeling can be done any may ways, using a variety of modeling languages. In this course, however, we perform modeling using Real-Time UML (Bruce Douglass, "Real-Time UML Second Edition", Addison-Wesley, 1999). We focus on use cases diagrams and statecharts.|
|Embedded system analysis and testing methods||The analysis and testing of embedded systems, their designs, and the components from which they are implemented, is generally an on-going process. Generally, tests are separated between individual hardware and software tests, after which integration tests are performed, where the software runs on the target hardware.|
|Future predictions for embedded systems||Embedded system design technologies, and how they are used, is constantly changing; generally becoming more complex, and increasingly software and firmware intensive. The final lecture looks at some of the latest trends, and how things may be done in a few decades (or only a few years!) time.|
Projects and practical constitute a large portion of this course. Most likely, you will spend most of your time solving problems or finding out how to solve problems (whether using textbooks, lecture notes, artifacts within the ESAOA framework, or doing web searches). That's what R&D is about, and I'm of the philosophy that experimentation is good, and is facilitated through tutorials and being walked through procedures on how to do such experimentation effectively. I tend to think the theory is really there just to provide the foundation and understanding that you need to plan your experimentation and understand the results of doing it.
|Experiment with tools and hardware||You will use a range of development tools, and different hardware peripherals. We start with a few simple tasks using just a regular PC, and then we move to the CSB337 evaluation board from Cogent, which will be used in most pracs, and in the project.|
|Use a sophisticated ARM microcontroller||The CSB337 has a microcontroller based on the ARM9 core. You get to develop programs in ARM assembly language, ANSI C, and finally C++, while progressing from a bare-bones boot loader, and moving to developing a C++ application for embedded Linux.|
|Communicate using standard protocols||Control peripherals using standard protocols, e.g. RS232 or I2C.|
|Use a system framework for fast development||We do everything using the ESAOA framework, which assists in your knowledge management, as well as providing a versatile application framework through which you can port your application code between platforms (PC or CSB337), and between platform deployment strategies (MicroMonitor, uCLinux, and your own creations or refined variants of these).|
|Try a boot loader||We get to test out a bootloader, and learn how to deploy software on the hardware using one.|
|Produce a mini BSP (board support package)||A Board Support Package is a set of documents, designs, code, and other files which allows developers to quickly develop custom applications for a board. You will develop a very simple BSP for the CSB337 and the custom hardware that you use in your own project, using ESAOA as a guideline and starting point.|
|Write and execute real RISC assembly language||Hope you remember some of your SPIM simulator (if you did CS2), because that may help you to accomplish this part. A open-source simulator is provided and installed on forge.ee to help out.|
|Prototype a subsystem||Developing an entire system is rather optimistic in the time available. Instead, you are required to prototype part of a (possibly hypothetical) larger system. The project will lead towards this, and in the final days on term, you will need to demo the sub-system in a simulated acceptance test (which you are expected to take very seriously, will count a noteworthy portion of your project mark, and during which time you can be expect to be grilled!).|
|Working in teams||Projects will be done in teams of three.
Collaboration tools (such as forums, chat services, email) are on
Connect, and the ESAOA framework is design to facilitate
identification, capture and sharing of implementation strategies for
Each student develops a prototype of a small piece (i.e. subsystem) of a larger hypothetical project. The team as a whole needs to come up with the initial project idea, and to develop a poster, and concept presentation of the idea. The poster and slides for the concept presentation will be put on this (public) website, so that you can proudly demonstrate your efforts with easy, wither done remotely or locally on campus.
Participation formally counts a few (i.e. one or two) percent of your final mark. But, you can be sure that if you don't participate, you aren't likely to succeed in this course. By participation, I refer to such activities as: using forums, and putting in your two pennies worth by asking questions in lectures, and being actively involved in practical and project work.
|Student presentations||You need to present your concept idea to the assembled students. I have planned for a 10 minute presentation by each team, in which each student must speak for approximately 3 minutes, and 4 groups per lecture slot. That is expected to take up four lecture slots assuming 39-42 students. PPT slides must be sent to the lecturer beforehand. Only those students presenting need to attend the lecture (i.e. audience of 9 including the lecturer); others students may attend also if they want to.|
|Simulated acceptance test||All the practical and project work really
cumulates towards a simulated FAT (Factory Acceptance Test). Basically,
the examiner pretends to be a client or (rather client's engineer
representative) and you demo your prototype to show to what degree it
One convenient cravat is that although you may loose a few marks by not meeting requirements precisely, most of the marks are related to how professional or how well organized your demonstration and setup is. In reality, it is often difficult, or impossible to meet all requirements, and often compromises are required (but clients are fickle; often if the prototype performs the important tasks well, if you carry yourself in a professional manner, and the overall presentation is good, a client may well overlook some of the unimportant bits that may not be working).
|Ask questions||Don't be shy in class, feel free to ask questions. Most lecturers (including myself) do tend to pause and poll for questions; but if it's a really poignant issue that you have to ask right now, by all means ask. Naturally, it's easy to say "ask questions", but I know full well it isn't all that easy to actually do so; especially if the lecture is well planned and the important issues are covered in clear and simple terms during which time you didn't fall asleep (unlikely, but happens).|
|Answer questions!||If you know the answer just stick up your hand and answer. Even if your answer leads to disagreement and argument, that's fine too: adds spice to the lecture.|
|Spot quizzes||No, they are generally not for marks. But your answer sheets are kept for archival purpose, to determine if you were "participatory" in class, and are also used in special situations such as trying to decide whether you deserve 49% or 51%...|
|Use the chat site and forum||Useful little tool for you and for me: the forum being particularly useful to me to gauge your participation ;-)|
|Contribute!||If you're likely the only one who has amazingly enough solved a sticky problem, why not post the solution on the relevant forum (provided that you can do so legitimately in accordance with the EEE3074W Forum Regulations).|
Place is limited due to the limited amount of hardware and person power available for teaching this course. Also, this course is designed for a fairly small number of students (not more than 42). So if you're interested, by all means cruise through a bit more of this website to make sure you want to take the course, but don't take too long or you may loose out...
The start page provides links to the main sections of this website. From here you may want to try:
|EEE3074W Online||Description of what you will find on the connect site (i.e. the course material, lecture notes, sample tests, booking sheets, etc) and what you will find on our forge.ee Linux server.|
|EEE3074W Hardware||Hardware used in the course, including PC requirements if you want to do practical work at home.|
|EEE3074W Software||Software used in the
course, including a description of the Embedded System Artifact
Organization and Adaptation (ESAOA) framework.
||Concept posters and
developed by students in EEE3074W 2005.
* “Systems” as in GST (General Systems Theory) which all scientists and engineers should know about!