In SX Microcontrollers, SX/B Compiler and SX-Key Tool, g_daubach wrote:

Hi Elliot, and all "lurkers",

I did a lot of breadboarding when preparing the application sample chapters for my book. Due to the new professional development board, I tend to do even more breadboarding than before, because it is so much fun with such an ample breadboarding area, and many useful components on board, just a wire jumper away - THANK YOU, Parallax"!

When starting a new SX project, you should first just insert the SX28, hook up the SX-Key, and see if you can send the basic part of your planned application to the SX, and test if you can debug it, for example, the code to clear the RAM and to initialize the port configuration registers.

When this works, you can add more components (in hardware on the breadboard, and in software to the application). For example, you could attach components to the planned SX output lines, like LEDs, Relays, etc. Even if your code does not yet contain the logic to control such components, you can use the debugger, set a breakpoint on some instruction following the initialization. Clicking on the bits in the port register's binary representation, you can toggle the output lines to verify if the connected components are driven by the output lines as expected.

Next, you can do the same with the input lines, i.e. connect them to pushbuttons, DIP switches, or any other components driving SX inputs. Again, you can run the basic program to a breakpoint located at some meaningful location, and then actuate the input components, watching if the associated port bits are changing as expected.

When you have mastered this, you can be pretty sure that the hardware part of your project is free of bugs. Next, you will have to dive into the "mysterious adventure" of adding more and more components to your software part of the project. I can promise you - the probability to run into errors here, is much higher than before when you have set up the hardware. Nevertheless, you should be able to master this part as well. Again, think of modules, or components. Don't try to enter code for the complete project at once. Add routines to handle certain tasks first, and - if necessary - write a "wrapper" (to be removed again later) in your main program to call and test these routines.

Design the software part of your project as modular as possible. It is better to spend some more instruction words and execution cycles for subroutine calls and returns (with the right pages selected before), even if a soubroutine might be called only once in a program than trying to write "tricky" code in the beginning. You may optimize your code later, when it turns out that this is really required to reduce code size, or to gain execution speed. If this is not the case, just don't do it - this keeps your code well-structured making it a lot easier to add enhancements later when neccessary.

Following these rules, you (and not only you :-) ), will be able to successfully create fine projects with the SX - and don't forget to comment your code  - at least when you think you are doing something "tricky". Later, you'll be glad that you have added such comments, when sitting there, scratching your head, asking yourself: "What the hell are these instructions good for?".

BTW: Two bugs meet in a program. Says the first one: "My programmer is trying to fix me since a week!" Says the other one: "Well, my programmer does not even know about me".

Bugfree programming!

---------- End of Message ----------


You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=84675#m84707

Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com

The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2005 (http://www.dotNetBB.com)