180 likes | 291 Views
Real time systemen. Real time De resultaten moeten deterministisch (steeds binnen een gedefiniëerde tijd ) ter beschikking zijn na het optreden van een event. Anders werkt het systeem niet naar behoren .
E N D
Real time systemen Real time De resultatenmoetendeterministisch (steeds binneneen gedefiniëerdetijd) terbeschikkingzijnna het optreden van een event. Anders werkt het systeem niet naarbehoren. In het ergstegevalkanerzelfsschadeoptredenaan de installatie of ergernog, kunnenermensenwordengewond of…
Onderscheid volgens tijds- en kritisch belang. RT systeem reactietijd: traag of snel = f(toepassing) • De meeste RT systemen hebben zowel hard- als soft realtimeeisen en zijn meestal gebaseerd op een embedded computer
Alternatieven voor de opbouw van een RT systeem. Een eenvoudig single loop RT systeem . Temperatuur Vout Single task programma Soft real time systeem: Geen timing eisen… dus eenvoudig? Low level routines: Kennis van de systeemhardware nodig!
Alternatieven voor de opbouw van een RT systeem: Interrupt gebaseerde aanpak Een foreground/ background RT systeem. Oneindige lus + ISR’s ISR’s handelen de kritische: asynchrone events af. periodische zaken af (timer ISR) en dit met prioriteitsregeling! zoveel mogelijk werk in background uitvoeren! ‘Tasklevel responce’= f(backgroundloop) Niethard realtime! (niet deterministische background routine: Hard real time danactie in de foreground routine stoppen!) Geen formele maar ambachtelijke manier voor het opdelen van het probleem in ISR’s en backgroundlus Interrupt / hoofdprogramma Kritische bewerkingen! Info uitwisseling met de background routine via buffers, queue’s, flags…
Communicatie tussen foreground en background routines kan bv. via flags en buffers.
Alternatieven voor de opbouw van een RT systeem. Teken een ‘timing chart’ van de foreground/background routine “Stel kritische vragen: kunnenergeenseriëelechars verlorengaan?”
Ontwerptips voor ISR’s.Dikwijls:‘Vectored’ interrupts 8051 vasteint.vectoradressen x2 of x4 (bij16bit/32bit…) offset Adres ISR
Ontwerptips voor ISR’s.algemeneregels: • Maak een schematische voorstelling! • Breng elke ISR in kaart! (int freq , worst case exe tijd) • Bepaal de int. prioriteit i.f.v. : int freqen exe tijd… • kies een hogere prioriteit voor taken met zeer snelle respons op de int! • ISR’s steeds ‘kort’ houden. (‘flag-principe’, delayloop= ) • Data verwerken met (low prio) ISR (timer) met een nog ‘real time’ periode! • Enable zo snel mogelijk opnieuw de interrupts (X86) • Schrijf ‘reëntrant’ code! • Gebruik nooit de NMI tenzij voor powerfail of de ‘apocalyps’... Na het uitvoeren van tijdskritische en niet reëntrant code…
NMI gebruik! Vorige INT is nog niet in uitvoering! Met NMI Stel dat er een niet-reëntrant deel zolang duurt => probleem! Uiteindelijk kans op stackoverflow!!!
Ontwerptips voor ISR’s.algemene regels • Vul alle niet gebruikte vectoren in de vectortabel steeds in… • Let op het genereren van het INT signaal (flank of niveau gevoelig!) • Begin met het prototypen van ISR’s! • Komt de interrupt niet? Check: • - Interruptsgeënabled in het hoofdprogramma? Kijk (indien mogelijk) naar de INTR pin! • - Genereert de (externe) periferie zelf wel een interruptrequest? • - Heb je alle nodige delen van de periferie wel toegelaten om interrupts te genereren? • Interruptéénmaal zien werken? • - Terug enabled? (X86) • - Moeten pending interrupts in de periferie worden gereset? • - RET ipv RETI gebruikt? interruptlevel terug vrijgegeven? Steile flank ruis!
Ontwerptips voor ISR’s.snelheidsproblemenbij ISR’s. • “Is de ISR niet snel genoeg, ge krijgt de problemen waar ge om vroeg!” • Wat is snel genoeg? • -maak een ‘interruptchart’ met timing… • Hoe weet ik of ik de beoogde timing haal? (het werkt!??…) • Instrumenteer uw code, maak een aantal parameters meetbaar! • en meet deze parameters ‘worstcase’. • Voorzie marges!! • - Performance analyser : min, max, gemiddelde uitvoeringstijd van software routines. • - Low budget? Set en reset een ongebruikte I/O pin en gebruik een (digitale) • ‘scoop’ in oneindige persistentie mode. • - Totale interrupt overhead in het systeem?
Ontwerptips voor ISR’s.ISR's moeten grotendeels 'reëntrant' zijn. • ‘reëntrant’ : ISR (of main) moet kunnen onderbroken worden door ISR met hogere • prioriteit die dezelfde (sub)routines gebruikt als de onderbroken ISR! • Probeer globale variabelen te vermijden (tenzij beschermd door gedisabeldeint’s) • Pas een ‘propere’ context switch toe! • Opgelet voor de ‘C’ fanaten: zorg voor runtime functies die volledig 'reëntrant' zijn • of disable de interrupts voor het gebruik ervan, maar dit is nefast voor de int.respons! • NMI is niet te maskeren, bij slecht gebruik bijna 100% zeker reëntrancy problemen op • X86 processoren. - Meestal flankgevoelig => zorg voor steile flanken ivm. ruis! • Zelfs een perfectreëntrantISR die te traag is geeft stack-problemen….
Ontwerptips voor ISR’s.ISR's en de systeemstack. • “groeit de stack ongeremd, de programmeur staat in zijn hemd” • Problemen kunnen de stack laten ‘groeien’ zodat het systeem vastloopt! • Analyse van het probleem is moeilijk, variabelen zijn soms overschreven. • Oplossing: de ‘stack-monitor’ • → vergelijkt de stackpointer met limietwaarde en indien groter dan • een bepaalde waarde spring naar dummy routine waar een breakpoint op staat. • Stop de stackmonitor in de meest veelvuldig opgeroepen ISR’s. • Stackinhoud analyseren: als veel adressen uit een geheugengebied van een ISR • komen, dan wordt deze steeds weer opgestart (na enable INT bij X86) • … dan is de ISR te traag!
Alternatieven voor de opbouw van een RT systeem.Een systeem met een RT operating systeem (RTOS). Multitasking! (code opdelen in meerdere onafhankelijke tasks) Taskhandling (timing, intertaskcommunicatie…) = verantwoordelijkheid van het OS. ‘rechtlijnige’ code Data verwerkende Data verwerkende Coördinatie synchronisatie communicatie onderlinge prioriteit Time tick De RT-Kernel zal zorgen dat er nog ‘deterministisch’ op een real time manier wordt gereageerd op een extern of intern event.
Voor en nadelen van een RTOS. • Voor: • Tasks handelen deelproblemen af en zijn minder met elkaar verweven: eenvoudiger, beter te afzonderlijk te debuggen… • RTOS zorgt voor: • communicatie tussen de tasks • interrupthandling • taskswitching • memory management • Na: - RTOS ‘aware’ debugging ? • - Uitvoeren van een RTOS kost processortijd! • Verloren tijd bij taskswitch • Verloren tijd bij opstarten task na interrupt (latency) • -Interruptlatencytijd is meestal veel groter dan bij een foreground/background systeem! • Systeem coordinatie na systeem ‘timetick’... • Extra geheugen nodig…(ram en rom)
Opdracht embedded II: systeem met RT gedrag. • A/D samples 12 bit! @1ms! • Moving average 8 samples • Sinusoïdale golf genereren met freq. 0,1-99,9Hz (12bit) • DDS principetoepassen • LCD aanduiding: (20ms) • 0,00V - 5,00V / 0,1-99,9Hz • Serial port:9600bps • :FH :FD :VD commando’s • uitvoeren binnen de 50ms! • Errorstatus op leds (knipperen @0,5s) DAC out
Enkeleverbanden en getalwaarden… • Stelfclock = 16.777216MHz, timerclock = fclock/12 • faclk= adderclockgenererenadhv. een timer: • →Bijtimeroverflowna 200 counts: 143,0511µs (6,990507kHz) • Stelfase adder = 20 bit • Dan: = met = fase increment • Voor =1 geeft dit: • = 6,990507kHz/ = 0,0066666666666Hz = 1/150Hz! • Voor =15 geeft dit dus een frequentie van 0,1Hz