Sorry, I think that's a silly argument. There is bad software that only=20 works on specific motherboards, chipsets, etc too. A virtual machine is=20 effectively just a different kind of base system with very high jitter=20 on timing and fewer interface options (usually no PCI, etc). Multitasking OSes split process time and run stuff in fits and starts...=20 simple as that. As a virtual machine usually runs as a process itself,=20 the timing jitter within the virtualized system is high and that jitter=20 gets pushed into the virtualized kernel space where device drivers that=20 depend on less jitter will fail. My point is if you plan on involving a PC you should design a system=20 that can handle jitter. The "XP compatibility mode" of 7 is a virtual machine. More and more,=20 software is moving to a virtualized sandbox of one kind or another.=20 There are more and more Mac systems these days, and they need virtual=20 machine software to run Windows apps. The likely future is more=20 virtualization, not less. It's the timing jitter that most often kills fragile designs. Sometimes=20 you've got a specific legacy protocol you don't have a choice about...=20 but when there's a choice... choose something that's got the best chance=20 to work for people in the future. In fact... debugging a USB device in a virtual machine is a pretty good=20 idea. It will likely bring up some issues that may bleed over to=20 different motherboards you haven't tried yet or use cases you haven't=20 tried yet (hubs, etc). It helps to get to a robust product. Darron On 2/2/14, 4:10 PM, David C Brown wrote: > How can it claim to be a virtual machine if it won't run software that wi= ll > run on the system that it is virtualising? > > > On 2 February 2014 20:31, Darron Black wrote: > >> On 2/2/14, 12:36 PM, Wouter van Ooijen wrote: >>> Dwayne Reid schreef op 02-Feb-14 7:12 PM: >>>> Generally, I reset a timer every time a new byte comes in. When the >>>> timer expires, I consider that to be the end of the packet. >>>> >>>> That works pretty well for me but in my case, the bytes are fairly >>>> close to each other, and the time between packets is much longer than >>>> one byte time. This doesn't work if the packets are really close >> together. >>>> >>> And you'll get in trouble when an usb-to-serial converter is used. >>> >>> Wouter >> Yes... or virtual machines. >> >> I've had to write and maintain kernel-level device drivers that only >> exist to properly manage timeouts on otherwise straightforward serial >> level protocols. Even those drivers usually won't work when running >> software from virtual machines. >> >> If you're making a product, don't screw it all up with systems >> requirements from the 1990s. >> >> I will avoid any product if I can't run the user software or a >> development environment from a virtual machine. There's no excuse for >> that these days. >> >> >> Darron >> >> -- >> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive >> View/change your membership options at >> http://mailman.mit.edu/mailman/listinfo/piclist >> > > --=20 http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .