| ??? 03/20/12 07:56 Read: times |
#186789 - Where you sit determines what you see ... Responding to: ???'s previous message |
Erik Malund said:
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.
probably correct. If the fall time is so short that the period of "who knows what it does" is short enough the likelyhood of 'bugaboos' will be less. Will they be zero, I'm not too sure 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. all arguments for supervisors are based on the selection of a supervisor with the right "activation voltage" if you choose a supervisor with the "activation voltage" of 1V for a 5V system, you will, of course, see no improvement. BTW this is the reason that some circuits can not use the uC's reset output for everything and thus need an external supervisor What? Did anyone mention the uC's RESET output? The supervisor can't do anything but assert its own RESET output. Not every uC has a bidirectional RESET, and those that do only serve to confuse the situation in this context. 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.
Well, if you consider statements in the datasheet 'nothing' In the face of physical evidence, I've concluded that it is, indeed, nothing. They say what active RESET input is supposed to do when Vcc is within specified limits. They say nothing about what happens once Vcc is outside of those limits. 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. Consequently it's just an unproven hypothesis.
the FDA bases approval on "statistical data" you have the same re this. There are countless posts that after the suggestion of using a supervisor (or in the case of SILabs adding a pullup to the internal super) states "this fixed the problem" The FDA uses statistics based on what their people can see through a microscope. I've read lots of posts indicating that the "reset problem" went away, without a single indication of how it was determined that there was a "reset problem" at all. Though I've asked you to show indication of a RESET problem, you've never been able to show any evidence, or, for that matter, that you've even tried to find one. You, and others, simply added a supervisor and declared the problem, whatever it was, solved. Now, I can't say there was no RESET problem, since I didn't observe the situation, I have not seen any indication that the "problem", whatever it was, was solved. You simply didn't see itany longer, and that was "good enough" for you. Without firm and rigorous methodology, you simply can't declare a problem "fixed," particularly when you haven't even tracked the problem down to a RESET=related issue. 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.
except for "antique collectors" like you I doubt many care about "the guys at Intel" re the '51 I mention this detail only because nearly every manufacturer has used the crappy old RESET design from Intel in their own examples of "how to do it." It doesn't make sense, even when they do specify a minimal duration of RESET since the RC values produce a pulse many times longer. 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.
repeat/rewording of a statement above, the same answer applies Erik PS Richard, do you see how easy it is to follow a post when there is references to what it replies to Do you, Erik, see how easy it is to follow a post when there is reference to the original? RE |
