At 07:38 AM 11/18/2007, you wrote: >On 11/16/07, Jinx wrote: > > > I thought also of using a baby PIC, but somehow the fact that it's > > > a clocked micro running program code seems somehow less > > > bulletproof than a purely logic based solution. Not sure if this > > > concern is truly valid though > > > > No reason a micro shouldn't be as reliable a solution as a dedicated > > IC. There are pros and cons for either option (cost, simplicity, s/w, > > availability etc) > > There is one big reason why it should not be used. As long it needs >programming and is acting like a two penny 74SN7121 or 74SN7123 why >the hell to use a microcontroller or other $20 part ? There are sooo >many dedicated Ics (I think I can number around 20 without searching >at Digikey) that a programmed microcontroller (anyone would be that) >should be the last and the most complicated option. It is very hard to guarantee the behavior of a complex device like a microcontroller if you have to allow for "soft" errors, because there are so many possible internal states. It's generally errant behavior of a device like a micro that you're trying to guard against with a WDT. When there are only two stable states it's pretty easy to analyze the behavior. When there are 2^128 or more it becomes more difficult. Even if you take preventive action such as only using a micro with hardware address and bad instruction protection, and one that can do its own checksums and tests and use completely bulletproof and precise supervisory and power subsystems, I think doubt will still remain. Most low cost micros (including PICs) lack the on-chip hardware to be really robust, although with clock monitors, the ability to read checksums, bullet-proof supervisory circuitry (not there yet) bad instruction and RAM protection (not on PICs), and better hardware WDTimers (such as the 'windowed' variety, and those that require 'arming' before they will accept a reset command we might get a lot closer, at a reasonable price, some day. Depends on the engineering and the consequences of a failure. People have died, and more will die, because of such problems. Fortunately, usually it's just the user getting p*ssed off because they have to cycle the power to get things to work properly again. In many medical, aerospace and 24/7 industrial control applications that may be considered unacceptable for some reason. Best regards, Spehro Pefhany --"it's the network..." "The Journey is the reward" speff@interlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist