Software bloat (Larkin was right)
in [Design]
|
Prev: OrCad/ question
Next: Capture hierarchy
From: krw on 22 May 2010 18:14 On Sat, 22 May 2010 16:17:54 -0400, "Michael A. Terrell" <mike.terrell(a)earthlink.net> wrote: > >"krw(a)att.bizzzzzzzzzzzz" wrote: >> >> I've never seen a library that keeps them in ISBN order. I doubt even Amazon >> keeps them in ISBN order. > > > That's because libraries sort books by the Dewy Decimal System, which >is much older than ISBN. SO? Renumber them. Why is there an ISBN if Dewey is so great? BTW, many libraries don't use Dewey. I'm quite sure Amazon doesn't either. >How old do you think the ISBN system is? >Which of the two ISBN systems would you use? BTW, I have a LOT of books >without ISBN numbers. What the Maxim databook. ;-)
From: Tim Williams on 22 May 2010 18:27 "D Yuniskis" <not.going.to.be(a)seen.com> wrote in message news:ht81uf$koo$1(a)speranza.aioe.org... >> -=-=-=- >> >> Makes sense, right? > > Yup. Though I don't see how *time* gets factored in > (no doubt the "samples" are taken periodically so there > is something, someplace, that allows you to map > "number of consecutive samples" to some "period of time". Yup, it runs once every 16ms, called by the 1kHz global timer (which is also the PWM generator for analog outputs). Lots of stuff > Everything is an event. So, you can just as easily pass a > "KEYBOARD STUCK" event down the same channel as the keys > themselves (simplifies handling at the application layer). Events aren't something I've done much with. It's quite handy, but very heavy handed. You can easily define KEY_DOWN, KEY_HOLD, KEY_UP, etc. events for each key, but where do they go? You start getting something like Windows (or more specifically, maybe a DirectX API) where you can register functions with events. So you need to store more pointers, and assign all of them when moving to different sections, where the actions are different, and so on. When you need reconfigurable control that general, it can't be beat. > I like using FSM's in my code. User interfaces are nothing > but *big* FSMs (often containing nested FSM's). It seems to > make things easier to understand and modify. Well, if you want to get technical, the whole processor is one FSM, or can be reduced to one (in the same way a complex control loop can be simplified to a single transfer function). So regardless of how it's written, I'm doing that implicitly. But the point is if it reads that way, which it doesn't necessarily. :) The downside to programming state machines is, you need a state variable. If-then-loop constructs use other variables, program counter and so on as implict state variables, which saves on memory. There are cases where you don't have a better way to do it, so you use a state variable, or you already have something that looks like a state variable, so you use that. Tim -- Deep Friar: a very philosophical monk. Website: http://webpages.charter.net/dawill/tmoranwms
From: Michael A. Terrell on 22 May 2010 22:44 "krw(a)att.bizzzzzzzzzzzz" wrote: > > On Sat, 22 May 2010 16:17:54 -0400, "Michael A. Terrell" > <mike.terrell(a)earthlink.net> wrote: > > > > >"krw(a)att.bizzzzzzzzzzzz" wrote: > >> > >> I've never seen a library that keeps them in ISBN order. I doubt even Amazon > >> keeps them in ISBN order. > > > > > > That's because libraries sort books by the Dewy Decimal System, which > >is much older than ISBN. > > SO? Renumber them. Why is there an ISBN if Dewey is so great? BTW, many > libraries don't use Dewey. I'm quite sure Amazon doesn't either. Dewy was US based, for filing in a library. ISBN is international, and identifies the publisher. Reprints of the same book have different ISBN numbers. A library would be pretty useless with the books sorted by publisher and date order. 'Amazon' isn't a library. > >How old do you think the ISBN system is? > >Which of the two ISBN systems would you use? BTW, I have a LOT of books > >without ISBN numbers. > > What the Maxim databook. ;-) I don't recall ever seeing an ISBN number on any databook, since they aren't sold through regular book distribution channels. I'm talking about my collection of SF, history and military books printed before the mid '70s. -- Anyone wanting to run for any political office in the US should have to have a DD214, and a honorable discharge.
From: D Yuniskis on 23 May 2010 00:33 Hi Tim, Tim Williams wrote: > "D Yuniskis" <not.going.to.be(a)seen.com> wrote in message > news:ht81uf$koo$1(a)speranza.aioe.org... >>> -=-=-=- >>> >>> Makes sense, right? >> Yup. Though I don't see how *time* gets factored in >> (no doubt the "samples" are taken periodically so there >> is something, someplace, that allows you to map >> "number of consecutive samples" to some "period of time". > > Yup, it runs once every 16ms, called by the 1kHz global timer (which is also > the PWM generator for analog outputs). Lots of stuff Yes, every "time" has some underlying granularity. I.e., my "50 MSEC" references for DEBOUNCE_TIMER is only guaranteed to be at least 50ms -- if the jiffy runs at 3ms, then you can end up with 51ms (17*3), etc. I like coding the actual times in the code (since they pertain to the actual technology used in the switches) as the jiffy can change without having to rewrite the code, etc. >> Everything is an event. So, you can just as easily pass a >> "KEYBOARD STUCK" event down the same channel as the keys >> themselves (simplifies handling at the application layer). > > Events aren't something I've done much with. It's quite handy, but very > heavy handed. You can easily define KEY_DOWN, KEY_HOLD, KEY_UP, etc. events > for each key, but where do they go? You start getting something like You only define events for things that are significant to your application. And, you can route events to different *parts* of your application (so you don't have to have "everything" routed to one giant process. > Windows (or more specifically, maybe a DirectX API) where you can register > functions with events. So you need to store more pointers, and assign all > of them when moving to different sections, where the actions are different, > and so on. When you need reconfigurable control that general, it can't be > beat. > >> I like using FSM's in my code. User interfaces are nothing >> but *big* FSMs (often containing nested FSM's). It seems to >> make things easier to understand and modify. > > Well, if you want to get technical, the whole processor is one FSM, or can > be reduced to one (in the same way a complex control loop can be simplified Of course! > to a single transfer function). So regardless of how it's written, I'm > doing that implicitly. But the point is if it reads that way, which it > doesn't necessarily. :) The downside to programming state machines is, you > need a state variable. If-then-loop constructs use other variables, program > counter and so on as implict state variables, which saves on memory. Each state machine needs a "current state". It is also helpful to keep a "stack" of previous states. And, of course, a list of event sources. Here, for example, is a *part* of a FSM that collects a decimal integer from the user: STATE IDLE Case '0' thru '9' Goto GATHER Executing Firstdigit Case CLEAR Goto IDLE Executing Reinitialize Case ENTER Goto PREVIOUS Executing Accept ORELSE Absorb STATE GATHER Case '0' thru '9' Goto SAME Executing Accumulate Case CLEAR Goto IDLE Executing Reinitialize Case ENTER Goto PREVIOUS Executing Accept ORELSE Absorb Firstdigit: accumulator <- (key - '0') goto Feedback Reinitialize: accumulator <- default_value Feedback: discard event display accumulator produce key click discard last state RETURN Accept: blank display make accumulator available to application Absorb: discard last state RETURN This is more involved than need be as it allows a "default value" to be passed to the FSM as the "value" which is displayed in IDLE and accepted, "as the default", if the user ENTERs while in IDLE. Otherwise, once the user has begun typing, the default is discarded and the digits accumulated. I.e., once in GATHER, we are accepting input from the user. While we are in (or *return* to) IDLE, we are using the "default value". N.B. discard last state explicitly gets rid of the "pushed" state name which preceded this "state transition". I.e., we don't care about the storing the history of state transitions *within* this little FSM since they contain nothing of interest. OTOH, the state transition that intially brought us *into* IDLE (i.e., the equivalent of a "Call GetValue") still lingers in the state history stack so we can "return" to that "calling state" once the value has been ENTERed. Note, also, that the event that completed the FSM ("ENTER") is propagated back to that "calling state" so it can treat it as "value now available" (in accumulator). In each other case, the event that initiated the state transition is explicitly "discarded"/absorbed. I have several different implementations of this which vary depending on whether I want to pass the event "code" on to the "transition routine" (e.g., Accept, Reinitialize, etc.) or not; whether the previous state is "pushed" automatically or not; etc. Also, the encodings of each line of the table(s) varies depending on the implementation and how I trade space for time (this "four argument" format can encode in as few as 4 bytes). A user interface is just pages of tables expressed like this. So, you know exactly what causes the machine to move from one state to another (testing is *really* easy!) And, the FSM concept is an ideal way to implement other protocols (e.g., communication). It makes it really obvious what are "valid" and "invalid". > There are cases where you don't have a better way to do it, so you use a > state variable, or you already have something that looks like a state > variable, so you use that.
From: D Yuniskis on 23 May 2010 01:54
Hi John, John Larkin wrote: >>>> There's nothing that says part numbers have to be positioned >>>> on shelves in sequential order. You track the *location* >>>> of a part as part of your inventory control system. So >>>> that you are free to put things wherever is most convenient. >>> Cool. Every part gets a location number that determines their location >>> and order on the shelves. So why isn't that the part number? >> Why *should* it be? Do you seat your children around the >> table by age? alphabetically? > > If I had 4900 children, I probably would. And your cars are parked in the driveway sorted by date purchased? Or, alphabetical by make/model? Or, VIN number? >>>> Let the machine figure out where something is. Let it >>>> print your pick list in an order that *it* knows is >>>> efficient (because *it* knows the physical layout of >>>> your stockroom and can order the part numbers so you >>>> don't wander around looking for numbers "in numerical order"; >>>> sort of like preparing a grocery list -- you list the eggs >>>> with the butter so you can pick up both of them in "Dairy") >>> So the pick list is in sequential order by location, and the parts are >>> ordered on the shelves by location number. Great idea. >> Do you *really* think DigiKey has all of their parts on >> shelves in numerical order? Well, we all like to marvel at how *wonderful* DigiKey's search capabilities are -- even those exposed to the public. So, DO YOU THINK THEY HAVE THEIR PARTS ON SHELVES IN NUMERICAL ORDER? >>> So what use is the part number now? >> Because you don't put "room 4, shelf unit 13, bin 5" on >> a bill of materials! > > No, I put "231-2170" for a 1N5247B. And I can go to the stockroom and > walk right up to the bin, knowing that number. It's the stock number > *and* the location. Isn't that just too clever? Do your engineers think and talk about "using a 231-2170" in a circuit? Or, do they think and talk about using a "1N5247B"? (if the former, I'm sure that's a great skill that will server them well at *other* companies!) You've done what most small companies do: one guy wants to keep track of things IN HIS HEAD so he creates a numbering system that lets him (try to) do so. As more and more parts fall under that system, exceptions start to creep in ("We'll just store the big stuff over in the next aisle... we'll all *know* that because it's BIG STUFF"). He ignores the '9xxx' syndrome because he's got too much invested in the system already and minimalizes the issues that are consequential to that choice. As new technologies emerge, he *bends* the system to try to accommodate them -- there's always an "out" that can be rationalized into the system. Time is spent coming up with workarounds, standards, etc instead of being spent on things that actually contribute to the *real* business. >> You put *things* in *places*. Parts in locations. >> You associate a part with a location in much the >> same way that you associate a part with a subassembly. >> >> Part numbers are just ways to identify parts. >> >> Location numbers are just ways to identify locations. >> >> If you reorganize your stock room, should all of the part >> numbers change? But, clearly the *locations* of all >> of those parts must change! So, your desire to arrange >> parts contiguously by part number forces your stock room to >> have a particular shape. > > No. It forces groups of parts to be locally ordered. What's wrong with > that? Why *should* the part number be the criteria for defining placement of a part? We've had *affordable* computers for nearly 40 years now. A machine can keep track of *two* numbers just as easily as *one* (since it already has to keep track of *vendor* part numbers as well!). You're dealing with a false economy. I had an employer who wanted everyone to program Z80's using "split octal" (e.g., 0xFFFF is 377377). His rationale was that you could easily decode -- or ENCODE -- the instruction IN YOUR HEAD when you saw the opcode expressed in this form. "Um, don't we have symbolic assemblers and debuggers to do that thinking *for* us?? So we can concentrate on solving engineering problems and let the machines handle the trivial tasks??" >> (Or, do you have a little sign located between part #0999 >> and #1257 saying "1000-1256 located down the hall"?) > > One of our part attributes, in the database, is "location". S means > stockroom. B1 means one area of the basement, where we have stuff like > chassis and power transformers. I think we have 4 or 5 named areas. So, why didn't you put those designators *in* the part number? I.e., you have already acknowledged that there are "exceptions" to your nice "ordered by part number" scheme. Here come the '9xxx's... :> > But everybody pretty much already knows that big transformers are > downstairs; if you don't, look it up. The parts in the stockroom, the > electronic stuff, wraps around the room in part number order. Hardware > is in a carousel sort of thing on the production floor. A lot of > people, production and engineering, designed the system. It works > really well, much better than anything I've ever seen elsewhere... and > I've seen some horrors. When I walk into a library, the *first* thing I do is go to the card catalog. *It* tells me where the item that I am interested in is located. Then, I look at the signs on the stacks to figure out which stack will contain it. The items aren't stored alphabetically. By title or author. They aren't even stored in the Dewey Decimal system anymore! I can roam around the library and try to get a feel for where things are. But, this takes time. (most employers have to pay people for their time :> ) OTOH, if "something" tells me an item is in a particular location, then all I need is a map of where those locations are to find the item. > If I need an SMB connector, I look up any one and then go browse the > shelf where all the other SMBs are located. They are all together, > because SMB connectors have a defined part number prefix. Resistors > and capacitors and inductors are together, ordered by value. That's > nice too. And if *I* need an SMB connector, I issue a query: CONNECTOR and SMB not only will this tell me which connectors have had part numbers assigned to them, but it will also tell me quantities (instead of having to count them "by eye"), whether any are "held" for an upcoming build, when the last buy was, how much they *cost* (since I can't look at two connectors and decide which is most economical based solely on appearance and "feel"), etc. I'll get more information *and* know where they are. >> I'm deploying exactly this sort of system currently. > > Well, good luck, whenever you get it done. The numbering system has been working for almost 25 years. As I said elsewhere, I learned this lesson before I got out of college :> I've since seen many companies go the "let me keep it in my head" approach and struggle when The Guy retired, or couldn't anticipate a new teechnology ("Gee, what order should I put these CPus in? Numerical by vendor's part number? Alphabetical by vendor name? Should I put all the peripherals for a particular processor with that processor? Or, should I impose some sort order on the peripherals -- UARTs together, Timers together, etc.? Oh, my! I never dreamed they'd make ethernet controllers in chips! What category do I put those in? I'm sure the folks who come browsing through the stockroom to see what sorts of chips we have BEFORE they design their processor boards will want all of them in *some* order...") The mistake *I* made when I did this was failing to put *everything* into the system. Treat *everything* as a number (contracts, screws, semiconductors, source code, binaries, clients, informal documents, etc.) instead of just the obvious things (screws, code, etc.). If I wanted to, I can add them now -- since I don't have to go back and "make room" in the numbering system (just grab the next N part numbers! :> ) It's just not worth the effort. Instead, I'll have to keep several different "tracking systems" (contracts, "parts", contacts, etc.) instead of being able to unify *all* of it. I am now porting it to a different hardware and software platform and "adding automation". None of that changes the core logic in the system -- just the way you get data in and out. (e.g,, so a forklift operator can access the data without getting off the truck) >> Everything has an identifier. EVEN PEOPLE! > > Saves having to remember all those pesky unstructured "names" things. > "Good morning 34719622. Can I get you a cup of 7192453?" How do you know *who* pulled the parts for a build? Or, designed a circuit? Or, who the customer is? Or the vendor? Or, do you not really track those sorts of things? >> The RDBMS puts the smarts to the system. Map an identifier >> into an "object type": "What is 12345678?" "12345678 is a person" >> >> Based on that object type, figure out what the actual object's >> characteristics are. "Please describe person 12345678" >> "12345678 has brown eyes, is 6' tall, male, etc." >> >> When I need an identifier "anywhere", I impose criteria >> on what sort of object I expect in that "application". >> So, for a timeclock application, I expect the identifier to >> map to "PERSON" and not "RESISTOR". >> >> Using this sort of approach, I can have many different classes >> of objects and allow the descriptions for those objects to >> be intelligently *parameterized*. >> >> E.g., create a new part: 55667788 >> What is it: (multiple choice) RESISTOR >> OK, since it is a resistor... >> What value: 4K7 >> Tolerance: 5% >> Rating: 1/4W >> etc. >> >> Create a new part: 55667789 >> What is it: SCREW >> OK, since it is a screw... >> Head type: clutch >> Thread pitch: 32 >> Size: 6 >> Length: 1" >> >> Create a new part: 55667790 >> What is it: PCB >> OK, since it is a circuit board... >> Schematic: 12342345 (which must be of type "SCHEMATIC") >> Artwork: 45567788 (which must be of type "ARTWORK") >> BOM: 45324323 (which must be of type "BoM") > > Yikes. Now you need a product structure document (or database) to tell > you which schematic goes with which bare board and which assembled > board. And where they are all kept. And what drawings (of type > "drawing") and parts lists (of type "parts list") apply. > > Been there, done that, never again. How do you deal with a vendor calling to inquire about a system you built for him 5 years earlier which, perhaps, has developed a bug. Or, perhaps the customer wants an *identical* system (because the last one has already been through FDA validation -- "functionally equivalent" is not the same as "identical"). You need to know all of these things in order to be able to reproduce *the* system you sold him. You also need to know exactly which version of every software function/routine you used. Which of each tool used to create it. Which configuration of each OS, etc. What do you do when a customer calls and points out a *bug* in your product? If you can narrow it down to a routine, how do you know which *other* products may be affected? How do you know which other builds contained *that* "software component" (not just one that had that "function name")? Or, do you just wait for other customers of other products to call with problems later? I design boards that typically serve multiple purposes. Lots of stuffing options. Sometimes those options are exposed to customers (if they are going to support the product "in the field"). Sometimes, they are just unnecessary details ("No, you don't need to know that cutting this foil switch will allow you to use a larger memory device in place of two smaller ones"). The same sort of "I-want-to-keep-it-all-in-my-head" mindset leads to equally silly numbering systems: SCH-12345 BOM-12345 PCB-12345 Wow! Isn't this great?! I can come up with a part number for the schematic for this board without having to turn on the computer! Gee, welcome to the 21st century!! You then have to deal with "variants" -- fabricate NEW part numbers (schematic, PCB, etc.) for each of these variants. "Gee, lets' put a dash after the part number!" (Of course, this doesn't help you figure out the significance of each particular "dash number" -- "Oh, we can always look that up -- on the computer!") Instead, I create *really* new part numbers whenever I need one. They are inexpensive. I can apply a single "board" with different silkscreens to different finished assemblies -- and give each a separate schematic *or* have them share a common schematic. The part number for the BOM need not be related to the SCH *or* the PCB *or* the final assembly. When you purchase a "final assembly", you are purchasing a tangible piece of hardware. The schematic, artwork, BOM, etc. are all *different* entities. One doesn't imply the other. (i.e. a schematic, BOM, piece of FR4, etc. can exist in the absence of any of the others!) If I have to "sell" a documentation package, then I create a P/N for that package -- which could just be a bunch of paper (or files). It doesn't have to include the actual physical "device". > I bet that if you have a shell-and-pin connector, the shells are kept > far away from the pins because "shell" and "pin" are different types. The shell is kept wherever the hell you want REGARDLESS OF IT'S PART NUMBER! *Your* scheme FORCES the shell and the pin to have adjacent part numbers because you *want* them to be adjacent and can only do so *if* they have consecutive (or nearly so) part numbers. *I* can put them in any order I want -- pins *before* or after the shells AS I SEE FIT (regardless of their part numbers) -- because I dissociate the part number from its location. |