square bullets

[Ken Smith]

I've never quite understood why we had to switch to a registry
approach.

For years and years INI files sufficed quite nicely.

Some might argue that that's the reason right there. With *.ini files you
didn't need to pay someone to fix your PC. How could microsoft create a
new priest class of softare gurus if mere mortals could understand the
stuff?

Some of my
"golden-oldies" work just fine under XP with just an INI file.

The next version fixes that all installs will default to automatically
deleting (I)nternet (N)etwork (I)ndex files. (AKA *.ini)

 

[John Larkin]

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
22379C.RBT/32000 /C:3F004

SPLIT 22376D.ROM

TYPE 0.ERR

 

[Keith]

Its better to create your Makefile with fake targets for that sort of
thing.

You can then type:

make clean to remove all temp files
make all to do a total debug build
make flash to make the shipped result (yes it goes in a flash)

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.

I use a combination of make files and batch files. There are some things
that make just doesn't do well. For these, a batch file that runs make
works better.

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

A GUI with only one button:


-------------------
! !
! ------- !
! ! DO IT ! !
! ------- !
! !

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

I've only ever worked on one project that used purchased CVS tools. It
got totally screwed up. We had one "programmer" who would "get" a file,
copy it to his Mac and then "put" it back unchanged. Later he would "get"
the file and over write it from his Mac and "put" the new version. This
totally screwed things for everyone.

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.

Since then it has been more like this:

Dave: I need to work on XYZ.A51
Ken: Ok here's a CD with it on
..... time passes ...
Dave: I'm done with XYZ.A51. Here's the changed version.

This along with making a full backup of the source at all important points
and always putting our names and the dates in the comments has worked well
for us.

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.

 

[Keith]

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.

<BAT file snipped>

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.

 

[Ken Smith]

When I was doing 8051 assembly I'd put write the readme as ASM51

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.

 

[Ken Smith]

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.

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

[....]

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.

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.

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.

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.

[....]

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.

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.

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.

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.

 

[Keith]

[.. make stuff..]
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.

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

(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.

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.

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 .

[...]

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

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

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.

[....]

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.

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.

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.

[....]

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.

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.

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.

[...]

;-) 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.

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.

<chuckle> 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.

 

[Ken Smith]

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 .

make clean to remove all temp files
make all to do a total debug build
make flash to make the shipped result (yes it goes in a flash)

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.

[...]
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.

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.


[...]

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'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)

 

[Keith]

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.

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

[...]
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.

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.

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

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)

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