RTlinux voor machinebesturing

[carbidsjitter]

Hallo forum leden van tweakers,

Ik ben bezig bij een bedrijf met een nieuwe besturing. Nu ben ik zover dat ik software moet gaan ontwikkelen voor een touchscreen met display en deze module moet ook de joysticks uitlezen en de machine aansturen.

De hardware die ik gebruik is:
http://www.karo-electronics.com/tx25.html

Nu heb ik eigenlijk de keus uit 2 besturingssystemen. WindowsCE of Linux.

Nu heb ik eerst gebeld met een officieele distrubiteur van WindowsCE, of je uberhaupt wel CE mag gebruiken voor een machine, die bij verkeerd gebruik een mens kan laten overlijden. Hij zei dat CE niet bij medische toepassingen mag worden gebruikt, maar wel bij de machine's van ons. Ook is CE realtime (wat ik nodig heb)

Nu wil ik de mogelijkheden van Linux ook onderzoek en hierbij zoek ik een bedrijf in nederland die bijvoorbeeld RTlinux zo configureerd dat ik de zekerheid heb dat bijvoorbeeld drivers niet de kernel laten vastlopen en het beiden van support.

Welk besturingssysteem zouden jullie kiezen ? Weten jullie hier bedrijven in Nederland die een RTlinux verkopen voor machinebesturingen?

[Soultaker]

Ik denk dat de verschillen vanuit een puur technisch perspectief vrij klein zijn. Of je Windows CE of RTLinux "mag" gebruiken is waarschijnlijk meer een juridische vraag waar je beter een ter zake kundige advocaat over kan raadplegen. Ik neem aan dat als het bedrijf waar je voor werkt potentieel levensbedreigende machines bouwt, ze wel op de hoogte zijn van de daarbij geldende normen?

Vanuit praktisch oogpunt ontlopen Windows CE en RTLinux elkaar niet zoveel. Qua "drivers die de kernel laten vastlopen" zullen beide wel meevallen, want de hardware die je op het oog hebt is vrij simpel. Ik zou me dan meer zorgen maken over de mogelijkheid van hardwarefalen.

[Refro]

Welke eisen stel je eraan? In windows CE is het keiharde realtime gedrag alleen van toepassing op interrupts. Een normale thread laten draaien met een vaste interval van bijv 100ms is redelijk onnauwkeurig (lees jitter van 1 tot 2 ms en ook nog wel grotere uitschieters) het is met prioriteiten wel wat nauwkeuriger te krijgen maar je blijft aangewezen op een niet hard realtime scheduler. Ook trekt windows CE voor grafisch spul nogal wat resources.

Ik ben nu aan een project bezig op CE hardware (312mhz x270) en we komen van 16 bittertje op 16mhz enkele tegenvallers zijn:
-Realtime gedrag
-Programmeren met threads en alle synchronisatie die hierbij komt kijken
-Grafische performance

Ik heb het idee dat je met RTLinux standaard dichter op de kernel zit en ook beter RT gedrag krijgt.

[carbidsjitter]

@soultaker. We zijn hier wel met normen bezig, maar dit is nieuw voor iedereen hier.
Over hardware falen zit ik ook niet zo in. De elektronica die de ventielen aansturen is goed getest. Ik hoef nu alleen op een juiste manier de canbus aan te sturen.

Het is een hydraulische machine. De aansturing van de cilinders wordt elke 1/100 seconde geupdate. Dit is gedaan, omdat je op deze manier vetragingen in de aansturing van de cilinders kunt maken.

Wanneer de chauffeur de joystick volluit aan stuurt, dan kun je instellen hoeveel % van de maximale sturing er elke 1/100 seconde bijkomt. Stel dit is 50 % dan is de cilinder in 2/100 seconde op de ingestelde maximale snelheid.

Tragere snelheden hebben we ook geprobeerd, maar dit gaat te schokkerig. Je kunt een verandering van een 1 % al merken.

Het moet dus aardig realtime werken.

Weten jullie mischien ook een bedrijf die RTlinux evt. kan leveren. Dan kan ik wat advies vragen en vrij snel op gang komen.

[Guru Evi]

RTLinux kun je hier verkrijgen:

http://www.rtlinuxfree.com/
http://www.fsmlabs.com
http://www.windriver.com/

Als je echter op zoek bent naar een programmeur of een softwarebedrijf die programma's voor RTLinux schrijft, dan ga je wel elders moeten zoeken.

[carbidsjitter]

Dank je wel voor de links. Ik neig toch steeds meer naar windowsCE. Ik ben bij het bedrijf waar ik bezig ben alleen qua elektronica en hardware. Het voordeel van CE is dat de 'toolchain' al klaar is. Ik kan in principe meteen beginnen met de applicatie code.

Het kost dan wel wat, maar dat weegt wel op tegen de uren die ik in linux moet steken.

Ook heeft een oud klasgenoot van mij interesse in het bordje en is er ook mee aan de slag gegaan. Deze is helemaal linux/mac minded. Hij heeft er al moeite mee om het allemaal werkend te krijgen.

@retro Die tegenvallers op realtime gedrag, hoe moet ik dat zien. Gebeuren bepaalde handelingen gewoon te laat ?

Ik vond trouwens nog een leuk filmpje van CE

http://www.bing.com/video...0-real-time-demo/qm5fkswc

[Refro]

[b][message=33481262,noline]carbidsjitter schreef op dinsdag 16 februari 2010 @ 16:10[/message@retro Die tegenvallers op realtime gedrag, hoe moet ik dat zien. Gebeuren bepaalde handelingen gewoon te laat ?

Dit heeft inderdaad voornamelijk met scheduling te maken zelfs als de thread een behoorlijk hoge prioriteit heeft kan het voorkomen dat ie blocked omdat een andere thread ergens een lock op heeft (kan ook een systeemthread zijn). En hierdoor niet op tijd aan de beurt komt bij de thread waar wij het meeste aan meten is deze jitter standaard als 1 tot 2 ms (gemeten met een scoop) en kan wel oplopen tot 30ms en dat op een thread die elke 100ms moet draaien en dan voor ongeveer 3ms rekenwerk heeft.

Dit gedrag is wel allemaal verklaarbaar maar niet fijn als je erop vertrouwd dat de scheduling behoorlijk hard is. Dit wordt ook nog verstrekt door multithreaded te werken en uiteraard de totale belasting van het systeem. Het kan allemaal een stuk harder qua timing als je met ISR en IST gaat werken maar als ik me het goed herinner speelt dat zich allemaal binnen het BSP af en das ook niet altijd even fijn.

De toolchain lijkt wel heel compleet bij CE maar je bent wel voor een groot deel van je BSP leverancier afhankelijk (ik gok KARO in dit geval) en deze pakken heel vaak ook gewoon het reference BSP en hebben er verder ook weinig verstand van. Ik denk dat een windriver zeker net zo'n goede ontwikkelomgeving heeft (greenhills in ieder geval wel) alleen zijn die wel duurder per stoeltje (al zit er meestal wel een stukje scholing bij en bij microsoft niet.

[carbidsjitter]

Karo levert een goede ondersteuning voor windows CE. Zo hebben ze allemaal voorbeeld applicatie's en allerlei drivers zelf geschreven en in de bsp als optie in platformbuilder gedaan. Ik heb zelf de can bus,display, touchscreen enz. nodig, dit zit er allemaal bij.

Ook met vragen zijn ze zeer snel en correct.

Ik zal het zelf moeten ervaren hoe RT windows ce is. Ik moet het allemaal nog wat in de vingers krijgen. Vooral het werken met de windows api's en OOP programmering. Ik kom zelf van de AVR kant, die ik gebruikt heb om de can bus signalen te vertalen naar hydraulisch ventiel aansturing. Het is wel weer een mooie uitdaging.

Als het allemaal wat af is laat ik jullie zeker het resultaat zien.

[Refro]

carbidsjitter schreef op woensdag 17 februari 2010 @ 16:42:
Karo levert een goede ondersteuning voor windows CE. Zo hebben ze allemaal voorbeeld applicatie's en allerlei drivers zelf geschreven en in de bsp als optie in platformbuilder gedaan. Ik heb zelf de can bus,display, touchscreen enz. nodig, dit zit er allemaal bij.

Ook met vragen zijn ze zeer snel en correct.

Niet om lullig te doen maar als je nog niets gekocht hebt zijn ze altijd snel, als dat nadat je iets gekocht hebt blijft heb je een goede leverancier te pakken. Ik heb beide meegemaakt een weinig support nadat je het gekocht heb zuigt, maar dat weet je vooraf natuurlijk nooit.

Ik zal het zelf moeten ervaren hoe RT windows ce is. Ik moet het allemaal nog wat in de vingers krijgen. Vooral het werken met de windows api's en OOP programmering. Ik kom zelf van de AVR kant, die ik gebruikt heb om de can bus signalen te vertalen naar hydraulisch ventiel aansturing. Het is wel weer een mooie uitdaging.

Als het allemaal wat af is laat ik jullie zeker het resultaat zien.

Op windows CE hoef je geen OO te doen C werkt net zo goed win32 api zijn ook in C (alles van MFC, .net etc zijn gewoon lagen bovenop de standaard win32C api). Zelf zou ik proberen zo weinig mogelijk nieuwe dingen te doen, want als je zowel een nieuwe GUI een nieuw OS en een nieuwe programmeertaal in een stap gaat doen is dat een behoorlijk groot risico. Hoogstwaarschijnlijk gaat dit ook tegenvallen en duurt het project veel langer als ooit de bedoeling was. Ga je het trouwens allemaal zelf doen of huren jullie iemand in om te assisteren?

Oja en bij ons hadden we ook nog de tegenvaller met persistence we stapten van battery backed up ram over naar een filesysteem en dan moet je netjes afsluiten enzo anders raakt je settings file corrupt (mischien niet na 1x maar wel na 100x of 1000x en dan is de vraag wat je daar acceptabel vind).

[carbidsjitter]

De support is goed. We hebben dat tx25 bordje bij een partner van hun gekocht en ze zijn nu nog goed.

In principe ben ik alleen, maar ik heb zo wel m'n contacten dus voor gebrek aan kennis ben ik niet zo bang voor.

idd, het is wel een erg steile leer curve als ik alles tegelijk wil doen. C programmeren heb ik goed in de vingers.

Als eerst de onderliggende basis qua Cabus en joystick uitlezing maar goed is, Dan kan er worden getest bij de klant. Dat heb ik vrij snel voor elkaar. Er loop nu al een machine met het nieuwe spul, alleen hier zit nog niet het display in gemonteerd maar tijdelijk een andere kastje om de joystick signalen te vertalen naar de canbus.

Je moet toch ergens beginnen.