Real time systemen Real time –De resultaten moeten deterministisch (steeds binnen een gedefiniëerde tijd) ter beschikking zijn na het optreden van een.

Presentatie over: "Real time systemen Real time –De resultaten moeten deterministisch (steeds binnen een gedefiniëerde tijd) ter beschikking zijn na het optreden van een."— Transcript van de presentatie:

1 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. In het ergste geval kan er zelfs schade optreden aan de installatie of erger nog, kunnen er mensen worden gewond of…

2 Onderscheid volgens tijds- en kritisch belang. RT systeem reactietijd: traag of snel = f(toepassing) De meeste RT systemen hebben zowel hard- als soft realtime eisen en zijn meestal gebaseerd op een embedded computer

3 Alternatieven voor de opbouw van een RT systeem. Een eenvoudig single loop RT systeem. Vout Temperatuur Single task programma Soft real time systeem: Geen timing eisen… dus eenvoudig? Low level routines: Kennis van de systeemhardware nodig!

4 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 ) Niet hard realtime! ( niet deterministische background routine: Hard real time dan actie in de foreground routine stoppen! ) Geen formele maar ambachtelijke manier voor het opdelen van het probleem in ISR’s en backgroundlus Info uitwisseling met de background routine via buffers, queue’s, flags… Kritische bewerkingen! Interrupt / hoofdprogramma

5 Communicatie tussen foreground en background routines kan bv. via flags en buffers.

6 Alternatieven voor de opbouw van een RT systeem. Teken een ‘timing chart’ van de foreground/background routine “Stel kritische vragen: kunnen er geen seriëele chars verloren gaan?”

7 Ontwerptips voor ISR’s. Dikwijls: ‘Vectored’ interrupts 8051 vaste int.vectoradressen x2 of x4 (bij16bit/32bit…) offset Adres ISR

8 Ontwerptips voor ISR’s. algemene regels: Maak een schematische voorstelling! Breng elke ISR in kaart! (int freq, worst case exe tijd) Bepaal de int. prioriteit i.f.v. : int freq en 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…

9 NMI gebruik! Uiteindelijk kans op stackoverflow!!! Met NMI Vorige INT is nog niet in uitvoering! Stel dat er een niet-reëntrant deel zolang duurt => probleem!

10 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: - Interrupts geënabled in het hoofdprogramma? Kijk (indien mogelijk) naar de INTR pin! - Genereert de (externe) periferie zelf wel een interrupt request? - 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? interrupt level terug vrijgegeven? Steile flank ruis!

11 Ontwerptips voor ISR’s. snelheidsproblemen bij ISR’s. “Is de ISR niet snel genoeg, ge krijgt de problemen waar ge om vroeg!” Wat is snel genoeg? -maak een ‘interrupt chart’ 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?

12 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 gedisabelde int’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 perfect reëntrant ISR die te traag is geeft stack-problemen….

13 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!

14 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. De RT-Kernel zal zorgen dat er nog ‘deterministisch’ op een real time manier wordt gereageerd op een extern of intern event. Data verwerkende ‘rechtlijnige’ code Coördinatie synchronisatie communicatie onderlinge prioriteit Time tick

15 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)

16 Opdracht embedded II: systeem met RT gedrag. DAC out A/D samples 12 bit! @1ms! Moving average 8 samples Sinusoïdale golf genereren met freq. 0,1-99,9Hz (12bit) DDS principe toepassen 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)

17 DDS principe +

18