Let's take a look at design.
If you design your project well, looking at all possibilities up front without coding a single thing you can catch some problems up front that you may run into. One of those may cause messy or unneeded code! That's again the beauty of the artist they can choose whether they want to keep repainting the exact same thing or really go out there and paint something new!
What all can be designed?
For Microprocessors where you have a limited number of register's to use, defining a personal/project standard allows greater code re-use, as well as less code and easier to understand code.
If you define a register as the UART pointer from the beginning and make sure not to change it, you won't have to constantly be re-writing the code to setup a pointer. How many times does that have to happen? Well if everytime you have to drop into your interrupt service routine and determine whether it was a RX or TX bit that sent you running, that's 2 times for every "interrupt". I know it doesn't sound like alot of time, but when you run into a situation where your time is critical, 2 instructions can make that difference.
The short time that it takes to design your project, can multiply the rewards exponentially.
Deciding how you want to setup each module is part of design, would you rather setup the entire initialization in your main routine for each module, and let that handle everything OR modularize everything and put ALL uart related items in the UART section.
This brings up the good point of .include files, by putting all your setup into a .include file, you can now start using that file in new projects and rather then constantly having to re-write a subroutine you just write it once, and any improvements you make are better for all programs, (provided they are in fact better). Writing this I already see a flaw in the design of the program we made in our latest lab!
Guess what? Looking back on it, I realize we have a file called variables that contains the ".set" items that point to the UART and all other associated names, this means that every file that I try to .include the UART routine into has to have the entire variables file included, Guess what we did that with a "register setup file too!!!".
How can this be improved?
I can put all registers that the UART EXPECTS to use in it's .include file as part of the initialization, and make sure that any time I use that file those particular register's are in that state before the subroutine is used, this can occur by pushing the register settings to the stack before any updates to them, then reverting them back, will allow the subroutine to keep using them as expected.
If there is one thing I'll stress, Try to make your code as uncomplicated and easy to understand for yourself and others, Implementing a design can aide in that.
Let me know how you design!!
