> > > > I agree that 'voodoo programming' does not help, and I have no time=20 > > for the folk who when faced with a plain simple programming error=20 > > resort to debug techniques such as "lets try booting from my lucky=20 > > disk", but nevertheless, you have to come up with some=20 > theories before=20 > > you debug, otherwise it is pure guesswork! >=20 > No, it isn't. Not knowing what's wrong does not imply=20 > guesswork. Often once a system is basically working, you can=20 > look at a symptom and be quite sure what's wrong. Those are=20 > usually the "Oh, yeah, I forgot about that" bugs. >=20 When you don't have a depth of understanding, then guesswork is all you have. It has a low payoff, but what else can you do? > However when you first try to get something to work the=20 > "system doesn't respond" symptom isn't very useful in=20 > narrowing down on the problem. Aside from checking a few=20 > obvious things (power on?, MCLR released?, oscillator=20 > running? ect) it is better to keep an open mind and *not*=20 > assume you know why it's doing what it's doing. That allows=20 > you the mindset to methodically check everything instead of=20 > jumping around spot checking one hairbrain guess after another. >=20 I agree with you on this point. I think people often want to blame the hardware (the pic microcode has a bug in it) instead of their own mistakes. > I've also noticed, especially with inexperienced programmers,=20 > that their guesses are usually wrong and far fetched. =20 That's what makes them inexperienced. If you know immediately what is wrong, then you are experienced. > Just=20 > check the archives of this list for lots of incredibly stupid=20 > guesses as to why someone's program doesn't work. It seems=20 > we had several in just the last few days. First some bozo was=20 > trying to tell us the EEPROM read back randomly (turned out=20 > to be bank switching, big surprise), then someone tried to=20 > blame a hardware reset problem on software, and now we've got=20 > some rocket scientist trying to tell us that two INCF FSR=20 > don't produce the expected result. In all these cases it=20 > would have been much more productive NOT to waste time on=20 > wildass guesses and instead spend the effort carefully and=20 > methodically figuring out what IS wrong instead. >=20 You know, if it ticks you off so much responding to these "rocket scientists" and "bozos," then why don't you just ignore them? Personally, I am grateful for any correction to my understanding of how the PIC works. Essentially, "you think it works that way, but it doesn't" People build up mental models continually, and as they become refined they learn and become "experienced," which gives them the right to laugh at other people's struggles. Alex -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.