![[picture of the lab setup]](setup.jpg)
NB: onderstaande college-onderwerpen zijn op basis van de huidige planning, maw. dit kan wijzigen als blijkt dat eea sneller of langzamer gaat dan verwacht!.
Het prakticum bestaat uit 3 dagdelen verspreid over drie weken (1 dagdeel per week, het dagdeel is di ochtend of wo middag of do middag or vr middag, afhankelijk hoe je bent ingedeeld). Het prakticum is verplicht, en moet met voldoende resultaat zijn afgesloten wil je het vak kunnen halen. Omdat het praktikum slechts uit 3 dagdelen bestaat is er weinig tijd beschikbaar en is het essentieel dat het werk thuis wordt voorbereid (gebruik bv. de X32 simulator of de DOS versie van uC/OS die met het boek wordt meegeleverd). Studenten die de opdrachten onvoldoende hebben voorbereid en/of die veel te laat arriveren op het praktikum worden onherroepelijk weggestuurd, met als gevolg het niet behalen van het praktikum. Er geldt namelijk: aanwezigheid is verplicht voor elk van de drie dagdelen: afwezigheid leidt onherroepelijk tot het niet behalen van het praktikum en derhalve het vak.
Het praktikum wordt in groepjes van 2 studenten uitgevoerd. Behalve dat je je moet inschrijven in TAS, moet je je ook via email opgeven bij de student assistenten waarbij een groepje slechts EEN email verstuurt met beide namen en studienummers, samen met en EEN emailadres waaronder het groepje bereikbaar is. Als je geen partner weet geef je je individueel op. Je wordt dan in een groepje ingedeeld. De indeling in een van de vier dagdelen wordt door de student-assistenten bepaald op basis van beschikbaarheid. Wel kon een groep zich bij TAS inschrijven voor een specifiek dagdeel (di, wo, of vr) waar de voorkeur naar uit gaat, mits dat dagdeel nog niet voltekend is. Hier wordt - voor zover mogelijk - mee rekening gehouden, maar inschrijving voor een bepaald dagdeel biedt geen garantie. NB: dit geldt met name nu er sinds 26 nov 2006 de donderdagmiddag is bijgekomen.
In het praktikum moet een embedded programma worden ontwikkeld die het toerental van een electrische motor regelt (simulatie van een cruise control systeem bij auto's). De opdracht staat beschreven in de praktikumhandleiding. Als microcontroller gebruiken we de X32, een experimentele 32-bit softcore, geschreven in VHDL, die op een Xilinx Spartan-3 FPGA board is geimplementeerd. De softcore bevat peripheral devices zoals een UART om met de Linux host te communiceren (daar wordt het embedded programma gecompileerd en vervolgens ge-upload naar de X32), en devices op de motor aan te sturen en om de verdraaing van de motor-as te meten. De X32 wordt geprogrammeerd in ANSI C.
![[picture of the book]](simon.jpg)
Chapter 1. A First Look at Embedded Systems.
Doorlezen.
Geeft een aardig idee wat embedded systems zijn
en wat de specifieke toepassingsgebieden zijn.
De voorbeelden die behandeld worden dient men
wel te kennen, deze komen nml. veelvuldig terug in latere
hoodstukken.
Wordt indirect getoetst.
Chapter 2. HW Fundamentals for the SW Engineer.
Niet noodzakelijk, maar wel iets dat een goede
embedded SW engineer hoort te weten.
Er wordt aangenomen dat de basiskennis reeds aanwezig is
op grond van in2305-i.
Errata Figure 2.18 en 2.19: haal OVERLOADED weg.
Wordt niet getoetst.
Chapter 3. Advanced HW Funadamentals.
Niet noodzakelijk, maar wel iets dat een goede
embedded SW engineer hoort te weten.
Er wordt aangenomen dat de basiskennis reeds aanwezig is
op grond van in1705 en in2305-i.
Wordt niet getoetst.
Wij zullen de X32 behandelen.
Chapter 4. Interrupts.
Kern, helemaal bestuderen.
Interrupts vormen de basis voor elk computer systeem,
en met name embedded systemen, omdat die instantaan
op een veelheid van externe events moeten kunnen reageren.
Wordt getoetst.
Chapter 5. Survey of SW Architectures.
Kern, helemaal bestuderen.
In dit hoofdstuk wordt een aantal architectures
besproken, beginnende bij een heel simpele
round-robin opzet tot een volwaardige RTOS opzet.
Elke nieuwe architectuur wordt gemotiveerd
aan de hand van de tekortkomingen van de
net besproken architectuur.
Essentieel hoordstuk om het nut van een RTOS
te doorgronden, alsmede om in te zien dat
je niet altijd maar een RTOS-oplossing moet nemen.
Errata: Fig. 5.6 is niet correct. Zie slides op college.
Wordt getoetst.
Chapter 6. Introduction to RTOS.
Kern, helemaal bestuderen.
In dit hoofdstuk wordt het programmeren mbv een RTOS
uitgebreid besproken aan de hand van bekende
aspecten zoals priority scheduling, data sharing,
reentrancy, semaphores als basis-oplossing voor
data sharing met de daarbij behorende problemen
zoals priority inversion, deadlock.
Wordt getoetst.
Chapter 7. More OS Services.
Belangrijk, echter slechts gedeeltelijk bestuderen.
Met interrupts en de basis RTOS functies: (priority) task
scheduling en semaphores heb je eigenlijk al genoeg
om embedded applicaties te bouwen.
In dit hoofdstuk worden een aantal aanvullende toeters
en bellen geintroduceerd, zoals queues, mailboxes, pipes,
timers, events, en memory management, die het programmeerleven
makkelijker maken.
Tekst van 7.1 t/m 7.4 doorlezen, met name de gevaren
van het ondoordacht programmeren mbv bovenstaande functies
dient men te onderkennen (de Pitfalls op pag. 181 t/m 184).
Het gebruik van timer functies (7.2) en
interruptroutines in combinatie met een RTOS
(7.5) dient daarentegen helemaal bestudeerd te worden.
Wordt getoetst.
Chapter 8. Basic Design Using an RTOS.
Belangrijk, echter slechts doorlezen.
In dit hoofdstuk worden algemene stelregels gegeven
hoe een embedded systeem moet worden ontworpen.
Alle eerder behandelde concepten komen bij elkaar
in het voorbeeld design van 8.3 (de Underground Tank
Monitoring System) inclusief methoden om bugs te voorkomen
(lees met name 8.4).
In tegenstelling tot de UTMS zullen wij ons echter primair richten
op de Cruise Control applicatie die op het prakticum
moet worden geprogrammeerd.
Wordt indirect getoetst.
Chapter 9. Embedded SW Development Tools.
Belangrijk, echter slechts doorlezen.
Goede introductie in de algemene tool chain architectuur
bij embedded systems.
Wij zullen ons echter primair richten op de X32 tool chain
die op het prakticum wordt gebruikt.
Wordt indirect getoetst.
Chapter 10. Debugging Techniques.
Niet noodzakelijk.
Goede en belangrijke introductie in wat in de embedded systems praktijk
het meest belangrijkste (en tijdrovendste) is:
testen en debuggen. Gegeven de gelimiteerde tijd
komen wij hier helaas niet aan toe, maar is warm aanbevolen
voor verdere studie. Een deel van de stof komt
automatisch aan bod tijdens het prakticum.
Wordt niet getoetst.
Chapter 11. An Example System.
Niet noodzakelijk.
Dit hoofdstuk geeft een nadere uitleg van een PC-versie
van de UTMS die is meegeleverd bij het boek (op CD).
Omdat het hier om een versie gaat die weinig
"embedded" is, geven wij de voorkeur aan de Cruise
Control HW en SW bij het prakticum.
Wordt niet getoetst.
Er bestaat de mogelijkheid tot het doen van een tussentoets. Deze toets bestaat uit het maken van (waarschijnlijk) 10 MC vragen tijdens het eerste uur (45 min) van een collegeblok. Tijdens het tweede uur wordt de toets besproken. De toets geeft een idee hoe het tentamen zal gaan en speelt mee in de beoordeling van het vak (het eerder genoemde cijfer c) volgens een gunstig no-cure-no-pay-achtig principe, waarbij onvoldoenden geen negatief effect hebben. Zij p het cijfer voor de toets en q het cijfer van het tentamen. Dan geldt dat c = max(q, (7.5*q + 2.5*p)/10). Altijd komen dus!