HUD357 wrote:It has been a tradition from the first days of the 'C' language (and now many others) to provide newcomers with some code in that prints "hello world" to some output device on whatever 'platform' you are looking at (Windows, OSX, LINUX, MS-DOS..).
The blinking LED (or equivalent) isn't just for newcomers. I've done over 100 PIC projects professionally, and the first code I put on a PIC is usually my boilerplate setup customized for that app, then all the app does is go into a loop toggling a pin. I usually have the preprocessor compute what the pin toggle frequency should be, then check that with the scope to make sure it's right. LEDs are overrated in that you don't always have one connected to a pin on every project, and humans aren't good at judging frequency. The scope doesn't require anything be connected to the pin, and it measures and displays the frequency directly.
When the pin is toggling at the right frequency, you know that:
1 - Code was successfully built and loaded into the PIC.
2 - Enough of the configuration is right to allow the PIC to run as wired up.
3 - The oscillator is apparently set up as intended.
4 - All the boilerplate code customized for this app ran, set up the pin as a output correctly, and at least didn't do something stupid to keep the app from ever running, the processor resetting, etc.
This method once reminded me of a obscure "feature" of the 16 bit E series PICs that I had forgotten about. The bit toggle loop ran too slowly. I knew about jumps taking longer relative to the other 16 bit PICs, but had missed that writes to certain SFRs take two cycles, not a single cycle as on other PICs. The LAT register being toggled was such a register, so the BTG instruction took two cycles instead of the expected one.
It's a lot easier to find and track down such issues with stripped down code than later when the app is doing all kinds of things that could be causing the symptoms.