I don't know what you mean. I've experimented with supervisors of various sorts. I've also experimented with various sorts of regulators and power sources.

I've found that, in my own experience, those brownout bugaboos relating to program-store-content-loss that trouble the 805x community at large, don't make themselves apparent when the Vcc supply rise and fall times are very short. I don't deny that there are other brownout-related problems, but just hitting the RESET doesn't always solve those problems. Since there are different levels at which various devices perceive "out-of-spec" Vcc, the behaviors of MCU's, supervisors, BBRAM's, and other devices can be very hard to predict as Vcc wanders around the 4.5-volt level. Some devices will respond as though it's a brownout, while others will not. They don't all have the same hysteresis, either. I know the Dallas BBRAM's that I was using when I first encountered some of these anomalies don't behave in the same way as the Dallas MCU's built-in brownout detector does.

Additionally, I've observed that supervisors do absolutely nothing useful during the power-down transient, aside from activating the RESET. My argument is, once again, that nothing guarantees what happens when RESET is active but Vcc is below the acceptable level. Additionally, as I've pointed out, not all devices have a RESET input.

Many people think that a large capacitor will compensate for an under-specified raw input to the on-board regulator. Some think that additional capacitance on the output of their on-board regulator will solve the too-weak-input problem. I am not among them. Designing with a 20% margin of safety ijnto the raw input supply might be cheaper in the long run than adding extra Vcc-to-Gnd capacitance, and it causes no increase in Vcc rise and fall times.

While I'm forced by circumstance to respect the general opinion that a supervisor will, in general, make these problems "go away," I know that nobody has made the assertion that they've spent any time testing that notion. Consequntly it's just an unproven hypothesis.

I'm still convinced that the guys at Intel couldn't get their oscillator to start reliably, so they used a RESET time-constant long enough to convince their boss that it would start most of the time, rather than figuring out how to do it properly. The FLASH-corruption issue didn't come about until FLASH-based program store became a reality. This makes the supervisor look more like a fig-leaf rather than a solution. Maybe someone with a real motivation will actually spend the time and resources to perform rigorous testing on the function of the supervisor in this environment rather than allowing it to continue to float in the fog.

RE