Monolithic assembly; no libs, no includes, no linker (except for the thing that pokes in Xilinx configs)
Manual source control
Minimal abstraction, a few macros at most
Extensive program documentation *in* the source file
Mimimal, archived tool set; in my case, Crimson Editor, C32 assembler, and a few homebrew utilities.
Lots of correct and relevant comments, based on the premise that no code is self-documenting.
Programs managed and released just like any other engineering document, by rev letter; firmware installed by manufacturing just like hardware.
The process is fast to develop, fast to execute (as in microseconds), easy to do and maintain, and produces bug-free, profitable products. What's wrong with that?
Ick! Too much chance for screw-up. A simplified OO approach is far safer.
Agreed. State machines are simple. A common structure helps even more.
Explain?
Ick! Reuse is important to me. Once I have a module correct I can concentrate on other things.
Ick! (see above) How do you do FPGAs? Single file? I try to limit VHDL to 1000 lines. If a module is over that it's not designed well enough. Assembly I limit to about two pages, a quarter of which tends to be header/descriptive comments.
I like MAKEs, though I've been converted to CVS, and the like. I'll likely fight it for my next project though.
Again, macros, functions, procedures, etc. are not only good for reuse, they're important for organization and readability.
Agreed! It's hard enough to keep documentation and code in step when they're in the same file. External documentation should be in the form of a high level functional spec rather than implementation. Where this breaks down is in very large designs, though the concept still holds, just pushed further down the food chain.
This si fine for very simple tools. It gets much harder with FPGAs and impossible with ASICs. The larger the project the harder this is to do. How do you handle schematics (one reason I favor VHDL over schematics, BTW)?
Agreed! Mostly so I remember what I did the next week. ;-) I also do the high level comments and flow (written in the header) before the code so I can organize the work to be done in that module.
Not sure I follow exactly what you're saying here. In general, manufacturing puts the boot loaders on the boards when they're made. The functional code is flashed at final assembly (during ICT, ideally).
Nothing is wrong with the end. I don't agree with all of your means to that end. Your process certainly WOULD NOT work in a large project. Though I've had my fill of large projects. As an engineer, they suck.
What's unreliable about either of my circuits? Neither does precise timing, but this isn't an eximer laser or a picosecond-resolution ICCD camera; it's a sump pump or something. The OP can always tweak the RC until he's satisfied with the timing, or use a pot for the timing resistor. The thing about a simple circuit is that he can grab a few discrete parts from RatShack and connect them up quickly and easily.
Discretes are rugged and easy to use. The more complex a circuit, the more bugs it could have, evidenced by the multiple times you corrected your complex 555 thing.
Besides, circuit minimization is a fun game. Try it sometime.
Safer? Once my stuff works, I can count on it not breaking. And I haven't had a stack overflow in years.
Absolute assembly, ram variables all declared and nailed at assembly time. Their memory address is right there in the listing.
My editor has advanced "copy" and "paste" features. I reuse code all the time.
FPGA configs are generated on the side, by my FPGA guy, usually a top-level schematic and VHDL boxes. The Xilinx project is released as a separate part number+rev from the uP firmware. I wrote a little linker-like command-line program that builds a runtime image (rom/flash file) from the assembler's absolute S28 output and one or more Xilinx .RBT files. One batch file, GO.BAT, reassembles the source and builds the final image. Typically takes a second or so to run.
Manufacturing does it all, from formally released files and procedures. That may be an eprom or may be a flash procedure or may be files installed on a drive. But it's never hacked or short-cut by engineering, and the configuration of shipped products is absolutely known. Bastard versions, like a wrong mix of code and FPGA configs, don't happen.
But the end is all that matters. Too many programmers, maybe most of them, care about the means more than they care about the end. They mainly want to play programming games.
Yup. Part of the scheme for delivering reliable code is to restrict the problem set. We do hard-embedded instrumentation, VME modules, small embedded boxes, waveform generator type stuff. My methods wouldn't scale to word processors or web browsers. But the OO methods that make sense for them don't really make sense for a 6000 line bare-metal ROM-based instrument controller program.
I got rid of my new Keithley DVMs, and wish I could return our new Aeroflex spectrum anayzer, because they are both full of buggy, nightmare code that the vendors are powerless to fix.
Two, usually. We do better work by interacting and checking one anothers' work.
We are, after all, electronics design engineers, and we sell functional hardware, not software. The uP and its code are *not* the center of the show, they're just another support component that we want to work reliably, like a power supply.
Typically the maximum source or sink is 100mA. The TLC555 data sheet says 150mA absolute max, but why push your luck? Tack on a pnp transistor to the output to handle the current:
| Vcc ----+-----------+ | | | | R | | R 10K | | R | | | e | out ----+--RRR---b PNP | 10K e | | | | | +----+----+ | | | RLY | - C| | ^ C| | | C| | | | | +----+----+ | | | === | GND
The bipolar ones are supposedly good to (sink) 200mA, but the CMOS one I show above is only good for 100mA (sink). In both cases, you probably shouldn't go much over half of those numbers.
But you could just replace the 1N4005 with a 2N4403 emitter follower and make the TLC CMOS one work without adding to the parts count.
Thanks guys :-) I think :-) You've give me lots of circuits to try. I actually ordered a few of the parts from newark as well. Realized I needed some quad opamps to fix a dbx-223 and a couple other parts I had been holding off on so it was worth the postage. Plus I always order 10 or so of the cheap bits to keep expanding my parts bin.
You close on the purpose. It's a water pump on an engine. I want it to run on for a couple minutes after shutdown. So accuracy is not an issue.
Did you design your own instruction set? What was it like?
I designed an 8-bit CPU once, for a marine data logger. It had two instructions, MOVE and JUMP. It took about 40 TTL chips on two boards, and had a 20 KHz, 4-phase clock. Worked fine.
A few years ago, I was skiing backwards, fast, and hit a mound of snow. My skis dug in and I got slammed on my butt, hard. The bruise came out the other side, shock wave or something.
Last couple of crashes were into pretty deep powder, and the problem is to dig out. It's like being buried in feathers.
Does a relay armature ever leave slowly? The return spring accelerates the mass of the moving contact assembly when the armature-to-solenoid contact opens up, going from from metal-metal contact to an air gap. At that instant, the magnetic reluctance increases and the holding force drops, positive feedback. Would it acelerate much different if the current drops off quickly or slowly?
In article , snipped-for-privacy@highNOTlandTHIStechnologyPART.com says...>
I designed my own once out of a FPLA and some registers. It had conditional jumps, moves, and controls (S&H timings, gain select, channel select, etc.) for a digital voltmeter I was designing. I wanted to use a real microprocessors but they were bad words (lose your job bad).
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.