square bullets

This takes an assembly soutce file in my preferred format (.MAC), preprocesses if for the assembler, assembles, reformats the listing .LUG (Listing, UGly) file, builds a rom image file from the uP code and three FPGA config files, adds the checksum, and splits the rom image into high and low byte things. There's a readme.txt file with each release, too, discussing who/what/why/when.

REM - GO.BAT : BATCH FILE TO BUILD THE V375 PROGRAM FILE 22376D.ROM REM - REM - V375 FIRMWARE RELEASE 'D' REM - (22376 FOR ASSEMBLY REV B, C) REM - REM - REV A MW JULY 2, 2003 REM - REV B MW AUG 21, 2003 REM - REV C SP OCT 01, 2004 REM - REV D JL JAN 12, 2005

ECHO OFF CLS

PREP32 22376D C32C 22376D.ASM -L 22376D.LUG -H 22376D.HEX > 0.ERR POST32 22376D /N

DEL 22376D.ASM DEL 22376D.LUG

BRICK 22376D.ROM/2M = 22376D.HEX 22377C.RBT/14000 22378E.RBT/20000

SPLIT 22376D.ROM

TYPE 0.ERR

I don't trust processes that have different paths for "development" and "manufacturing" targets. I prefer to have a debug parm or equate that includes debug code, and delete all generated code before building for manufacturing.

Make can be written like a batch file. Again, I don't like different processes or paths through processes.

I sorta did that when I was designing FPGAs, though there were several "DO IT" buttons (synthesize, place-n-route, burn prom,...).

No software in the world will solve an out-of-control process. OTOH, I don't understand how he "put" it back unchanged. CVS doesn't update unchanged modules. At least with our version of CVS this would work fine. If two people work on the same module and make different changes it'll flag it as an issue and try to piece the thing back together, showing what it did.

That's the nice thing about CVS. If I want to build Version 002 (we're now on 021), I simply tell CVS to that I wish to check out version 002. I expect it's a lot of work to set up for a one-man shop, but it is invaluable when there are hundreds. I talked with an engineer in a one-man shop that has everything under CVS control with another computer across country mirroring the CVS repository.

When I was doing 8051 assembly I'd put write the readme as ASM51 comments and include it in the main program module (which only has the register definitions, interrupt vectors, and startup branch). The documentation was then printed with the full listing.

Make created ROM images as well.

In article , Keith wrote: [...]

My "README.TXT" often says "See the comments in ..."

Often my source files will have comments that say "See the comments in ..." I don't assume that the full listing will be viewed by the next poor sucker. I assume that at least he has a good editor that lets him open multiple files. I even end up drawing ASCII art schematics and timing diagrams to document what the code is doing.

Basically, all the documentation I do is in the form of comments. I've seen too many cases where the documentation goes missing. Also any file that is not "plain ascii" or HTML can't be read by any known program is it is over about 5 years old. Documents in WordStar format are fairly easy to recover but XYWrite is a bit tricky.

In article , Keith wrote: [.. make stuff..]

I don't understand the "different paths" comment here.

This CVS program would put an "unchanged" version. Basically all it really did was take the lock off the archived version and delete the copy on your machine.

This one kept some key information in funny comments in the source file. There had to be a comment that explained to it how to do a comment and then it would automatically put in a user readable history and a couple of magic values. If you munged the magic values at random, it would flag it but if it was an older copy of the file it would get confused and let it in.

We don't often want to remake old versions. If I do, I go get the CD and copy the contents into a directory and make it. It makes for a lot of disk useage.

With hundreds of people, you need a lot more management of these issues than with 1 to 4. At that point I would have CVS and a person assigned to the task of kicking anyone who did as described earlier straight out the door.

(I wish you'd kept more of the context) Unless I misunderstand, your versions of make execute different paths in the make file. That doesn' tgive me a comfy feeling that the code generated is identical.

Ours doesn't check in or commit anything that hasn't changed.

Yes, in the header line or two. It has to be there but re-writes it each time it saves the module. When I add a module I grab the header off a random module and tack it on. CVS then puts what it wants there and all is magic.

Sounds like a broken version of CVS. AFAICT, ours looks at the latest version and the one being checked in. If they're the same nothing happens. If not it takes the header from the old one, updates it and saves the new. A "cvs add" teplaces the header with a v1.0 header.

We often use old versions. If we have a failure we might want to go back and see if that failure shows up on an earlier model. If not, what changed? Old versions are also useful for old product.

;-) While we don't have an assigned bouncer, it's pretty well self regulating. If the database gets screwed up we have to fix it.

Oh, that's what you mean.

No, I don't have different paths as such. The FLASH target depends on the binary file. The binary is what I debug with. To program the FLASH, we need a *.HEX file. That is done in the FLASH section.

That sounds like a good way to avoid the problem I had.

I think that's the big difference. Since it uses the old files header, nothing you've done in the new file can make it lose track of the older versions. If I ever am looking a CVS stuff again, I'll check for this.

We tend to "upgrade at our cost" older equipment. People like semi-free upgrades and it can be nice to get the old versions to go away. It makes customer services life much easier if the number of versions in the field is significantly less than the number of units.

The strongest threat I've ever used was to suggest that I would send (name withheld) over to talk to them. This person is technically sharp and a very hard worker but talking to him is like getting gum on your shoe.

I understand the FLASH part (I did that too, though built the ROM image every time - it only took milliseconds). What about the "virgin", or whatever you called it (see; snipping too close is not good ;).

That's why I was confused. I take a boatload of files away on my laptop and have never run into this problem. If I thought it was something others were working on I'd check it aout again just before I edited it, just to make sure we're not stepping on each other, though CVS willl identify this too.

Indeed. It does some sort of DIFF or SUPERC on the files (minus it's own headers) to determine whether the file has been changed. If two people check in different versions of the same file these sorts (DIFF or SUPERC) messages are included in the file and the check-in flags go bonkers.

Since our product is, perhaps, a million copies of hardware, many soldered onto boards, this would get a tad expensive. ;-) If it's a flash file, I would agree with your position. ...as long as the hardware is *IDENTICAL*. Any ECs made to the hardware would bring up a huge regression problem.

I guess we're a little different. It's enough to know that we're all in the same boat. If someone pisses in it, we all still have to bail. Forcing cow-orkers to do unnecessary work is frowned upon. ...sometimes it happens though.

In article , Keith wrote: [.. snipped all sorts of stuff I shouldn't have ..]

The "make clean" erases all the intermediate files leaving only the source code. Its a "fake target" in the make file. The advantage is that if you create some type of file other than *.OBJ, you only need to remember once that it needs to be removed too.

Who's CVS is this? Does it exist in both Windoze and Linux versions? I'll file the info in case my next project grows a bunch of software.

I'm at the other end of the spectrum. I don't sell one million systems for a dollar each. I sell one system for a million dollars. (really more like 10 for 100K)

Ok, so that's essentially just doing what I did by hand (delete

Dunno. I'm not involved in tool selection or setup. I (mainly) do logic verification. We run on AIX though.

Well, they're not exactly a dollar each, rather $100s (chips) to $100,000s (system), depending on where you draw the line. ;-)