Debouncing....at About 1Mhz - Uobtanium Obtained ;-)
in [Design]
|
Prev: TL499A boost converter question
Next: PIC sanity test
From: Jim Thompson on 12 Nov 2007 09:26 On Sun, 11 Nov 2007 17:07:01 -0800, D from BC <myrealaddress(a)comic.com> wrote: >On Sun, 11 Nov 2007 15:54:49 -0800, JosephKK ><joseph_barrett(a)sbcglobal.net> wrote: > >>D from BC myrealaddress(a)comic.com posted to sci.electronics.design: >> >>> On Sun, 11 Nov 2007 08:29:44 -0700, Jim Thompson >>> <To-Email-Use-The-Envelope-Icon(a)My-Web-Site.com> wrote: >>> >>>>On Sat, 10 Nov 2007 19:55:00 -0600, John Fields >>>><jfields(a)austininstruments.com> wrote: >>>> >>>>>On Sat, 10 Nov 2007 14:40:51 -0700, Jim Thompson >>>>><To-Email-Use-The-Envelope-Icon(a)My-Web-Site.com> wrote: >>>>> >>>>>>On Sat, 10 Nov 2007 11:42:31 -0800, John Larkin >>>>>><jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: >>>>>> >>>>>>>On Sat, 10 Nov 2007 11:57:19 -0700, Jim Thompson >>>>>>><To-Email-Use-The-Envelope-Icon(a)My-Web-Site.com> wrote: >>>>>>> >>>>>>[snip] >>>>>>>> >>>>>>>>Now please present us with your "solution" with component names >>>>>>>>and values and I'll simulate it side-by-side with my design. >>>>>>> >>>>>>> >>>>>>>I rarely simulate. Design is the reverse of simulation. Design >>>>>>>forces the desired results, so why simulate? >>>>>>> >>>>>>[snip] >>>>>> >>>>>>So you've been converted to the Bob Pease school of hand waving >>>>>>?:-) >>>>>> >>>>>>My POV: Design puts the idea onto paper. Simulation proves that >>>>>>what >>>>>>is on the paper really works. But simulators don't "design". In >>>>>>my business, simulation "proof" is required for each and every >>>>>>process corner, otherwise the customer doesn't "buy". >>>>> >>>>>--- >>>>>I used to be in Larkin's corner, defending "build and test" over >>>>>"simulate", but after writing a few simulators to solve specific >>>>>problems posed here on sed, which couldn't be solved, practically, >>>>>any other way, I decided to lay down my wire-wrap gun until the >>>>>machine worked in the computer. >>>>> >>>>>Then, along came wonderful, free LTSPICE. >>>>> >>>>>I've designed stuff using it which I never had to physically build, >>>>>but which worked and which I got paid for, which is a joy. >>>>> >>>>>A feeling I'm sure you enjoyed before I did. :-) >>>> >>>>It took me MANY years to trust simulators. Initially even bipolar >>>>device models were bad. >>>> >>>>But I still "design" by first "sketching", even if the "sketching" >>>>does use a schematic capture program... I'm faster that way, no >>>>erasing... drag stuff around... such fun! >>>> >>>>Then I simulate. >>>> >>>> ...Jim Thompson >>> >>> I still sketch for the tough problems. >>> That gives me the freedom to express the problem in any fashion. >>> If drawing cartoons of a little choo choo train stuck in a valley >>> helps to solve the circuit ... great! :) >>> >>> Also, I think I can move my pen faster than a mouse. >>> D from BC >> >>Yeah, but my pen (when using the tablet) can move a symbol or even a >>group of symbols. > >I've been so tempted to get a tablet.. I just don't like the prices I >see at the computer shops.. >(Doh... I'm forgetting Eprey (Ebay) again.. :P ) > >Is it the trendy thing to have for electronics design nowadays? >D from BC I designed the pen-to-tablet electronics for the Kurta (now Mutoh) tablet. Though I was always impressed with the speed and accuracy we attained I never really cared for tablets. Though I almost succumbed to using a track ball many years ago. ...Jim Thompson -- | James E.Thompson, P.E. | mens | | Analog Innovations, Inc. | et | | Analog/Mixed-Signal ASIC's and Discrete Systems | manus | | Phoenix, Arizona Voice:(480)460-2350 | | | E-mail Address at Website Fax:(480)460-2142 | Brass Rat | | http://www.analog-innovations.com | 1962 | America: Land of the Free, Because of the Brave
From: John Larkin on 12 Nov 2007 15:32 On Sun, 11 Nov 2007 15:43:56 -0800, ChairmanOfTheBored <RUBored(a)crackasmile.org> wrote: >On Sun, 11 Nov 2007 07:50:44 -0800, John Larkin ><jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: > >>On Sun, 11 Nov 2007 08:25:59 -0700, Jim Thompson >><To-Email-Use-The-Envelope-Icon(a)My-Web-Site.com> wrote: >> >>>On Sat, 10 Nov 2007 17:44:09 -0800, John Larkin >>><jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: >>> >>>>On Sat, 10 Nov 2007 18:03:07 -0700, Jim Thompson >>>><To-Email-Use-The-Envelope-Icon(a)My-Web-Site.com> wrote: >>>> >>>>>On Sat, 10 Nov 2007 16:19:54 -0800, John Larkin >>>>><jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: >>>>> >>>[snip] >>>>>>>> >>>>>>>>Your Sysreset sets Q high, but your sim starts with Q low. Why? >>>>>>>> >>>>>>>>John >>>>>>>> >>>>>>> >>>>>>>The default set-ups included FF initial conditions Q=0. If I uncheck >>>>>>>that box it starts, as would be expected, with Q=1. >>>>>>> >>>>>>> ...Jim Thompson >>>>>> >>>>>>Well, run that. It's more interesting. >>>>>> >>>>>>John >>>>> >>>>>Yep. It takes one cycle for the output to be correct. >>>>> >>>>> ...Jim Thompson >>>> >>>> >>>>It seems to work, but it's awfully convoluted. It would be, for me, >>>>like one of those things that I designed but that I can barely >>>>understand myself; there are too many possible states, and the dflop >>>>clock sometimes comes from the input, and sometimes comes from the >>>>input xored with the internal delay. >>> >>>Think of the XOR as a device that is switched from being an inverter >>>to being a buffer. The switching does not occur while clock (input) >>>edges are present. >>> >>>>And the input can chatter, or it >>> >>>Does nothing after the first transition... it's an edge-triggered >>>flop. >>> >>>>could be a single edge of either polarity. All those conditions have >>>>to be proven to work, and proving it is too much work. >>>> >>>>I avoid clever stuff like that, in hardware and in software. Sorry, >>>>but I prefer my first circuit, because it's a lot easier to >>>>understand. >>>> >>>>John >>> >>>When I feel confused I drinks a glass of wine ;-) >>> >>> ...Jim Thompson >> >> >>One of the great engineering virtues is laziness. I consider a circuit >>or a piece of code or a mechanism and say "that's going to be way too >>much work" so I put it off for a while, or talk to somebody about it. >>Usually something simpler emerges. Too many people, cursed with excess >>energy, just plow ahead and implement the first idea they have. And >>when it turns out to have bugs, as complex things will, they add stuff >>to repair the bugs. >> >>John > > > Must be what happened to you. Gosh, where did you acquire such wit? John
From: John Larkin on 12 Nov 2007 15:39 On Sat, 10 Nov 2007 19:55:00 -0600, John Fields <jfields(a)austininstruments.com> wrote: >On Sat, 10 Nov 2007 14:40:51 -0700, Jim Thompson ><To-Email-Use-The-Envelope-Icon(a)My-Web-Site.com> wrote: > >>On Sat, 10 Nov 2007 11:42:31 -0800, John Larkin >><jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: >> >>>On Sat, 10 Nov 2007 11:57:19 -0700, Jim Thompson >>><To-Email-Use-The-Envelope-Icon(a)My-Web-Site.com> wrote: >>> >>[snip] >>>> >>>>Now please present us with your "solution" with component names and >>>>values and I'll simulate it side-by-side with my design. >>> >>> >>>I rarely simulate. Design is the reverse of simulation. Design forces >>>the desired results, so why simulate? >>> >>[snip] >> >>So you've been converted to the Bob Pease school of hand waving ?:-) >> >>My POV: Design puts the idea onto paper. Simulation proves that what >>is on the paper really works. But simulators don't "design". In my >>business, simulation "proof" is required for each and every process >>corner, otherwise the customer doesn't "buy". > >--- >I used to be in Larkin's corner, defending "build and test" over >"simulate", but after writing a few simulators to solve specific >problems posed here on sed, which couldn't be solved, practically, >any other way, I decided to lay down my wire-wrap gun until the >machine worked in the computer. Perhaps I didn't make our procedures clear. We design, think, build, test. "Build" means a full multilayer production item, not a breadboard. "Test" means verify that everything works properly. John
From: Charlie Edmondson on 12 Nov 2007 16:40 John Larkin wrote: > On Sun, 11 Nov 2007 09:05:43 -0700, Jim Thompson > <To-Email-Use-The-Envelope-Icon(a)My-Web-Site.com> wrote: > > >>On Sun, 11 Nov 2007 07:50:44 -0800, John Larkin >><jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: >> >> >>>On Sun, 11 Nov 2007 08:25:59 -0700, Jim Thompson >>><To-Email-Use-The-Envelope-Icon(a)My-Web-Site.com> wrote: >>> >> >>[snip] >> >>>>When I feel confused I drinks a glass of wine ;-) >>>> >>>> ...Jim Thompson >>> >>> >>>One of the great engineering virtues is laziness. I consider a circuit >>>or a piece of code or a mechanism and say "that's going to be way too >>>much work" so I put it off for a while, or talk to somebody about it. >>>Usually something simpler emerges. Too many people, cursed with excess >>>energy, just plow ahead and implement the first idea they have. And >>>when it turns out to have bugs, as complex things will, they add stuff >>>to repair the bugs. >>> >>>John >> >>I've been known to toss designs that I had been working for >>weeks/months, because of too many "patches". >> >>Panics the hell out of clients until they see the results of a clean >>start. >> >> ...Jim Thompson > > > > It takes guts to dump something you've put three months into. Even if > the new thing would be better and finished sooner. It's even more > difficult in a team design, where peer pressure exists. But yeah, I'll > consider dumping a design that's far along, even finished, when a > better or simpler idea pops up, or when the original starts creaking > of its own weight. > > That's why it's better to not start too soon, to play with ideas for a > while at the start. > > John > On a similiar subject... A team I was working with was developing a vehicle classifier using an overhead laser rangefinder and some other sensors. Their problem was that the laser system was not very accurate or precise, it gave the range to a vehicle with an 'error' of several inches. The laser system had actually been developed just to detect presense, not range, and range was just an unsupported feature. So, the team went to work. Unfortunately, they were of the 'hacker' level of software developers - lets write code, and figure out how to do things later! So, after about four months, they had working code, but it was of the consistency of spaghetti, having had four different hackers working on it simultaneously. So, the project team went to management and said "We now know how to do it, and make good determinations. Let us have another month, and we can start from scratch and build it right, from the ground up, and you will have a system that will be much more stable and dependable. Management told them to get off their duffs and start on the next project, the system worked and that was all they needed, and that they were behind schedule anyway. Then they fired the head of R&D! I transfered out to the field... Charlie
From: John Larkin on 12 Nov 2007 22:02
On Mon, 12 Nov 2007 13:40:30 -0800, Charlie Edmondson <edmondson(a)ieee.org> wrote: >John Larkin wrote: >> On Sun, 11 Nov 2007 09:05:43 -0700, Jim Thompson >> <To-Email-Use-The-Envelope-Icon(a)My-Web-Site.com> wrote: >> >> >>>On Sun, 11 Nov 2007 07:50:44 -0800, John Larkin >>><jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: >>> >>> >>>>On Sun, 11 Nov 2007 08:25:59 -0700, Jim Thompson >>>><To-Email-Use-The-Envelope-Icon(a)My-Web-Site.com> wrote: >>>> >>> >>>[snip] >>> >>>>>When I feel confused I drinks a glass of wine ;-) >>>>> >>>>> ...Jim Thompson >>>> >>>> >>>>One of the great engineering virtues is laziness. I consider a circuit >>>>or a piece of code or a mechanism and say "that's going to be way too >>>>much work" so I put it off for a while, or talk to somebody about it. >>>>Usually something simpler emerges. Too many people, cursed with excess >>>>energy, just plow ahead and implement the first idea they have. And >>>>when it turns out to have bugs, as complex things will, they add stuff >>>>to repair the bugs. >>>> >>>>John >>> >>>I've been known to toss designs that I had been working for >>>weeks/months, because of too many "patches". >>> >>>Panics the hell out of clients until they see the results of a clean >>>start. >>> >>> ...Jim Thompson >> >> >> >> It takes guts to dump something you've put three months into. Even if >> the new thing would be better and finished sooner. It's even more >> difficult in a team design, where peer pressure exists. But yeah, I'll >> consider dumping a design that's far along, even finished, when a >> better or simpler idea pops up, or when the original starts creaking >> of its own weight. >> >> That's why it's better to not start too soon, to play with ideas for a >> while at the start. >> >> John >> >On a similiar subject... > >A team I was working with was developing a vehicle classifier using an >overhead laser rangefinder and some other sensors. Their problem was >that the laser system was not very accurate or precise, it gave the >range to a vehicle with an 'error' of several inches. The laser system >had actually been developed just to detect presense, not range, and >range was just an unsupported feature. > >So, the team went to work. Unfortunately, they were of the 'hacker' >level of software developers - lets write code, and figure out how to do >things later! So, after about four months, they had working code, but >it was of the consistency of spaghetti, having had four different >hackers working on it simultaneously. > >So, the project team went to management and said "We now know how to do >it, and make good determinations. Let us have another month, and we can >start from scratch and build it right, from the ground up, and you will >have a system that will be much more stable and dependable. > >Management told them to get off their duffs and start on the next >project, the system worked and that was all they needed, and that they >were behind schedule anyway. > >Then they fired the head of R&D! > >I transfered out to the field... > >Charlie Engineers should just say "no, it's not good enough, it's not ready, and we won't release it until it is." Really. John |