1
Technical support / How compiled is the code?
« on: November 11, 2005, 09:39:24 PM »
Here is my first test program that sits in a single custom function on a "Norm.On" rung. There is a second DiffUpCustFunction on a 1.0 second pulse that prints the value of "j" to the LCD. That's the whole program.
What I'm getting concerned about is that the below code continuously cycles at a rate of only 160 odd Hertz. That is about one hundredth of the pace that I was hoping for.![Sad :(](https://triplc.com/smf/Smileys/default/sad.gif)
This function should compile to less than 40 instructions and if that's running in embedded program space on say a 10 MIPS core then we have a 4 microsecond execution time for this section which leaves 6246 usecs for the refresh cycle of two analogue inputs.![Wink ;)](https://triplc.com/smf/Smileys/default/wink.gif)
Evan
What I'm getting concerned about is that the below code continuously cycles at a rate of only 160 odd Hertz. That is about one hundredth of the pace that I was hoping for.
![Sad :(](https://triplc.com/smf/Smileys/default/sad.gif)
This function should compile to less than 40 instructions and if that's running in embedded program space on say a 10 MIPS core then we have a 4 microsecond execution time for this section which leaves 6246 usecs for the refresh cycle of two analogue inputs.
![Wink ;)](https://triplc.com/smf/Smileys/default/wink.gif)
Code: [Select]
a = adc(1) : b = adc(2) 'Snap readings
i = (i + 1) & &H0f
j = j + 1
dm[i+1] = abs(a - b) 'Insert computed error
c = dm[1]+dm[2]+dm[3]+dm[4]+dm[5]+dm[6]+dm[7]+dm[8]+dm[9]+dm[10]+dm[11]+dm[12]+dm[13]+dm[14]+dm[15]+dm[16]
c = c * 3125/8192 'Convert to mA, (100 / 20 * 5000 / 4096 / 16)
if c > 100
clrio RUNNING
endif
Evan