Forums

Favorite VM for development?

Started by Dave Nadler July 12, 2014
So here I am, trying to (again) help (another) customer whose previous consultant didn't leave complete sources and tools, and who cannot reproduce their production firmware. Aarrgggg...

In past, we've required customers to install the tools and do the builds from our delivered sources, but that is time-consuming for them and doesn't yield repeatable results for certain toolchain installations that wander off and fetch mysterious components from the net (and make it impossible to back up an installation snapshot).

So, to avoid further repeats, I'm going to do development in a (windows 7 32-bit) VM with EVERYTHING required. Deliveries will be copies of the VM and I will ensure the customer actually rebuilds their production releases in the delivered VM. No more confusion about which version of tools, libraries, sources, etc....

I've avoided doing this in past because of VM problems:
- USB bugginess and/or performance interfering with JTAG dongles, and
- VM performance
- annoying 100GB delivery files

What VMs have you guys used successfully?
The tools for this customer's projects include:
- Microchip MPLABX with ICD-3 debug adapter
- TI CCS for MSP430 (GCC version) using TI MSP-FET430UIF
- (phasing out) Rowley Crossworks for MSP430 using TI adapter

Host for the VM will be Win7 32-bit, and later Linux and Win7 64-bit.

I've used QEMU in past for developing inside a Linux VM, and VMware player for a WinXP machine. I tried VirtualBox but was stymied by USB issues. But all of these were at least a couple years ago...

Any advice, suggestions, warnings much appreciated!
Thanks,
Best Regards, Dave
Dave Nadler <drn@nadler.com> writes:
> What VMs have you guys used successfully?
I've used VMware for something like this and it worked pretty well though USB wasn't involved. Another idea might be to deliver on real hardware (a cheap laptop, say) instead of a VM.
Dave Nadler wrote:
> So here I am, trying to (again) help (another) customer whose previous consultant didn't leave complete sources and tools, and who cannot reproduce their production firmware. Aarrgggg... > > In past, we've required customers to install the tools and do the builds from our delivered sources, but that is time-consuming for them and doesn't yield repeatable results for certain toolchain installations that wander off and fetch mysterious components from the net (and make it impossible to back up an installation snapshot). > > So, to avoid further repeats, I'm going to do development in a (windows 7 32-bit) VM with EVERYTHING required. Deliveries will be copies of the VM and I will ensure the customer actually rebuilds their production releases in the delivered VM. No more confusion about which version of tools, libraries, sources, etc.... > > I've avoided doing this in past because of VM problems: > - USB bugginess and/or performance interfering with JTAG dongles, and > - VM performance > - annoying 100GB delivery files > > What VMs have you guys used successfully? > The tools for this customer's projects include: > - Microchip MPLABX with ICD-3 debug adapter > - TI CCS for MSP430 (GCC version) using TI MSP-FET430UIF > - (phasing out) Rowley Crossworks for MSP430 using TI adapter > > Host for the VM will be Win7 32-bit, and later Linux and Win7 64-bit. > > I've used QEMU in past for developing inside a Linux VM, and VMware player for a WinXP machine. I tried VirtualBox but was stymied by USB issues. But all of these were at least a couple years ago... > > Any advice, suggestions, warnings much appreciated! > Thanks, > Best Regards, Dave >
I've had excellent results with all of VirtualBox, VmLite and VMWare. I'd give VirtualBox a slight edge because the documentation is quite good. USB support seems okay - with the exception that I always have to do a forced remount ( -o force ) of spinning USB drives on an old SuSE 11.0 VM. I've no way of knowing right now if that's an artifact of SuSE, VirtualBox or the Win8 host. It's hardly a show-stopper and it may actually be fixable. The VM files themselves are considerably less than 100GB in my case. This being said, I'm not trying to connect a JTAG adapter. That's probably the main risk here. -- Les Cargill
Les Cargill <lcargill99@comcast.com> wrote:
> USB support seems okay - with the exception that I always > have to do a forced remount ( -o force ) of spinning USB drives on an > old SuSE 11.0 VM. I've no way of knowing right now if that's an > artifact of SuSE, VirtualBox or the Win8 host. It's hardly a > show-stopper and it may actually be fixable. > > The VM files themselves are considerably less than 100GB in my case. > > This being said, I'm not trying to connect a JTAG adapter. > That's probably the main risk here.
I've done USB JTAG things on VMWare Fusion: Mac OS host, Win 7 guest. It works fine, with the exception of USB3 devices which VMWare doesn't have a Windows guest driver for. Putting a USB2 hub between the device and the machine should fix it. It's quite neat in that, whenever you plug in a USB gadget, it asks whether you want to connect it to Mac or choose a VM to connect to (you can of course remember this setting). Theo
Dave Nadler wrote:

> So here I am, trying to (again) help (another) customer whose previous > consultant didn't leave complete sources and tools, and who cannot > reproduce their production firmware. Aarrgggg... > > In past, we've required customers to install the tools and do the builds > from our delivered sources, but that is time-consuming for them and > doesn't yield repeatable results for certain toolchain installations that > wander off and fetch mysterious components from the net (and make it > impossible to back up an installation snapshot). > > So, to avoid further repeats, I'm going to do development in a (windows 7 > 32-bit) VM with EVERYTHING required. Deliveries will be copies of the VM > and I will ensure the customer actually rebuilds their production releases > in the delivered VM. No more confusion about which version of tools, > libraries, sources, etc.... > > I've avoided doing this in past because of VM problems: > - USB bugginess and/or performance interfering with JTAG dongles, and > - VM performance > - annoying 100GB delivery files > > What VMs have you guys used successfully? > The tools for this customer's projects include: > - Microchip MPLABX with ICD-3 debug adapter > - TI CCS for MSP430 (GCC version) using TI MSP-FET430UIF > - (phasing out) Rowley Crossworks for MSP430 using TI adapter > > Host for the VM will be Win7 32-bit, and later Linux and Win7 64-bit. > > I've used QEMU in past for developing inside a Linux VM, and VMware player > for a WinXP machine. I tried VirtualBox but was stymied by USB issues. But > all of these were at least a couple years ago... > > Any advice, suggestions, warnings much appreciated!
For processors like the MSP430 and on up through ARM Cortex families I would suggest that giving the Forth VM a consideration might be worth your while. I am not sure the Microchip MPLABX (PIC?) is covered by any of the vendors of Forth but you never know until you start asking.. The two main vendors for Forth are:- MPE Ltd. <http://www.mpeforth.com/> Forth Inc. <http://www.forth.com/> For the MSP430 there is 4E4th and MSP430Lite from MPE. There is also an ARM- Forth Lite for the ARM Core M0 and M1. You might have to speak to Steve Pelc about getting those. On the other hand, the professional versions will provide things like the USB and Networking stacks along with a host of other goodies. In case you haven't come across Forth before, it is an extensible development environment that enables the construction of Application Specific Languages. It is based on a twin-stack VM that enables you to eliminate the need for a wide range of global variables and is an amplifier of the programmers capabilities. There is a simple philosophy behind Forth that enables you to construct solutions according to your preferred style. My style is Component Oriented and I can fully certify my code to a level equivalent to hardware CofC. Many other Forthists utilise a mix of Functional and Object Oriented programming. I will warn you, however, the Forth mindset, is quite a bit different from all of the Algol family of languages (C etc). So the Forth way might not suit you. There are a number of books available (some for free in digital formats) that will help you understand Forth and its Philosophy. Absorbing the Forth philosophy can be tremendously powerful or, if you don't get it well enough, be a complete disaster. It works very well for me though. -- ******************************************************************** Paul E. Bennett IEng MIET.....<email://Paul_E.Bennett@topmail.co.uk> Forth based HIDECS Consultancy.............<http://www.hidecs.co.uk> Mob: +44 (0)7811-639972 Tel: +44 (0)1235-510979 Going Forth Safely ..... EBA. www.electric-boat-association.org.uk.. ********************************************************************
Paul E Bennett <Paul_E.Bennett@topmail.co.uk> writes:
>> What VMs have you guys used successfully? > For processors like the MSP430 and on up through ARM Cortex families I would > suggest that giving the Forth VM a consideration might be worth your while.
Dave wasn't asking about a VM to run on the target processor, but rather, a way to bundle up a completely configured dev environment involving a lot of third party Windows tools into a blob that the customer could host on their own computer, without having to individually install and configure all the different tools. Forth is an interesting idea in the sense that it replaces all those separate tools with a single, relatively small "do everything" app, avoiding many of the install/configure hassles. But, by the same mechanism, it completely takes over the whole development process including imposing use of a programming language that has some nice properties but is rather far outside the current mainstream. It might be worth looking at but it's not for everyone.
Paul Rubin wrote:

> Paul E Bennett <Paul_E.Bennett@topmail.co.uk> writes: >>> What VMs have you guys used successfully? >> For processors like the MSP430 and on up through ARM Cortex families I >> would suggest that giving the Forth VM a consideration might be worth >> your while. > > Dave wasn't asking about a VM to run on the target processor, but > rather, a way to bundle up a completely configured dev environment > involving a lot of third party Windows tools into a blob that the > customer could host on their own computer, without having to > individually install and configure all the different tools. > > Forth is an interesting idea in the sense that it replaces all those > separate tools with a single, relatively small "do everything" app, > avoiding many of the install/configure hassles. But, by the same > mechanism, it completely takes over the whole development process > including imposing use of a programming language that has some nice > properties but is rather far outside the current mainstream. It might > be worth looking at but it's not for everyone.
Hadn't considered he would be looking at the other level that is probably more suited to Eclipse and the like. Then, being the Forthist I am, I would not think to such a gargantuan level as a baseline. Hope he remembers to include the CM tools. -- ******************************************************************** Paul E. Bennett IEng MIET.....<email://Paul_E.Bennett@topmail.co.uk> Forth based HIDECS Consultancy.............<http://www.hidecs.co.uk> Mob: +44 (0)7811-639972 Tel: +44 (0)1235-510979 Going Forth Safely ..... EBA. www.electric-boat-association.org.uk.. ********************************************************************
Paul E Bennett <Paul_E.Bennett@topmail.co.uk> writes:
> Hadn't considered he would be looking at the other level that is probably > more suited to Eclipse and the like. Then, being the Forthist I am, I would > not think to such a gargantuan level as a baseline. Hope he remembers to > include the CM tools.
Yes, that is the idea. He wants to package up a complete Windows installation that's loaded up with the kitchen sink and everything else, in a way that the customer can run the whole shebang on their own hardware without a lot of hassle. The conceptually simplest approach is to just ship a full hard drive snapshot of the development system, but that can fail if the origin and destination computers aren't identical. That's why the virtualization is needed. In the Linux world, the approach has become very popular using lightweight containers like LXC or Docker rather than full-blown virtualization. I wonder if something like that might work for Windows.
On Sun, 13 Jul 2014 02:01:08 +0100, Paul E Bennett
<Paul_E.Bennett@topmail.co.uk> wrote:

>Paul Rubin wrote: > >> Paul E Bennett <Paul_E.Bennett@topmail.co.uk> writes: >>>> What VMs have you guys used successfully? >>> For processors like the MSP430 and on up through ARM Cortex families I >>> would suggest that giving the Forth VM a consideration might be worth >>> your while. >> >> Dave wasn't asking about a VM to run on the target processor, but >> rather, a way to bundle up a completely configured dev environment >> involving a lot of third party Windows tools into a blob that the >> customer could host on their own computer, without having to >> individually install and configure all the different tools. >> >> Forth is an interesting idea in the sense that it replaces all those >> separate tools with a single, relatively small "do everything" app, >> avoiding many of the install/configure hassles. But, by the same >> mechanism, it completely takes over the whole development process >> including imposing use of a programming language that has some nice >> properties but is rather far outside the current mainstream. It might >> be worth looking at but it's not for everyone. > >Hadn't considered he would be looking at the other level that is probably >more suited to Eclipse and the like. Then, being the Forthist I am, I would >not think to such a gargantuan level as a baseline. Hope he remembers to >include the CM tools.
You're still not thinking big enough. He wants to take an entire virtual machine image, from the operating system on up, and hand that disk image file to the customer. Eclipse (or whatever), compilers, etc., would be installed *in* that virtual machine image. IOW, it's an image of an entire virtual PC with the entire development environment installed. The customer then boots that virtual machine under VMWare, Hyper-V or whatever hypervisor gets picked for this task, and they've got the exact, and complete, development environment.
Hi Dave,

On 7/12/2014 11:20 AM, Dave Nadler wrote:
> So here I am, trying to (again) help (another) customer whose > previous consultant didn't leave complete sources and tools, and who > cannot reproduce their production firmware. Aarrgggg...
<grin> Amazing how often this happens! Even folks missing *sources*! (oops!)
> In past, we've required customers to install the tools and do the > builds from our delivered sources, but that is time-consuming for > them and doesn't yield repeatable results for certain toolchain > installations that wander off and fetch mysterious components from > the net (and make it impossible to back up an installation > snapshot). > > So, to avoid further repeats, I'm going to do development in a > (windows 7 32-bit) VM with EVERYTHING required. Deliveries will be > copies of the VM and I will ensure the customer actually rebuilds > their production releases in the delivered VM. No more confusion > about which version of tools, libraries, sources, etc....
This *can* work. But, there are caveats. Of course, one assumes customer has valid licenses, none are node-locked to *your* particular machine, etc. I think the more practical issue is how completely you can (re)produce the development environment FROM THE CUSTOMER'S POINT OF VIEW. I.e., does *your* environment accurately reflect EVERYTHING the customer uses AT HIS END? For example, my VC/CM system isn't replicated at any client. So, I have hooks to fetch sources, tools, etc. from *my* system built into my makefiles, etc. These simply don't make sense for the client. OTOH, he may have *different* tools and hooks to perform similar operations. As well as other tools with which they haven't bothered to involve you. E.g., I have a couple of projects with tie-ins to mechanical designs that I must be aware of; others where I am insulated from all that (along with the client's tools supporting those aspects).
> I've avoided doing this in past because of VM problems: - USB > bugginess and/or performance interfering with JTAG dongles, and - VM > performance - annoying 100GB delivery files
Install a removable drive carrier, external "dock", etc. and just buy a bunch of small (e.g., 80-160GB) drives that you use AS IF "removable media". Any drive technology (other than PATA) should work well (I use FC, SATA, SCA and SAS drives). If you are shipping media, you might opt for solid state drives and encourage your clients to "recycle" them (back to you! or, bill them for "media charges" in each deliverable)
> What VMs have you guys used successfully? The tools for this > customer's projects include: - Microchip MPLABX with ICD-3 debug > adapter - TI CCS for MSP430 (GCC version) using TI MSP-FET430UIF - > (phasing out) Rowley Crossworks for MSP430 using TI adapter > > Host for the VM will be Win7 32-bit, and later Linux and Win7 > 64-bit. > > I've used QEMU in past for developing inside a Linux VM, and VMware > player for a WinXP machine. I tried VirtualBox but was stymied by USB > issues. But all of these were at least a couple years ago... > > Any advice, suggestions, warnings much appreciated! Thanks, Best > Regards, Dave
I ended up moving my VM's (VMware) off my development systems and onto a host that *only* runs VM's. I found it was leading to flakey behaviour on the tools NOT running under the VM's on those systems (easier to move them all than fight the flakiness).