|
COMPUTER ENGINEERING LABORATORY
[This page is CSS2 enabled. Your browser might not fully support it]
[http://www.ee.oulu.fi/research/tklab/courses/521270A/]
521426A Embedded Software Project (5cu)
The spring 2008 course will use a wiki based communication system. It is under development, but will be ready before the start of the course, early in the January. Spring course will:
- be using the same ethernut 2.1 board as in the few years before.
- have it's credits raised once again.
- groups of 3 or 2 are accepted.
- this course is considered to be large enough project for doing a bachelors thesis.
These changes mean that:
- You can already start going through the specification of the board, and start trying out the ethernut-OS using last years material.
- the medium workload for a group will be higher than before.
- special attention will be given to project management (so use the timetrack from the beginning)
- start recruiting your friends to your group and/or start making new ones. :)
Link to sot-wiki
In this project the students familiarize themselves with the development
of non trivial computer applications by getting acquainted with software
development tools. Students are required to design and implement in C
a functioning application program while working in the project.
| Date |
News |
| 5th of June |
The extra intop is behind us. All final documents should be returned before 15th of June. Final document is returned in the mailbox in the third floor. Return your source code and documentation in electronic format also. Pack (zip, rar) the project and send it to the course assistants (sot-staff(at)ee). Use a folder structure so we can just unpack the system and run it on the class computers, without any extra folder fiddling. Results should be available ibefore the end of the month, but if you are in a hurry, contact the assistants. Thanks to everyone involved, and have a good summer. |
| 29th of May |
The last interoperability testing session approaches for this project. It will be held to those that have registered for it at 5th of June in the TS135 classroom. The session will start at 09:00 and will take no more than 3 hours. The point adjustment for the project groups that missed the deadline will be 10 full points. This will means that with a barely functional (but functional) application and decent documentation you will pass, and with extraordinary project work, a 5 is still a possibility, at least in theory. |
| 27th of April |
Interoperability testing is behind us, and thank for all taking part this year. The deadline for the documents and the sourcecode is on on the 30th of April (next monday), so return them before the door locks at 15:30. Thanks for your work, and have a good Wappu. |
| 27th of April |
If you *MISSED THE DEADLINE* there is still hope: We are having a extra interop session in the summer (5th of June), and you can register to it before 6th of May . All those needing extra time are penalized in the grading phase. Questions and email must be sent to the course staff email-address (sot-staff). |
| 23th of April |
Is there Life after interop? There has been some questions conserning the returning of the project. The project is returned in paper form to the mailbox. Additionally to that, we want your projects sourcecode and documentation files. Zip it, and send it to us at sot-staff. Zip the whole project folder, so that we can unzip it straight to the z:/ethernut/nutapp folder, and don't need to fiddle with the Makefile. Documentation should be in documentation folder. Paju will strip .zip attachments from e-mails, so please use your ee account or even g-mail. The returning email should have on subject field: "sot/esp final gr###", and the message part should have your groups e-mail addresses. |
| 18th of April |
Interoperability testing is close. Many groups have not registered. If you want to get a mark for passing this year, make sure that your group takes part of this event. |
| 10th of April |
INT-OPS ARE APPROACHING: ARE YOU READY??? The intop times have been changed to begin from 8 in the morning, and to end in the noon (12:00). There are 4 labtimes in-all, Monday, Tuesday, Thursday and Friday mornings. There are no more than 20 places in each of the labtimes, but keep in mind that there might be broken ethernuts in the class, so try to keep the maximum number of groups to 16, and you'll most likely have least amount of problems. The lab-registeration forms are on the noticeboard in the 3rd floor of Tietotalo. |
| 10th of April |
The UDP packets won't autofragment, as we previously thought. Thus implementation of frames larger than 1450 are not required. If you implement a multi frame data transfer, document it, so we can give you extra credit. The single ethernet frames are enough to prove the concept: multiple (more than one) players playing a single tune. |
| 13th of March |
The ethernuts are a eroding resource. Please inform the assistants, when there are broken nuts, so we can take approriate measures. |
| 13th of March |
The hubs are also under great strain. One has been replaced with a switch. Thus all packages don't reach the test PC. The affected places are on the first table (STUPID PCs 1 - 4). |
| 12th of February |
The Makefile in the LCD test doesn't work at the moment. The assistants are looking into it. The .c and .h files should work appropriately though, so you can copy them into your project. |
| 5th of February |
The design review times have arrived. Check them NOW. (link) |
| 30th of January |
Groupnumbers published (link) |
|
| 29th of January |
FAQ list added. |
| 23th of January |
Design lecture is held in L6 from 14:15 - 16:00. |
| 17th of January |
Groups of 2 made public. Need a group? Find one at the notice board in the 3rd floor of tietotalo. |
| 17th of January |
The documentation can be made in english or finnish. There has been a lot of questions about this. |
| 15th of January |
Lab exercise made public: http://www.ee.oulu.fi/research/tklab/courses/521270A/2007/lab/ |
| 9th of January |
Beginning lecture |
| 2007 |
|
Prof. Juha Röning
The purpose of the course is to familiarize the students
with modern software engineering methods and tools.
The purpose of the Embedded Software Project (Sulautettujen
Ohjelmistojen Työt, 521270A, formerly Software Engineering Project or
Ohjelmistotekniikan Työt, 521426A) course is to familiarize the
students with project teamwork, modern
software engineering methods and tools - eg. Ward & Mellor Structured
Analysis for Real-Time Systems (RT-SA/SD). The course is realized as a
project-like assignment that can, in principle, be taken from the
start to finish in 2-3 weeks by a team of 3 students working full
time. Typically the assignments have been completed during 2-5 months
requiring approximately 80-120 hours from each project team. Even
distribution of workload will require all members of projectgroup to
make at least some of the coding required. We suggest that the exercise
is done in groups of 3, but also groups of 2 are accepted.
The goal of the Embedded Software Project is to have a walk through
from the design to implementing and testing. An emphasis is put on
proper documentation. Extensive hardware or software expertise is not
necessary, so proportionate attention can be given to the design
methodology.
Despite its apparent simplicity, the problem allows plenty of
alternative solutions and should be a motivating and educating
exercise. Demonstration of a properly functioning system and
sufficient documentation is proof of a completed assignment.
No exam is required.
- Software Engineering (Ohjelmistotekniikka)
- Computer Engineering 2 (Sulautetut Järjestelmät)
Recommended:
- Programming Excercise (Ohjelmointityö)
- Operating Systems (Käyttöjärjestelmät)
| Task |
Day |
Time |
Location |
| Beginning Lecture |
9th of January 2007 |
13:15 - 15:00 |
L3 |
| Beginning Laboratory |
week 3 |
|
TS135 |
| Design review lecture |
23rd of January |
14:15 - 16:00 |
L6 |
| Final version of design must be returned by |
31st of January |
15:30 |
Mailbox |
| Group design review |
weeks 6 and 7 |
|
TS360 TS361 |
| Interoperability testing (software must work by this time) |
week 17 |
|
TS135 |
| Project Deadline |
30th of April 2007 |
|
|
- mailbox - refers to the metallic green mailbox at the third floor of the Tietotalo
- email - to the teaching assistants
The initial lecture is given on 9th of January in 2007 at 13:15 - 15:15
in lecture hall L3.
It is obligatory to register for this project. Registering is done by returning the design document before the design deadline.
The results of each project team will be judged based on
| Domain |
Value |
| Consistent use of the SE methodology |
15% |
| Implementation quality |
35% |
| Correspondence between design and implementation |
20% |
| Documentation |
20% |
| Interoperability |
10% |
| TOTAL |
100% |
The design results will be posted on the following page,
along with the review times for each group:
LINK
The course assignment is to implement an embedded software to
the course working environment (ethernut + io-board) that
- the application can communicate with other applications using
SNMP messages.
- meaningful usage of the provided IO-board features(LCD-display
and LEDs).
- user interface using the serial interface.
- SNMP messaging between different Ethernut boards.
- playing MIDI files, using the io-boards loudspeaker output (no
mp3 chip is present on the basic Ethernut)
The full project assignment as a pdf
can be found from the resource list in the following chapter.
Groups are expected to refer to the requirements document in their
own documents when appropriate.
The minimum requirements for passing the course are
- Functional implementation of
- Network functionality
- User Input / Output
- Playing MIDI format-0 files
- All documents delivered and accepted
- Design 1st Draft
- Design Document
- Final Document
- Presentation of implementation to the course assistants
Further implemented functionality improves the grade.
In the following table you will find all the necessary documents and document templates for the course.
| Description |
Download |
| Laboratory questions |
(link) |
| LCD library added (lcd-test.zip) |
(link) |
| PWM and HTTP example (buzzer.zip) |
(link) |
| Requirements specification |
(link) |
| Personal timetrack sheet |
(link) |
| Pre-compiled Nut/Os 3.9.8 (for TS135) |
(link) |
| Pre-compiled Nut/Os with minimal support for AvrStudio (for TS135) |
(link) |
| Pre-compiled Nut/Os 4.0.3 (for TS135) |
(link) |
| IO-board schematics |
(link) |
| Design document template |
(link) |
| Final document template |
(link) |
| Interoperability testing template |
(link) |
The Ethernut is a rather powerful microcontroller board. From Egnites web pages:
Ethernut 2.1 combines Atmel`s ATmega 128 microcontroller with SMSC`s LAN91C111 Ethernet controller. The main features are:
- ATmega 128 RISC microcontroller with up to 16 MIPS throughput.
- Full duplex IEEE 802.3 compliant 10/100 Mbps Ethernet controller with on-board RJ-45 connector.
- Two serial ports, RS232 at DB-9 connector and half duplex RS485 at screw terminal.
- 128 kByte in-system programmable Flash ROM and 512 kByte serial Dataflash.
- 4 kByte in-system programmable EEPROM.
- 32kByte SRAM plus 480 kByte banked SRAM.
- 22 programmable digital I/O lines.
- 8-channel, 10-bit analog/digital converter.
- Two 8-bit and two 16-bit timers/counters.
- Watchdog timer for enhanced reliability.
- LED indicators for power supply and Ethernet activity.
- Single power supply DC 8-12V.
- Board size: 78 x 98 mm.
The IO board consists of the following elements:
- 4 LEDs
- 4x16 characters LCD
- Plug for connecting loudspeakers
| Description |
Download |
| Ethernut 2.1 Hardware User's Manual |
(link) |
| AT45DB041B - Serial Data Flash |
(link) |
| ATMEGA 128 data sheet |
(link) |
| Terra Term Pro - Terminal Emulation |
(link) |
The usage of WinAVR is
advised. Up to date version of WinAVR is installed at the computers in TS135.
Use of programmers notepad (installed in TS135) or a similar programmin environment is encouraged.
The students are provided a library for handling the LCD and the PWM. See Material section for downloads.
As mentioned in the requirements, students are expected to use some consistent coding practice. Links to examples can be found from the link list below. Additionally, students are encouraged to use both a revision control system and a documentation tool.
| Description |
Download |
| Board test kit |
(link) |
| NutOS api |
(link) |
| WinAVR |
(link) |
| GNU Make - material on make rules and make |
(link) |
| Makefile tutorial |
(link) |
| Coding practice - notes on coding style for C programming |
(link) |
| Doxygen documentation tool |
(link) |
| A version control system available at ee machines: RCS |
(link) |
Few useful links to cut down the time used for googling.
| Description |
Download |
| Midi Specification |
(link) |
| Midi file format |
(link) |
| ...and |
(link) |
| Midinote-Frequency transformation |
(link) |
| SNMP made simple |
(link) |
| BER-Basic Encoding Rules |
(link) |
All network traffic testing has to be done in an isolated network.
Such a network is built for this purpose in class TS135.
- Course lecturer:
Prof. Juha Röning
- Teaching assistant: Teemu Tokola
- Consulting time:
- Wednesday, 12:00 to 14:00 at TS361
- Email: s o t - s t a f f @ e e . o u l u . f i
- Teaching assistant: Mirko Sailio
- Consulting time:
- Thursday, 10:00 to 12:00 at TS360
- Email: s o t - s t a f f @ e e . o u l u . f i
The assistants are responsible for the laboratory assignments,
tutoring and reviewing delivered documents and code.
- Read the material in the webpages carefully. Doing so will take it's
time and requires some effort. Not doing so will cost you much more
time in the coding phase. It will also affect the points you'll get
from your design document.
- If theres something you don't know how to implement in your design
document, it is usually a good idea to find it out before comitting to
the design. In worst case your wrong assumptions can double your
implementation workload.
- Keep your threads to a minimum, and when you use them, keep them small
and simple. This will cut down your debugging time.
- Test the functionality of the code often. If you make 85% of the code
in one chunk, and then come testing to the classroom, you will probably
have some exotic combination bugs. The detection and correction of
these take expertice and/or time. Most people have only one of these.
- Take full advantage of the starting laboratory, by familiarizing
yourself with the provided material beforehand.
- Try to make the project without long pauses. You will forget less and
need less time decrypting your own code. Even then comment your code
well.
- Allocate time to the project in the start of the year. Experience
has shown that on the last 2 weeks the test class are always full.
Network testing can be hard to do without at least 2 available
workstations with ethernut boards.
- Delete tested material after you stop testing. Even if the code
doesn't function perfectly, or you are returning to it in an hour.
Someone can copy it, and it is hard to prove which of you made the
original.
- All cases of suspected plagiarism will be investigated and all
unresolved cases are referred to professor Rönning. Plagiarism in
light cases can result in disqualification of work and in more severe
cases can result in temporary suspension of rights to study or permanent
expulsion from university.
- Don't use code apart from the examples that you find on the testclass
computers. It probably doesn't work in any case, and might be more
work to fix, than making your own code. Also it's unethical, illegal
and can put you in serious trouble (see the plaqiarism above).
- If a board doesn't seem to work properly, download our testsoftware.
It tests all the functionality required on the board. After this,
send mail to the course assistants, and they'll come and fix the
situation.
Problems some groups have faced. They are in a recent on top stack.
| Date added |
Question / Answer |
| 7th of march |
Q: The pins on the io-boards are different from place to place. Why is that? |
|
A: The different counters use different output ports for making the sound. The corresponding jumpers to portb pins to prosessor pins can be found in the datasheet and io-schematics. |
| 7th of March |
Q: Our multithreaded program crashes strangely, but when we put a debugging fprintf in there, it works. What's the problem? |
|
A: NutOS is not truly a multithreaded operating system. It uses the one and only processor to run all threads (and interrupts). The problem is, that the threads are not switched automagically. The prosessor keeps doing the same thread until it's given an instruction to let others play. This is included in some slower actions (like fprintf), and NutSleep. So: enrich all your threads with NutSleeps. Also, you will benefit from knowing how to use memory allocation and static variables. Even volatile variables can help. (Google: "static variables in c" and "volatile variables in c" gives some idea how they work). If you don't want the thread to really wait, use NutSleep(0), and the thread just checks if there are other threads waiting for prosessing. |
| 20th of February |
Q: Buzzer example is a mess, that makes no sense. How do I interpert it? |
|
A: Use the register definitions used in crosscompiling. They can be found in the STUPId PC:s from: \WinAVR\avr\include\avr\iom128.h |
| 30th January |
Q: What is this BOOLEAN datatype in the SNMP messages? We can't seem to find it from the SNMP specs? |
|
A: Use integer in stead. 0 for false and 1 for true. (Changes have been made to the specification). |
| 30th January |
Q: Does our player need to play multichannel melodies? |
|
A: Yes. You need to show that your player can play a melody using at least 2 players. |
| 29th January |
Q: Can the song be streamed to the other device during play? |
|
A: No. The specs cover it in the message transfers (send melody is before play). |
| 29th January |
Q: Can I use PORTB = 0xff in stead of sbi() and cbi() functions? |
|
A: Yes. But the system is more stabile if you use the sbi and cbi functions. (Especially setting DDRB = 0xff seems to wreck havoc with the system stability). |
Feedback can be given to any available course staffmember in person or using
e-mail: s o t - s t a f f @ e e . o u l u . f i
[http://www.ee.oulu.fi/research/tklab/courses/521270A/]
[This page is CSS2 enabled. Your browser might not fully support it]
|
