EmbeddedRelated.com
Forums

Re: Release/Revision standard notation?

Started by Jim Thompson December 9, 2008
On Tue, 09 Dec 2008 08:04:34 -0800, Joerg
<notthisjoergsch@removethispacbell.net> wrote:

>Paul Carpenter wrote: >> In article <C2k%k.6422$hc1.2452@flpi150.ffdc.sbc.com>, >> notthisjoergsch@removethispacbell.net says...
[snip]
>> >> Well actually if you think about you have proved my point, that the >> customer was lucky that SOMEBODY had archived the tools and systems >> otherwise the data was almost useless. >> > >It would not have been useless. I would have searched and searched until >the old SW tool and a contractor with the necessary skills are found.
Counting on old SW tools running on a modern PC, with who knows what variant of Wimpows, is very dangerous. While I do maintain archives in native SW language, I also archive device model and symbol libraries (text), netlists (text) and PDF versions of all schematics. I would hate to have to re-enter such stuff into a new SW, but I have done it... like some ancient SDT III stuff for which the symbol libraries went bye-bye :-( ...Jim Thompson -- | James E.Thompson, P.E. | mens | | Analog Innovations, Inc. | et | | Analog/Mixed-Signal ASIC's and Discrete Systems | manus | | Phoenix, Arizona 85048 Skype: Contacts Only | | | Voice:(480)460-2350 Fax: Available upon request | Brass Rat | | E-mail Icon at http://www.analog-innovations.com | 1962 | I love to cook with wine Sometimes I even put it in the food
On Tue, 9 Dec 2008 09:11:09 -0600, krw <krw@att.zzzzzzzzz> wrote:

>In article <3borj41d16scak476udpq3ofvs34sdb178@4ax.com>, >jjlarkin@highNOTlandTHIStechnologyPART.com says...> >> On Mon, 08 Dec 2008 17:42:55 -0800, Joerg >> <notthisjoergsch@removethispacbell.net> wrote: >> >> >Paul Carpenter wrote: >> >> In article <MPG.23a72548c1ca82ce9896ee@news.individual.net>, >> >> krw@att.zzzzzzzzz says... >> >>> In article <MPG.23a76baff80d79d39896c7@172.16.0.1>, >> >>> paul@pcserviceselectronics.co.uk says...> >> >>>> In article <MPG.23a706ae1955768d9896ec@news.individual.net>, >> >>>> krw@att.zzzzzzzzz says... >> >>>>> In article <8f4bbb1b-c188-4ede-b2de- >> >>>>> f406e934aaaa@r36g2000prf.googlegroups.com>, pomerado@hotmail.com >> >>>>> says...> >> >>>>>> On Dec 7, 11:46 am, John Larkin >> >>>>>> <jjlar...@highNOTlandTHIStechnologyPART.com> wrote: >> >>>>>>> On Sun, 07 Dec 2008 17:01:23 +0000, John Devereux >> >>>>>>> >> >>>>>>> <j...@devereux.me.uk> wrote: >> >>>>>>>> John Larkin <jjlar...@highNOTlandTHIStechnologyPART.com> writes: >> >>>>>>>>> A hardware top assembly could be 28A346-3B, where -3 is a version >> >>>>>>>>> (literally the "dash number") and B is the rev. This is basic >> >>>>>>>>> aerospace notation. >> >>>> ... >> >>>>>>> like that. It keeps things together. >> >>>>>>> >> >>>>>>> Everything is formally released, archived, backed up. 10 years later, >> >>>>>>> we know exactly what was built when, and can build exact copies if we >> >>>>>>> need to. >> >>>>>>> >> >>>>>>> John >> >>>>>> Providing that you still have a computer that can read 5.25" disks. >> >>>>> Well, genius, most are smart enough to migrate their business >> >>>>> critical data to new systems when the old get replaced. >> >>>> Migrating code for tools no longer manufactured/sold actually means >> >>>> that the simpler and cost effective solution for some markets is >> >>>> actually to archive complete computer systems as changing the tools >> >>>> means revalidation/certification. Even if you could get the new versions >> >>>> of tools to work with newer computers/operating systems/etc.. >> >>> No one specified code, though that is a bigger problem. How much >> >>> bigger depends on the tools (another vote for VHDL vs. schematic, >> >>> IMO). >> >> >> >> There is no point archiving data that is in 90% of the time (or more) >> >> anything other than plain text, without the tools to read it, even if >> >> it is just to print out new copies. >> >> >> > >> >Not so. I once was called to a new client. The new design wasn't what >> >they tasked me with (but that happened immediately after this initial >> >job ...). They were way behind schedule, trade show coming up, so the >> >only avenue to save the bacon was to gussy up an old system. A really, >> >really old one. So I plunged in. Later in the day I presented my >> >findings to the CTO. Found out that a math function was completely >> >"missing" on a board where it definitely should have been. "What?!!" He >> >turned pale. Now came the real issue. This board hadn't been touched in >> >a decade or so, the SW guy was long gone but we managed to find him in a >> >phone book. Whew! Next night he agreed to come in. Luckily he brought a >> >stone-age compiler and computer that was able to read in the source >> >code. The reason we couldn't read any of the archives was that it needed >> >to be done under CP/M. I almost couldn't believe it. If they hadn't >> >archived those ancient files the trade show would have been gone and the >> >CEO mad as hell. >> >> >> We do archive tools to a server, which gets weekly backups. And we >> rolled all our old DOS PADS jobs forward into the newer Windows format >> before we retired the DOS machines. > >Do test the entire process on every OS release and hardware >upgrade?
No. Whenever the tools change, we dump another set into the M:\TOOLS folder, where the M-drive is our library server. That's probably enough to untange the mess if we really need to go back and rebuild an ancient software product. All my assembly stuff uses batch files and programs that run under DOS or the Windows command line. That includes a few homebrew things that we have the source code for. So far, I've been able to rebuild 10-12 year old stuff with no problems. I won't let any of my guys use tools that we can't archive and be reasonably sure we can run a decade or two into the future. If they use a VCS, each formal release must be a set of clean files, all on its own, independent of the VCS. And the next rev must start from those released files, not from what the VCS thought the last formal release was. KISS. John
Jim Thompson wrote:
> On Tue, 09 Dec 2008 08:04:34 -0800, Joerg > <notthisjoergsch@removethispacbell.net> wrote: > >> Paul Carpenter wrote: >>> In article <C2k%k.6422$hc1.2452@flpi150.ffdc.sbc.com>, >>> notthisjoergsch@removethispacbell.net says... > [snip] >>> Well actually if you think about you have proved my point, that the >>> customer was lucky that SOMEBODY had archived the tools and systems >>> otherwise the data was almost useless. >>> >> It would not have been useless. I would have searched and searched until >> the old SW tool and a contractor with the necessary skills are found. > > Counting on old SW tools running on a modern PC, with who knows what > variant of Wimpows, is very dangerous. >
Nope. All the DOS stuff I still need does run on all machines here. Of course there is no Vista in this here consulting office. Other trick: I recently installed Sun VirtualBox. That allows multiple virtual machines. If the Romans had any operating system even that would probably run. I tried Linux on it and when clicking that tab the whole Windows PC feels like a Linux PC. Nice thing is, after some tricks you can effortlessly scoot back and forth between OS'es and even copy-paste across platforms. So far the only thing that presented a bump in the road to backward compatibility was that old Borland runtime bug. But there is a massaging routine you can send your *.exe through that will fix it even if you don't have the source code for a re-compile.
> While I do maintain archives in native SW language, I also archive > device model and symbol libraries (text), netlists (text) and PDF > versions of all schematics. >
Same here.
> I would hate to have to re-enter such stuff into a new SW, but I have > done it... like some ancient SDT III stuff for which the symbol > libraries went bye-bye :-( >
You mean, you "lost" the symbol libraries? When I have my druthers I might fire up ye olde SDT-III again. It was one of the best products since sliced bread. -- Regards, Joerg http://www.analogconsultants.com/ "gmail" domain blocked because of excessive spam. Use another domain or send PM.
"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message 
news:uh6tj41eru4k0e0l9rgqi34k0cmr2fm5bl@4ax.com...
> I won't let any of my guys use tools that we can't archive and be > reasonably sure we can run a decade or two into the future.
I think that rules out most Microsoft compilers? :-) On Windows Vista, nothing prior to Visual Studio 2005 is officially supported... although it turns out that Visual Studio 6 from 1998 will 99% work with very minor workarounds. Of course, those workarounds are not found on Microsoft's web site :-( ...but Google knows where they are.
> If they > use a VCS, each formal release must be a set of clean files, all on > its own, independent of the VCS. And the next rev must start from > those released files, not from what the VCS thought the last formal > release was. KISS.
That's an entirely reasonable process that I doubt anyone would object to. I believe in "management by interfaces" -- use whatever tools you feel like, but when it comes time to release, we have a well-defined "interface" that says what your code has to do... or, in your case, how the code needs to be built. ---Joel
Joerg <notthisjoergsch@removethispacbell.net> writes:

> Jim Thompson wrote: >> On Tue, 09 Dec 2008 08:04:34 -0800, Joerg >> <notthisjoergsch@removethispacbell.net> wrote: >> >>> Paul Carpenter wrote: >>>> In article <C2k%k.6422$hc1.2452@flpi150.ffdc.sbc.com>, >>>> notthisjoergsch@removethispacbell.net says... >> [snip] >>>> Well actually if you think about you have proved my point, that >>>> the customer was lucky that SOMEBODY had archived the tools and >>>> systems >>>> otherwise the data was almost useless. >>>> >>> It would not have been useless. I would have searched and searched >>> until the old SW tool and a contractor with the necessary skills >>> are found. >> >> Counting on old SW tools running on a modern PC, with who knows what >> variant of Wimpows, is very dangerous. >> > > Nope. All the DOS stuff I still need does run on all machines here. Of > course there is no Vista in this here consulting office. > > Other trick: I recently installed Sun VirtualBox. That allows multiple > virtual machines. If the Romans had any operating system even that > would probably run. I tried Linux on it and when clicking that tab the > whole Windows PC feels like a Linux PC. Nice thing is, after some > tricks you can effortlessly scoot back and forth between OS'es and > even copy-paste across platforms.
VirtualBox is great. I use it "the other way round", i.e. linux host, windows guest(s). I do all my "windows" development and testing on it (Visual C++). You can also have all the different windows variants installed as separate images for software testing. When you have finished testing, just roll it back to the virginal "snapshot" for next time. [...] -- John Devereux
John Devereux wrote:
> Joerg <notthisjoergsch@removethispacbell.net> writes: > >> Jim Thompson wrote: >>> On Tue, 09 Dec 2008 08:04:34 -0800, Joerg >>> <notthisjoergsch@removethispacbell.net> wrote: >>> >>>> Paul Carpenter wrote: >>>>> In article <C2k%k.6422$hc1.2452@flpi150.ffdc.sbc.com>, >>>>> notthisjoergsch@removethispacbell.net says... >>> [snip] >>>>> Well actually if you think about you have proved my point, that >>>>> the customer was lucky that SOMEBODY had archived the tools and >>>>> systems >>>>> otherwise the data was almost useless. >>>>> >>>> It would not have been useless. I would have searched and searched >>>> until the old SW tool and a contractor with the necessary skills >>>> are found. >>> Counting on old SW tools running on a modern PC, with who knows what >>> variant of Wimpows, is very dangerous. >>> >> Nope. All the DOS stuff I still need does run on all machines here. Of >> course there is no Vista in this here consulting office. >> >> Other trick: I recently installed Sun VirtualBox. That allows multiple >> virtual machines. If the Romans had any operating system even that >> would probably run. I tried Linux on it and when clicking that tab the >> whole Windows PC feels like a Linux PC. Nice thing is, after some >> tricks you can effortlessly scoot back and forth between OS'es and >> even copy-paste across platforms. > > VirtualBox is great. I use it "the other way round", i.e. linux host, > windows guest(s). I do all my "windows" development and testing on it > (Visual C++). You can also have all the different windows variants > installed as separate images for software testing. When you have > finished testing, just roll it back to the virginal "snapshot" for > next time. >
I use both Windows and Linux guests in VirtualBox (on a Windows host). If you've got two Ethernet ports on your host PC, a cunning trick is to set up a bridge on the host with the second Ethernet port, and connect the port physically to your network. Then make host interfaces in VirtualBox and connect them to the bridge, and use them instead of NAT to your host. It gives you a much more direct networking connection.
David Brown <david.brown@hesbynett.removethisbit.no> writes:

> John Devereux wrote: >> Joerg <notthisjoergsch@removethispacbell.net> writes: >>
[...]
>>> >>> Other trick: I recently installed Sun VirtualBox. That allows multiple >>> virtual machines. If the Romans had any operating system even that >>> would probably run. I tried Linux on it and when clicking that tab the >>> whole Windows PC feels like a Linux PC. Nice thing is, after some >>> tricks you can effortlessly scoot back and forth between OS'es and >>> even copy-paste across platforms. >> >> VirtualBox is great. I use it "the other way round", i.e. linux host, >> windows guest(s). I do all my "windows" development and testing on it >> (Visual C++). You can also have all the different windows variants >> installed as separate images for software testing. When you have >> finished testing, just roll it back to the virginal "snapshot" for >> next time. >> > > I use both Windows and Linux guests in VirtualBox (on a Windows > host). If you've got two Ethernet ports on your host PC, a cunning > trick is to set up a bridge on the host with the second Ethernet port, > and connect the port physically to your network. Then make host > interfaces in VirtualBox and connect them to the bridge, and use them > instead of NAT to your host. It gives you a much more direct > networking connection.
I have not needed to delve into the networking yet - everything seems to work fine as it is. I did create a shared folder link so that my linux home directory appears as a drive letter in VirtualBox. I was surprised how good the hardware support is. It creats some kind of "virtual" USB controller, so you can use any USB device with the manufacturers drivers. I also use the "headless" mode where you can connect using a remote desktop ("rdesktop") session. So I can be working in the office, then move to the "lab" machine and carry on using that same session. -- John Devereux
John Devereux wrote:
> David Brown <david.brown@hesbynett.removethisbit.no> writes: > >> John Devereux wrote: >>> Joerg <notthisjoergsch@removethispacbell.net> writes: >>> > > [...] > >>>> Other trick: I recently installed Sun VirtualBox. That allows multiple >>>> virtual machines. If the Romans had any operating system even that >>>> would probably run. I tried Linux on it and when clicking that tab the >>>> whole Windows PC feels like a Linux PC. Nice thing is, after some >>>> tricks you can effortlessly scoot back and forth between OS'es and >>>> even copy-paste across platforms. >>> VirtualBox is great. I use it "the other way round", i.e. linux host, >>> windows guest(s). I do all my "windows" development and testing on it >>> (Visual C++). You can also have all the different windows variants >>> installed as separate images for software testing. When you have >>> finished testing, just roll it back to the virginal "snapshot" for >>> next time. >>> >> I use both Windows and Linux guests in VirtualBox (on a Windows >> host). If you've got two Ethernet ports on your host PC, a cunning >> trick is to set up a bridge on the host with the second Ethernet port, >> and connect the port physically to your network. Then make host >> interfaces in VirtualBox and connect them to the bridge, and use them >> instead of NAT to your host. It gives you a much more direct >> networking connection. > > I have not needed to delve into the networking yet - everything seems > to work fine as it is. I did create a shared folder link so that my > linux home directory appears as a drive letter in VirtualBox. >
A networking setup like mine is particularly useful if the host is windows. Linux has vastly more networking tools, so my VirtualBox setup lets me run these in a virtual Linux box (the NAT networking can't pass anything other than UDP and TCP/IP packets - no pings, arpings, or other protocols). It is also useful if you want to access the virtual machine directly on the network from other machines.
> I was surprised how good the hardware support is. It creats some kind > of "virtual" USB controller, so you can use any USB device with the > manufacturers drivers. >
I've found it can be a little unstable at times, but apart from that it is *very* useful using USB devices in the virtual machines. It's particularly useful if the drivers for the devices are not too great, or have conflicting versions, or if you want to test installation routines. Just make a snapshot of the virtual machine before they are connected, then try it out. If it doesn't work, you can quickly roll back.
> I also use the "headless" mode where you can connect using a remote > desktop ("rdesktop") session. So I can be working in the office, then > move to the "lab" machine and carry on using that same session. >
David Brown <david@westcontrol.removethisbit.com> writes:


[...]

> > A networking setup like mine is particularly useful if the host is > windows. Linux has vastly more networking tools, so my VirtualBox > setup lets me run these in a virtual Linux box (the NAT networking > can't pass anything other than UDP and TCP/IP packets - no pings, > arpings, or other protocols). It is also useful if you want to access > the virtual machine directly on the network from other machines. > >> I was surprised how good the hardware support is. It creats some kind >> of "virtual" USB controller, so you can use any USB device with the >> manufacturers drivers. >> > > I've found it can be a little unstable at times, but apart from that > it is *very* useful using USB devices in the virtual machines. It's > particularly useful if the drivers for the devices are not too great, > or have conflicting versions, or if you want to test installation > routines. Just make a snapshot of the virtual machine before they are > connected, then try it out. If it doesn't work, you can quickly roll > back.
Also I don't feel the need to run AV software on the Windows VM, or keep it continuously updated. Although *theoretically* still needed, I don't do much browsing or read email from Windows (and when I do it is with firefox). So that in itself speeds things up enormously. [...] -- John Devereux