Springen naar inhoud

Real-time op een typische pc


  • Log in om te kunnen reageren

#1

velgrem1989

    velgrem1989


  • >100 berichten
  • 228 berichten
  • Ervaren gebruiker

Geplaatst op 06 juni 2014 - 22:12

Het is me verteld dat, ondanks er meerdere RTOS bestaan voor de typische, alledaagse home computer, dat de real-time performance die gehaald wordt toch niet alles is.

 

Ik vroeg me af of iemand me meer kan vertellen hierover. Is het bijvoorbeeld enkel mogelijk soft real-time performance te bekomen? Of kan hard real-time ook? Of zijn beide misschien niet aangewezen op een doordeweekse pc?

 

Bedankt!


Dit forum kan gratis blijven vanwege banners als deze. Door te registeren zal de onderstaande banner overigens verdwijnen.

#2

317070

    317070


  • >5k berichten
  • 5567 berichten
  • Moderator

Geplaatst op 06 juni 2014 - 23:44

Hard kan ook, maar normaal gezien heb je nooit hard nodig tenzij er echt levens van zouden afhangen.

Veranderd door physicalattraction, 28 juni 2014 - 12:58
Onnodige quote verwijderd

What it all comes down to, is that I haven't got it all figured out just yet
And I've got one hand in my pocket and the other one is giving the peace sign
-Alanis Morisette-

#3

Merlion

    Merlion


  • >25 berichten
  • 57 berichten
  • Ervaren gebruiker

Geplaatst op 18 juni 2014 - 07:48

Het is me verteld dat, ondanks er meerdere RTOS bestaan voor de typische, alledaagse home computer, dat de real-time performance die gehaald wordt toch niet alles is.

 

 

Ik kom beroepsmatig dagelijks in contact met RT-toepassingen, zowel voor niet-RTOS (Windows Embedded, Unix) als RTOS (OSE). De beslissing welk OS te kiezen hangt van verschillende factoren af en is niet zo eenvoudig te verwoorden. Legacy van bestaande producten is veelal de beslissende factor.

 

Het voordeel van het gebruik van een modern RT-OS is echter dat de mechanismen en tools die nodig zijn om RT toe te laten/te ontwikkelen reeds in het OS verwerkt zitten, wat de ontwikkeling aanzienlijk vereenvoudigd.

  • Debuggen op applicatieniveau i.p.v. kernel niveau
  • Ingebouwde Task scheduler die een stipte uitvoering waarborgt. 
  • Ingebouwde bewaking van de stipte uitvoering van de taken
  • Communicatie tussen asynchrone taken is makkelijker dan in een conventioneel OS.    

Dit wil echter niet zeggen dat een RT toepassing op een niet-RTOS een probleem moet zijn. Stipte uitvoering kan je bv. ook garanderen door een deel van de taken in een kernel-driver te implementeren.

 

Kernel drivers kunnen echter enkel worden geprogrammeerd in C, vereisen veel meer kennis van de kernel/OS architectuur (DDK voor Windows) en zijn ook veel moeilijker te debuggen (Je kan een kernel driver niet stoppen zonder het volledige OS te laten crashen). Een bijkomende controle of een taak ook effectief is uitgevoerd binnen de vooropgestelde tijd is ook niet altijd evident en vraagt heel wat programmeerwerk.

 

Misschien maakt dit het een en ander wat duidelijker  

 

Veranderd door Merlion, 18 juni 2014 - 07:50


#4

317070

    317070


  • >5k berichten
  • 5567 berichten
  • Moderator

Geplaatst op 19 juni 2014 - 16:41

Het voordeel van het gebruik van een modern RT-OS is echter dat de mechanismen en tools die nodig zijn om RT toe te laten/te ontwikkelen reeds in het OS verwerkt zitten, wat de ontwikkeling aanzienlijk vereenvoudigd.

  • Debuggen op applicatieniveau i.p.v. kernel niveau
  • Ingebouwde Task scheduler die een stipte uitvoering waarborgt. 
  • Ingebouwde bewaking van de stipte uitvoering van de taken
  • Communicatie tussen asynchrone taken is makkelijker dan in een conventioneel OS.    

Persoonlijk heb ik ervaring met realtime kernels uit Linux. Het allerbelangrijkste voordeel daarbij is dat je een volwaardig besturingssysteem hebt, waarbij je nog steeds real-time kunt werken (op microseconde-niveau). Voor mijn toepassing (robotica) is dat een gigantische verandering geweest, omdat je je laag niveau real-time kunt doen in snel draaiende talen ( C ) en je je hoog niveau kunt doen in snel ontwikkelde talen (Python). Op die manier heb ik de ontwikkeltijd van mijn experimenten erg naar beneden kunnen halen, zonder veel op nauwkeurigheid te moeten inboeten.

What it all comes down to, is that I haven't got it all figured out just yet
And I've got one hand in my pocket and the other one is giving the peace sign
-Alanis Morisette-

#5

velgrem1989

    velgrem1989


  • >100 berichten
  • 228 berichten
  • Ervaren gebruiker

Geplaatst op 27 juni 2014 - 13:06

Bedankt voor de reacties.

 

De toepassing waar ik het voor wil gebruiken is het aansturen van een voice coil actuator, met 1000 Hz als sample frequentie.

Als ik het goed heb zal de standaard linux kernel hier dus niet geschikt voor zijn. 3 opties die ik bekeken heb zijn

 

* Config_preempt_rt patch

* RTAI

* Xenomai

 

Ik heb begrepen dat de eerste de linux kernel volledig preemptible maakt en dat de 2 laatsten voor een extra software laag zorgen onder de standaard linux kernel en deze runt als een low priority process.

 

Mits ik een leek ben in deze materie kom ik er niet echt uit welke van de 3 ik best gebruik. Om deze beslissing te kunnen maken wil ik voornamelijk gebruiksgemak met performantie (timing determinisme kleiner dan 1ms) afwegen.






0 gebruiker(s) lezen dit onderwerp

0 leden, 0 bezoekers, 0 anonieme gebruikers

Ook adverteren op onze website? Lees hier meer!

Gesponsorde vacatures

Vacatures