There are many justified situations I can think of at this point, all related to development. For real world situations, I can't think of much reasons where a physical power cycle wouldn't be sufficient. Here is one. You store some values in the EEPROM, like a name, and some configuration etc. When the PIC comes online, and notices it's on the network, it will identify itself with a server machine, and depending on some configuration send certain data, and expect certain values. When developing the OTHER component, you sometimes need to reboot the PIC so it can go through this process again, as you test the different aspects in both, and ensure they work well together. Sure there are many ways to do this that doesn't require a reboot, like writing a routine that does only this, and execute it continuously as you test the other component, or turn the PIC on/off, etc. But having the PIC physically reboot allows you to introduce minimal extra functionality to emulate this. Introducing extra functionality also creates possible points of failure which aren't necessary. And a physical power cycle takes time, as we use Digi ConnectMEs for ethernet linking, and they take about 40seconds to boot up. And doing this in the actual same code and order it would happen as in the field, also allows you to develop against the actual code you would be running in production. Another example: We found a bug activated during the communication with the PC, via the Digi. Whenever this bug occurs, you had to reset the device to restore it to normality, and then continue debugging. In between these it's another 40 second waits. So when this happened the reset was very useful. We could just keep sending the reset command, and then monitor the communication and read the code until we could see exactly what was triggering the bug. We have had many situations where the reset command helped us a lot. All of them related to development, and only useful because our communication with the device all happens through this Digi device which takes long to activate. Had it not been for this long activation time, a reset wouldn't have been any more useful than just power cycling it. Another example: You have some configuration which severely changes the behaviour of the device. When you change this configuration during runtime, to have the PIC modify it's behaviour would require a complete extra piece of code just for this purpose. This introduces cyclomatic complexity and thus makes testing/debugging more comlex and a bigger the likeliness of introducing bugs. If you had to just update the configuration and reboot the device all can take care of itself. A situation where this might apply would be one of our boards. It's the same circuit used in 3 different scenarios. Depending on which scenario you use it in, you would configure it via the network (we have a utility for configuring it). We don't use the reset here, as we configure before shipping, and thus when it's powered in the field it has it's configuration predefined. If it needs to be reconfigured, everyone knows to power off/on. But assume you had some case where you wish to have it update immediately, like a mesh network where devices would rapidly modify behavior to account for some failure or change in environment. In such a scenario having the code branch at boot time would make for much cleaner/organized code, than if you had to mix all of them up together. Though the reboots will probably not happen often, and thus you're not likely to notice the problem I describe. Most of the time you can just get around this with source code design, so a scenario where this is necessary, having severely different behaviour on the same circuit, would be very rare, Quintin Beukes On Sat, Sep 26, 2009 at 10:01 PM, Jan-Erik Soderholm wrote: > But... > > The main question is *why* you want/need the PIC > to reset in the first place. That is very unusual. > > > > > Quintin Beukes wrote: >> But the problem isn't that I'm busy with anything. I didn't have time >> to make the sample program, will do so on Monday. >> >> The problem can be reproduced, however, by finish reading from the >> serial interface, then later one doing an exit(0). After doing that a >> few times all serial comms in the future are messed up. Sometimes >> they'll send the first few bytes double, sometimes the whole buffer >> will be double, sometimes it will write and then restart the write >> halfway through, sometimes it will just ignore data, and so on. And >> this will continue until you do a "cold boot". >> >> Quintin Beukes >> >> >> >> On Sat, Sep 26, 2009 at 5:12 AM, Tamas Rudnai w= rote: >>> On Fri, Sep 25, 2009 at 6:41 PM, Quintin Beukes w= rote: >>> >>>> Like I mentioned this is not used in production. We use it only during >>>> development to reboot the PIC. And Microchip told us to use exit(0) to >>>> reboot the PIC through software. >>>> >>> I understand, that you are making experience etc, that's ok. But exit(0= ) as >>> a reboot on PIC is like getting out of your car in the real life. Try t= o do >>> that while you are making 70 miles an hour! (DON'T) That's exactly what >>> happens on your PIC when you just do an exit(0) without properly stoppi= ng >>> what you are doing -- for example with the UART... >>> >>> Tamas >>> >>> >>> >>>> I'm only asking about this because I'm curious why it happens, since >>>> every time it happens we have to physically power cycle the PIC. And >>>> this is undesirable because some of the other components take long to >>>> boot. >>>> >>>> Quintin Beukes >>>> >>>> On Fri, Sep 25, 2009 at 2:14 PM, Olin Lathrop >>>> wrote: >>>>> Quintin Beukes wrote: >>>>>> I have noticed that when I execute exit(0) too many times, >>>>> What exactly do you think EXIT is going to do for you in a dedicated >>>>> embedded system like a PIC? =A0*Think* about it. >>>>> >>>>> >>>>> ******************************************************************** >>>>> Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products >>>>> (978) 742-9014. =A0Gold level PIC consultants since 2000. >>>>> -- >>>>> http://www.piclist.com PIC/SX FAQ & list archive >>>>> View/change your membership options at >>>>> http://mailman.mit.edu/mailman/listinfo/piclist >>>>> >>>> -- >>>> http://www.piclist.com PIC/SX FAQ & list archive >>>> View/change your membership options at >>>> http://mailman.mit.edu/mailman/listinfo/piclist >>>> >>> >>> >>> -- >>> http://www.mcuhobby.com >>> -- >>> http://www.piclist.com PIC/SX FAQ & list archive >>> View/change your membership options at >>> http://mailman.mit.edu/mailman/listinfo/piclist >>> >> > -- > http://www.piclist.com PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist > -- = http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist