??? 12/15/05 08:07 Read: times |
#105266 - Possible suggestion. Responding to: ???'s previous message |
Firstly, you haven't given us any numbers - engineers like numbers. As for your acceleration - what is your required range for the rate of change? What is the granularity? 1mm/year to lightspeed in increments of 1mm/sec? Generally, you have a fixed timebase, call it the timer tick. Each timer tick you need to add or subtract a number (determined from your ADC input) to the output value. Mostly this number is fractional - this is where the problem shows itself as the cpu deals in integer values. The solution is to simulate a fractional value. We need to imply a decimal point. To do this we add extra bytes for the calculation. So if the OCR1 is 8 bits, we need more bits to cope with our 'fraction'. For instance, if we used a 16 bit number and we imply the decimal point is between the high and low bytes. The high byte is used to load the OCR1 the low byte then is our fractional value (in this case 1/256). If we add a value of 1 to our 16 bit number, it will take 256 adds to increment the high byte that goes into the OCR1. If we add 2, it will take 128...and so on. If you need finer control, then you can go to 24 bits, 32 bits etc. How many bits you need is determined by your timer tick time, the upper and lower bounds for your accelleration value and the granularity of this value. Also, are you using assembler or C? |
Topic | Author | Date |
Acceleration rate | 01/01/70 00:00 | |
Possible suggestion. | 01/01/70 00:00 | |
numbers | 01/01/70 00:00 | |
Another Suggestion | 01/01/70 00:00 | |
re hysteresis aka "dead zone" | 01/01/70 00:00 | |
Hysteresis vs Dead Zone | 01/01/70 00:00 | |
OK | 01/01/70 00:00 | |
Are you sure? | 01/01/70 00:00 | |
you are right | 01/01/70 00:00 | |
I'm confused! | 01/01/70 00:00 | |
it's working now :-)![]() | 01/01/70 00:00 |