Vraag:
RTOS voor embedded systemen
Kortuk
2009-12-03 02:59:25 UTC
view on stackexchange narkive permalink

Ik heb veel artikelen gezien die me vertellen dat ik RTOS zou moeten gebruiken voor tijdbeheer en resourcebeheer. Mijn tijd heeft mijn eigen onderzoek niet toegestaan, dus ik kom naar chiphacker voor advies.

Ik gebruik low resource microcontrollers (MSP430, PIC) en was op zoek naar RTOS'en die ik kan gebruiken.

Ter zake:

  1. Resourcekosten van het systeem
  2. Voordelen van het systeem
  3. Nadelen van het systeem
  4. Implementatietrucs
  5. Situaties waarin de RTOS wel / niet moet worden gebruikt.

Ik gebruik geen systemen zoals de Arduino, de projecten waarmee ik werk kunnen de kosten van zo'n systeem niet dragen.

Ik ben in de war over waarvoor dit een neerwaartse stemming heeft gekregen. Als de kiezer mij feedback zou kunnen geven, zal ik proberen een dergelijke actie in de toekomst te vermijden.
idem dito. Het is een geweldige vraag ...
Ik accepteerde een vraag omdat ik, zelfs al dacht dat dit een open einde was, een aantal geweldige reacties had en ten minste één schrijver wilde belonen voor de moeite.
Negen antwoorden:
#1
+29
Jason S
2009-12-03 11:07:38 UTC
view on stackexchange narkive permalink

Ik heb niet veel persoonlijke ervaring gehad met andere RTOS's dan QNX (wat over het algemeen geweldig is, maar niet goedkoop en ik heb een hele slechte ervaring gehad met een bepaalde bordverkoper en QNX's we-don't-care-houding voor andere dan de meest gebruikelijke systemen) die te groot is voor PIC's en MSP430's.

Waar u baat zult hebben bij een RTOS zijn gebieden zoals

  • threadbeheer / planning
  • inter-thread communicatie + synchronisatie
  • I / O op systemen met stdin / stdout / stderr of seriële poorten of ethernet-ondersteuning of een bestandssysteem (voor het grootste deel geen MSP430 of PIC , behalve de seriële poorten)

Voor randapparatuur van een PIC of MSP430: voor seriële poorten zou ik een ringbuffer + interrupts gebruiken ... iets dat ik één keer per systeem schrijf en gewoon hergebruik ; andere randapparatuur Ik denk niet dat je veel ondersteuning van een RTOS zou vinden, omdat ze zo leverancierspecifiek zijn.

Als je een timing nodig hebt die tot op de microseconde keihard is, heeft een RTOS waarschijnlijk gewonnen ' t help - RTOS'en hebben de timing begrensd, maar hebben meestal timingjitter in hun planning vanwege vertragingen in contextomschakeling ... QNX die op een PXA270 draaide had jitter in de typische tientallen microseconden, maximaal 100-200us, dus ik zou dat niet doen gebruik het voor dingen die sneller moeten lopen dan ongeveer 100 Hz of die veel nauwkeuriger moeten worden getimed dan ongeveer 500 us. Voor dat soort dingen zult u waarschijnlijk uw eigen interruptafhandeling moeten implementeren. Sommige RTOS'en zullen daar goed mee spelen, en andere zullen het een koninklijke pijn maken: je timing en hun timing kunnen misschien niet goed naast elkaar bestaan.

Als de timing / planning niet te complex is, kunt u beter een goed ontworpen toestandsmachine gebruiken. Ik zou het ten zeerste aanbevelen om Practical Statecharts in C / C ++ te lezen als je dat nog niet hebt gedaan. We hebben deze aanpak gebruikt in een aantal van onze projecten waar ik werk, en het heeft een aantal echte voordelen ten opzichte van traditionele staatsmachines voor het beheren van complexiteit ... wat eigenlijk de enige reden is waarom je een RTOS nodig hebt.

Ik werk bij een startend bedrijf waar de meest ervaren embedded systems-jongens net klaar zijn met studeren (dwz ikzelf en de andere man die al ongeveer 2 jaar met mij samenwerkt). Ik besteed een zeer groot deel van de tijd aan het leren van mezelf over de praktijk van de industrie tijdens mijn werkweek. Zoals ik heb gelezen, ben ik voor iedereen geïnformeerd, behalve voor ons goedkoopste systeem, een RTOS zou een grote verbetering zijn.
Er lijkt een RTOS-systeem met een zeer lage bron te zijn voor zaken als PIC's en MSP430's die kunnen helpen een deterministisch systeem te creëren uit een zeer gecompliceerd systeem, waarbij ook ons ​​beheer van het gescheiden houden van modules aanzienlijk wordt opgeschoond. Ik heb deel uitgemaakt van een team van twee man dat effectief een gegevensverzamelings- en routingsysteem in het veld heeft gebouwd. Nu ik naar RTOS kijk, zie ik dat het perfect is voor wat we hebben ontworpen.
Sorry voor het gebruik van drie postvakken, uw antwoord is zeer nuttig, ik ben op zoek naar een oplossing met zeer weinig middelen, maar deze informatie is waardevol om te hebben, bedankt voor de hulp.
maak je geen zorgen over het aantal reacties (IMHO een ding dat het StackExchange-framework ontbreekt, is ondersteuning voor discussies ... het Q / A-formaat dekt de meeste dingen, maar niet sommige) ... het klinkt alsof je een redelijk goed begrip hebt van wat je zoekt. Ik heb niet gekeken naar de FreeRTOS die Steve heeft genoemd, maar als het is geport naar low-end microcontrollers, zal het misschien het planningsbeheer doen dat je nodig hebt.
Het lijkt de status van elke thread op te slaan via de stapel (ongeveer 50 push / pull-statements) en kan getimede interrupts verwerken. Mijn systeem zou normaal gesproken een poortonderbreking gebruiken voor het wisselen van thread, maar de taak ziet er goed uit. Ik zou willen dat dit sitetype de discussie in een beter formaat behandelde.
#2
+26
Steve Melnikoff
2009-12-03 06:05:08 UTC
view on stackexchange narkive permalink

Heeft u FreeRTOS geprobeerd? Het is gratis (onder voorbehoud van T&C), en is geporteerd naar zowel de MSP430 als verschillende smaken van PIC.

Het is klein vergeleken met sommige andere, maar dit maakt het ook gemakkelijk om te leren, vooral als je nog niet eerder een RTOS hebt gebruikt.

Er is een (niet-gratis) commerciële licentie beschikbaar, evenals een IEC 61508 / SIL 3-versie.

Heel erg bedankt, ik zal er binnen een week naar kijken, ik laat de vraag open voor andere antwoorden, maar je bent een grote hulp!
#3
+12
Jay Atkinson
2010-06-04 02:35:03 UTC
view on stackexchange narkive permalink

Ik kwam net te weten over NuttX RTOS, dat zelfs op een 8052 (8-bits) systeem kan werken. Het heeft niet veel poorten, maar het ziet er interessant uit. De POSIX kan een pluspunt zijn, omdat het een deel van je code wat draagbaarder kan maken als je overstapt naar een krachtigere processor en je real-time linux of QNX wilt draaien.

Ik niet heb zelf enige ervaring met commerciële RTOS's, maar ik gebruik zelf al jaren zelfgemaakte! Ze zijn geweldig om u te helpen bij het verdelen van uw code-ontwikkeling over veel programmeurs, omdat ze in wezen allemaal een "taak" of "thread" kunnen krijgen om van hun kant te werken. Je moet nog steeds coördineren en iemand moet toezicht houden op het hele project om ervoor te zorgen dat elke taak de deadline kan halen.

Ik raad je ook aan om Rate Monotonic Analysis of RMA te onderzoeken wanneer je een RTOS gebruikt. Dit helpt u te garanderen dat uw kritieke taken hun deadlines halen.

Ik zou ook willen kijken naar Miro Sameks QP-nano gebeurtenisgestuurd programmeerraamwerk dat kan werken met of zonder een RTOS en biedt u nog steeds realtime mogelijkheden. Hiermee verdeelt u uw ontwerp in hiërarchische toestandsmachines in plaats van traditionele taken. Jason S noemde het boek van Miro in zijn post. Uitstekend gelezen!

#4
+9
supercat
2011-03-16 09:06:07 UTC
view on stackexchange narkive permalink

Een ding dat ik op een aantal machines handig vond, is een eenvoudige stapelschakelaar. Ik heb er niet echt een geschreven voor de PIC, maar ik zou verwachten dat de aanpak prima zou werken op de PIC18 als beide / alle threads in totaal 31 of minder stapelniveaus gebruiken. Op de 8051 is de hoofdroutine:

 _taskswitch: xch a, SP xch a, _altSP xch a, SP ret 

Op de PIC ben ik de naam van de stapelwijzer vergeten , maar de routine zou zoiets zijn als:

 _taskswitch: movlb _altSP >> 8 movf _altSP, w, b movff _STKPTR, altSP movwf _STKPTR, c return 

Aan het begin van je programma, roep een task2 () routine aan die altSP laadt met het adres van de alternatieve stapel (16 zou waarschijnlijk goed werken voor een PIC18Fxx) en voert de task2 lus uit; deze routine mag nooit meer terugkeren, anders zullen de dingen een pijnlijke dood sterven. In plaats daarvan zou het _taskswitch moeten aanroepen wanneer het controle wil geven aan de primaire taak; de primaire taak moet dan _taskswitch aanroepen wanneer hij wil toegeven aan de secundaire taak. Vaak heb je schattige kleine routines zoals:

 void delay_t1 (unsigned short val) {do taskwitch (); while ((unsigned short) (millisecond_clock - val)> 0xFF00); } 

Merk op dat de taakwisselaar geen enkele manier heeft om 'wacht op voorwaarde' uit te voeren; het enige dat het ondersteunt is een spinwait. Aan de andere kant is de taakwisseling zo snel dat een poging tot een taskwitch () terwijl de andere taak wacht op het verstrijken van een timer, zal overschakelen naar de andere taak, de timer controleren en sneller terugschakelen dan een typische taakwisselaar zou bepalen dat het niet nodig is om te schakelen tussen taken.

Merk op dat coöperatieve multitasking enkele beperkingen heeft, maar het vermijdt de behoefte aan veel vergrendeling en andere mutex-gerelateerde code in gevallen waarin invarianten die tijdelijk worden gestoord kan snel worden hersteld.

(Bewerken): een paar kanttekeningen met betrekking tot automatische variabelen en dergelijke:

  1. als een routine die gebruikmaakt van taakwisseling vanuit beide threads wordt aangeroepen, zal het in het algemeen nodig zijn om twee kopieën van de routine te compileren (mogelijk door hetzelfde bronbestand twee keer op te nemen, met verschillende #define-instructies). Elk gegeven bronbestand bevat ofwel code voor slechts één thread, of bevat code die twee keer wordt gecompileerd - één keer voor elke thread - dus ik kan macro's gebruiken zoals "#define delay (x) delay_t1 (x)" of #define delay (x) delay_tx (x) "afhankelijk van welke thread ik gebruik.
  2. Ik geloof dat PIC-compilers die een aangeroepen functie niet kunnen" zien ", ervan uitgaan dat een dergelijke functie alles kan weggooien CPU-registers, waardoor het niet nodig is om registers op te slaan in de taakwisselroutine [een mooi voordeel vergeleken met preventieve multitasking]. Iedereen die een vergelijkbare taakwisselaar voor een andere CPU overweegt, moet op de hoogte zijn van de registerconventies die in gebruik zijn. voordat een taak wordt omgeschakeld en ze erna worden gepakt, is een gemakkelijke manier om voor dingen te zorgen, ervan uitgaande dat er voldoende stackruimte is.

Door coöperatieve multitasking kan iemand niet volledig ontsnappen aan problemen met vergrendelen en dergelijke, maar het is echt vereenvoudigt dingen enorm.In een preventieve RTOS met een compacterende garbage collecto r, is het bijvoorbeeld nodig om toe te staan ​​dat objecten worden vastgezet. Bij gebruik van een coöperatieve switcher is dit niet nodig, op voorwaarde dat de code ervan uitgaat dat GC-objecten kunnen worden verplaatst telkens wanneer taskwitch () wordt aangeroepen. Een compacterende verzamelaar die zich geen zorgen hoeft te maken over vastgezette objecten, kan veel eenvoudiger zijn dan een die dat wel doet.

Geweldig antwoord. Ik denk dat het interessant zou zijn om enkele links te krijgen over bronnen over het benaderen van mijn eigen RTOS. Mijn focus hier was echt om een ​​RTOS van hoge kwaliteit te krijgen van een leverancier die het werk heeft gedaan om te zorgen voor harde realtime, maar dit kan een leuk hobbyproject voor mezelf zijn.
Cool, nooit aan taken gedacht als alleen het wisselen van de SP ...
@JGord: Ik heb kleine taakwisselaars gedaan op de 8x51 en op een TI DSP. De hierboven getoonde 8051 is ontworpen voor precies twee taken. De DSP-versie wordt gebruikt met vier en is iets gecompliceerder. Maar ik had gewoon een gek idee: je kon vier taken uitvoeren door simpelweg drie taakschakelaars te gebruiken. Elke keer dat een van de eerste twee taken van taak wil wisselen, moet deze TaskSwitch1 en TaskSwitch2 aanroepen. Wanneer een van de tweede twee taken een taskwitch wil, moet deze Taskswitch1 en Taskswitch3 aanroepen. Stel dat de code begint in stack0 en dat elke taakwisselaar wordt ingesteld met het bijbehorende stapelnummer.
@JGord: Hmm ... dat werkt niet helemaal; het lijkt een 3-way round-robin op te leveren en negeert de derde switcher. Nou, experimenteer en ik denk dat je waarschijnlijk een goede formule zult vinden.
#5
+7
uɐɪ
2009-12-08 22:16:22 UTC
view on stackexchange narkive permalink

Ik heb Salvo op de MSP430 gebruikt. Dit was erg licht voor de processorbronnen en, op voorwaarde dat u zich aan de implementatieregels houdt, zeer gemakkelijk te gebruiken en betrouwbaar. Dit is een coöperatief besturingssysteem en vereist dat taakwisselingen worden uitgevoerd op het externe functieaanroepniveau van de taakfuncties. Deze beperking stelt het besturingssysteem in staat om in zeer kleine geheugenapparaten te werken zonder grote hoeveelheden stackruimte te gebruiken, waarbij taakcontexten behouden blijven.

Op de AVR32 gebruik ik FreeRTOS. Nogmaals zeer betrouwbaar tot nu toe, maar ik heb een aantal configuratie / versieverschillen gehad tussen de versie die FreeRTOS publiceert en de versie die bij het Atmel-framework wordt geleverd. Dit heeft echter als voordeel dat het gratis is!

#6
+5
Amos
2009-12-09 17:09:18 UTC
view on stackexchange narkive permalink

De decembereditie van Everyday Practical Electronics bevat deel 3 van een serie over realtime besturingssystemen voor PIC's (in de kolom PIC n 'Mix) en bevat details over het instellen van FreeRTOS met MPLAB en een PICKit 2. De vorige twee artikelen (die ik niet heb gezien) schijnen de verdiensten van verschillende RTOS'en te hebben besproken en besloten op FreeRTOS te zijn. Zodra het huidige artikel de ontwikkelomgeving heeft opgezet, beginnen ze met het ontwerpen van een binaire digitale klok. Het lijkt erop dat er nog minstens één onderdeel over dit onderwerp moet komen.

Ik weet niet zeker hoe EPE beschikbaar is in de VS, maar er lijkt een link naar een Amerikaanse winkel op hun site te staan ​​en mogelijk zijn er elektronische kopieën beschikbaar.

#7
+4
Jeanne Pindar
2010-06-04 07:36:57 UTC
view on stackexchange narkive permalink

De CCS-compiler voor de PIC wordt geleverd met een eenvoudige RTOS. Ik heb het niet geprobeerd, maar als je deze compiler hebt, zou het gemakkelijk zijn om mee te experimenteren.

Ik heb dit eigenlijk als mijn eerste geprobeerd. Het is geen RTOS in de echte betekenis van het woord. Het is op geen enkele manier preventief. Het vereist regelmatig gebruik van opbrengstopdrachten, zodat de RTOS kan beslissen wie de volgende keer draait, je moet ze opzettelijk constant invoeren voor het geval een ander programma het moet overnemen.
Ik denk dat het nog steeds een RTOS wordt genoemd. Het klinkt gewoon alsof het een coöperatieve planner heeft in plaats van een volledig preventieve planner.
Ja, het is technisch nog steeds een RTOS, maar ik had er nog steeds weinig waarde voor. Ik weet dat het iets persoonlijks is, maar voor mij moet het preventief zijn om waardevol te zijn. Ik geef nog steeds een +1 omdat het een goed antwoord was en waardevol.
#8
+3
davidcary
2010-06-10 02:28:42 UTC
view on stackexchange narkive permalink

Nauw verwante vraag: https://stackoverflow.com/questions/1624237/multithreading-using-c-on-pic18

Bedankt! Het lijkt erop dat de meeste mensen de vraag niet hebben gekregen, maar het is nog steeds interessant.
Ik heb op de vraag op SO gepost en de gebruiker uitgenodigd om naar E&R te komen voor hulp!
Ik denk dat we de vraag over SO hebben "gekregen", het was iets anders maar gerelateerd aan deze vraag. Wat betreft uw opmerking daar over certificering; dat hangt van veel dingen af. Kijkend naar de antwoorden hier, vind ik het antwoord van DoxaLogos dat verwijst naar QP-nano; mijn ervaring leidt me ertoe om gebeurtenisgestuurde code te verkiezen boven threads en impliciete contextomschakeling van threads.
#9
+2
Rocketmagnet
2011-01-25 04:32:27 UTC
view on stackexchange narkive permalink

Je hebt niet veel gezegd over je sollicitatie. Of je een RTOS gebruikt, hangt sterk af van wat je moet doen in de PIC. Tenzij je verschillende asynchrone dingen doet, waarvoor strikte tijdslimieten nodig zijn, of als er meerdere threads actief zijn, kan een RTOS overdreven zijn.

Er zijn veel manieren om de tijd op een microcontroller te organiseren, afhankelijk van wat belangrijkste:

  1. Constante framesnelheid: voor een PIC met een servocontroller die bijvoorbeeld op 1000Hz moet draaien. Als het PID-algoritme minder dan 1 ms nodig heeft om uit te voeren, dan kunt u de rest van de milliseconde gebruiken om andere taken uit te voeren, zoals de CAN-bus controleren, sensoren lezen, enz.

  2. Alle onderbrekingen: alles wat er in de PIC gebeurt, wordt geactiveerd door een onderbreking. De interrupts kunnen worden geprioriteerd op basis van het belang van de gebeurtenis.

  3. Houd het in een lus en doe alles zo snel mogelijk. Misschien vindt u dit geschikte tijdslimieten.

Ik begrijp andere methoden, maar ik wil uitbreiden naar een RTOS. Ik zal meerdere taken uitvoeren en een moeilijk real-time systeem hebben, maar ik ben bereid om te beginnen zonder de vereisten van harde real-time. Bedankt dat je de tijd hebt genomen om te antwoorden, maar ik wil een RTOS leren zodat ik het kan gebruiken in een situatie met veel vraag.


Deze Q&A is automatisch vertaald vanuit de Engelse taal.De originele inhoud is beschikbaar op stackexchange, waarvoor we bedanken voor de cc by-sa 2.0-licentie waaronder het wordt gedistribueerd.
Loading...