From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: Xen for real-time/embedded/automotive Date: Thu, 28 Nov 2013 13:03:33 +0100 Message-ID: <1385640213.20797.116.camel@Abyss> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8445803519252405063==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Simon Martin Cc: Lars Kurth , Roland Heusser , Artem Mygaiev , Lovene Bhatia , Sisu Xi , Stefano Stabellini , George Dunlap , Joshua Whitehead , xen-devel , Drek Darkover , Stefano Panella , Nate Studer , mdavis@planetaryresources.com List-Id: xen-devel@lists.xenproject.org --===============8445803519252405063== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-H+oW0FK3cQ7q8smadDN9" --=-H+oW0FK3cQ7q8smadDN9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On gio, 2013-11-28 at 11:39 +0000, Simon Martin wrote: > =20 > > BTW, I do realise only know that I probably never asked that... What > > is=20 > > (if you feel like saying it here) your specific usecase / final goal > > of=20 > > this work?=20 > > =20 > I am porting an motion control system to Xen. The OS and hardware is > developed in house. I originally wrote the OS about 20 years ago on a > TI DSP processor with 32 k words of RAM and it has been evolving since > then, migrating to different processors (MIPS/ARM) and an ever > increasing amount of memory (we moved from SRAM to DRAM when we went > on to the MIPS platform, and the smallest DRAM chips you could get at > the time were 1 MB). > That's very cool! You know, at some point, probably when you/we would have a bit more of this in place, I'll probably ask if you want to write a post on our blog (http://blog.xen.org/) about it! :-D =20 > Looking at the Real-Time Xen project, it is built around millisecond > resolution. That was fine for motion control about 20 years ago, but > nowadays everyone is working sub-millisecond.=20 > Yeah, well, let's investigate what the limit is and try to push harder on it then. From my previous experience with real-time on Linux, it's possiblee to go sub-milliseconds, although not without some tricks. Personally, I think it's both possible and worthwhile to try to figure out what are the tricks required for us to get as near as possible to that! > Our existing systems can close the control loop every 125 =C2=B5s doing > full interpolation on 8 axes with 64 bit resolution on an ARM11 > platform. Worst than that, jitter on the control loop gives you at > best jerky movement and at worst shuts down the drives so that must be > controlled. > =20 HeHe... It's about Linux, but I just can't resist: <> Torvalds, Linus (2007) Of course, substitute 'Linux' with 'Xen', and PREEMPT_RT with either RT-Xen, or whatever we could come up with in the long run! :-P :-P Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-H+oW0FK3cQ7q8smadDN9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) iEYEABECAAYFAlKXMRUACgkQk4XaBE3IOsTp1wCgo8aXvxtCX+OXrNZNLuGdnWBN haIAoJMnBqVNgZEVoIyF5yPtI3lvJyMp =KOXi -----END PGP SIGNATURE----- --=-H+oW0FK3cQ7q8smadDN9-- --===============8445803519252405063== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============8445803519252405063==--