design help

delay so

Batch files and README type stuff, and anything unique to the project, yes. The assembler and text editor and builder utilities are archived in our TOOLS folder on one of our servers, backed up to DVDs weekly. Any versions get a separate folder, so we always have the old ones. We must have hundreds of backups scattered all over the state by now.

There's no problem figuring out which tools are needed to rebuild a thing. The FPGAs are a bigger problem... we have some Actel designs that used Win3 Orcad under DOS with dongles, and *nobody* can rebuild them.

The advantage of simple tools is that they are easy to archive and revive. DOS boxes will live forever.

And engineering isn't allowed to build production units. Firmware gets to manufacturing as a formal document release on a CD; our librarian documents the release and puts the files on the library server.

Useless to me, except that the buggy results can be annoying.

We are living in the Dark Ages of computing.

John

Nice idea. My version had a common emitter driver, adding that and a base resistor to the parts count.

That set it behind in the parts-count derby, so I dumped it. Yours is better.

Cheers, James Arthur

John and John, instead of spouting you could just test it.

Good point.

Cheers, James Arthur

That's why so many use AACricuit for the task.

That only works if it's feasible to comprehend the design in its entirety. For a few KiB of uc code, that's realistic. For large scale desktop or server packages, it isn't.

For complex software, if you can't function without detailed knowledge of the entire system, then you simply can't function. Even if it was feasible to comprehend the entire system, it might take months or even years to do so, and changes will happen faster than you can absorb them.

You could have to re-write whole swathes from scratch to port the software to a different architecture, or even to a different version of the OS.

In a complex software package, you could have more code than that for a single dialog box. You could realistically have more than that just in the installer.

Lumping the design of microcontroller firmware and the design of application software together as "software" is like lumping the design of a microwave transceiver together with the design of a PC motherboard as "electronics".

Naw. Dis-parity. It is for bragging rights only.

Well, there's the BAV170.

Sure was, and the machine had cores that i could thread 4 wires through even today. (full 3-D core memory)

Yes, Escheresque terrain and buildings ("Ascending and Descending") were quite common back then.

Yep. Handy.

Vcc -+- | .---------------------o \\ | |_ o o .-. )| | | R1 )| | | _)| '-' | | ||-' | D1 |||---o-----o---||-+ | | | | \\ o | .-. R2 | \\ C1 --- | | === \\. --- | | GND o | '-' | | | === === === GND GND GND (created by AACircuit v1.28.4 beta 13/12/04

I might this weekend. I just shipped a new gadget today that I've been at all week, and I'm whupped at the moment.

John

Nearly choked me on me sourdough crêpe, 'at one did.

Cheers, James Arthur

This is sci.electronics.design. Most of the stuff we do meets that description. Why abstract setting a bit in a register (which I've seen people do) when you can set the bit in the register?

OS? What OS? And it's unlikely that we would port a working product to a new CPU just for fun.

Well, as I've said, I elect to not do stuff like that. And given that decision, I don't need an RTOS and C++ to set and clear bits.

This is sci.electronics.design.

John

What's the Hfe on that? I can't seem to find it on the datasheet.

John

I once got a gig porting a zillion lines of 80486 assembly to 'C'. In fact I learned 'C' then and there, for that task.

Lots and lots of lines--I don't recall how many--ported in no time. A couple weeks, IIRC.

It was easy. Worst part was that all the comments were in French.

Cheers, James Arthur

Typical=1.0 +/- 10%, guaranteed limits: 0 < Hfe < 2e6

Cheers, James Arthur