← Revision 6 as of 2010-08-21 03:33:54
|Deletions are marked like this.||Additions are marked like this.|
|Line 29:||Line 29:|
|this serves two functions. first, it makes it easier to read - no one likes non-linear narratives. second, it will most likely reduce the number of jumps you have to make.||this serves two functions. first, it makes it easier to read - only film majors like non-linear narratives. second, it will most likely reduce the number of jumps you have to make.|
These tips represent things i've come across while programming the MICrODEC, but are probably useful for other programming tasks as well. They will reflect my use of assembly, but hopefully we can add C tips in the future. For the most part, its a list of good documentation habits, which doesn't seem like coding at first, but when you get down to it, coding is really just writing down your thoughts in a very weird language. So its good to put translational bits everywhere.
it may seem like a waste of time, or that it uglies up the code, but you can never have too many comments. as a friend of mine once told me, "comments are a favor you do to your future self." i often go back to fix something that i worked on a few weeks ago, and for the life of me i can't remember why i did something a certain way. this keeps you from redoing work. also, if you borrow bits of code from other programs, you can quickly tell whether it will work for your application. for example, if a bit of code assumes that some register is set before it is executed, then you might need to set that register yourself when you move it somewhere else.
this holds doubly true for the entire program itself. write a description of what it does, how it does it, and where you got any outside code bits from. this will help others if they want to use your code as well.
if you're keeping track of your registers yourself (which is the most efficient way to do it), then have a list at the beginning of your code that shows what each register does, and stick with it. unless you need to save data between samples, you won't need to have a lot of permanent registers (ones used exclusively for a particular function). but, you will probably need at least two temporary registers (ones to swap things in and out of for multiplying, e.g.). note that some registers can only be used for specific functions. if you want to fetch something from program memory, you'll most likely need the Z-register (r31:r30). so try to put thing in r15 through r2 if possible. r1:r0 is used for multiply result, so its best to keep that clear. the only downside to these lower registers, is that you can't do any immediate operations on them, so they are a bit slower.
the second tip that is implied here is: use variables! when setting up things you might want to change in the future, or that you call in more than one place in your code, its handy to not have to find every instance you wrote that number, and replace them by hand. it also gives future users the ability to quickly mod parameters and get new effects. these should be clearly declared at the top of the function with what they do, and how they are calculated.
Use a UID
i'm sure this isn't something you'd have to do if you used C, but for the way things are currently set up with the MICrODEC, place a Unique ID after each variable so you don't conflict with other code loaded in the Function Bank.
Write the code in the order it happens
this serves two functions. first, it makes it easier to read - only film majors like non-linear narratives. second, it will most likely reduce the number of jumps you have to make.
Compartmentalize your code
its a good idea to write a chunk of code that does something well, and then just call it whenever you want to use it. this reduces the probability of writing that same chunk of code wrong the second time, and saves on code space. this also allows you to quickly comment out a section, and figure out if it works or not (or more likely, whether it was causing the bug or not).
Don't use rcall
in direct opposition to the dictum above! (sort of). for the MICrODEC, there is tons of code space, and very little time. so to save on execution time, either copy and paste your function from another place, or write a macro. you will still be using small chunks of code, but not wasting time making the jump to it. i've never written a macro, so i can't comment on that method. i usually copy and paste out of the 'Useful Functions' file, and then mod registers as i need.
Don't store to internal SRAM
reading and writing to the internal SRAM of the microcontroller is a last resort for when you run out of registers. it takes at least twice as long as using the registers.
Don't use the 18b address space
unless you need the full 6s sample time, always use the 16b address space. this saves a lot of time, and ensures that you have the SRAM control pins set correctly. even if you need the full 6s sample time, its a good idea to write your program first using the 16b address space, and then migrate it up. this will get the basic functionality down, without adding extra errors from doing 24b math.
Start in mono
when first prototyping a program, write it in mono, and get the bugs worked out, and then switch to stereo if you so desire. the simpler you can make things to begin with, the less likely you will be to make errors.
Start without mods
if you want to have something controllable by the pot, for example, just write the code so it reads a register for the value to begin with. you can define this value at the beginning of the code, and see if the rest of the program works. then, after everything is working, you can have a small function at the end write to that register with the ADC value. this will keep the guesswork down when it isn't working.