Re: Can the GPIO run variable cam phasing?
Posted: Thu Mar 26, 2009 11:46 am
Back to the topic at hand (adding PWM refresh and dither to the outputs):
Why do we add the variables to the code and MegaTune first, why not do it later? You could do that, but there are a few reasons to do it first:
1. One of the better ways to error check the code syntax is compile it often. You can only compile the code properly if all the variables used are declared. I usually compile after adding every complete statement (a whole if statement, etc.) This really helps to nip potential errors in the bud - partly because the compiler doesn't get the location of the error mixed up by a series of coding issues, and partly because if you get an error (and you didn't have any before), you know the error has to be in the statement you just wrote. You don't pay extra for compiling code, so do it often (it only takes a couple of seconds).
2. As soon as you have any useful code, you can check it in MegaTune (or MS TunerStudio, etc.) to see if the variables display properly, etc. So you can do program debugging right from the start, before you have hundreds or thousands of lines of code.
The code has a spare variable built in called outpc.dbug. This is already set up in MegaTune, and has a gauge, it's in the datalog, etc. You can use this variable to get info on the state of the code as you write mods. For example, you might have a statement like:
inside a loop you write to use MegaTune to see if the loop is ever called (and how many times). Or you could set it to a value to see the internal calculations. Suppose we wanted to know what the duty cycle was set to, we could could use:
outpc.dbug is mostly for troubleshooting. If you want to add a value to the output variables permanently, you should add it to the outpc. structure (I will cover this shortly).
Lance.
Why do we add the variables to the code and MegaTune first, why not do it later? You could do that, but there are a few reasons to do it first:
1. One of the better ways to error check the code syntax is compile it often. You can only compile the code properly if all the variables used are declared. I usually compile after adding every complete statement (a whole if statement, etc.) This really helps to nip potential errors in the bud - partly because the compiler doesn't get the location of the error mixed up by a series of coding issues, and partly because if you get an error (and you didn't have any before), you know the error has to be in the statement you just wrote. You don't pay extra for compiling code, so do it often (it only takes a couple of seconds).
2. As soon as you have any useful code, you can check it in MegaTune (or MS TunerStudio, etc.) to see if the variables display properly, etc. So you can do program debugging right from the start, before you have hundreds or thousands of lines of code.
The code has a spare variable built in called outpc.dbug. This is already set up in MegaTune, and has a gauge, it's in the datalog, etc. You can use this variable to get info on the state of the code as you write mods. For example, you might have a statement like:
Code: Select all
outpc.dbug++; // increment dbug - this is equivalent to outpc.dbug = outpc.dbug+1
Code: Select all
outpc.dbug = (PWMDTY3 * 100)/PWMPER3; // output the duty cycle percent of PWM channel 3
Lance.