Email: Password: Remember Me | Create Account (Free)

Back to Subject List

Old thread has been locked -- no new posts accepted in this thread
???
09/05/08 16:17
Read: times


 
#157980 - Scale offset using ints by byte position location
I've run across an issue and I'd like to recycle some code to keep the problem simple. I have a stepper motor that moves an assembly on a hyperbolic curve. I've discovered the limits to move the assembly and its limits. Using an array look up table based on its position, I want to set the limits from the lookup table. The problem:

The limits are INT and the control is in BYTE

From months gone by, I've been using this with all of my BYTE data:
HC_Gain_scaled = (((HC_GAIN_HIGH - HC_GAIN_LOW) * pot_level)) >> 8; //Average and divide by 256

HC_Gain_scaled += HC_GAIN_LOW;


Now, HC_GAIN_HIGH - HC_GAIN_LOW will be INT data and no longer BYTE

The pot level is used for control which is 00-FF (BYTE). So in this example, I can't simply divide by 65535 because the multiplier of the pot level is only a BYTE, in which lies my issue. Shifting the bits won't work, I've tried multiply by 100h and 101h and that doesn't seem to yield the right answer either.

Is there an easy way to adapt this simple statement so the pot_level from the ADC can set the problem int limits.

I've looked throught the help file of Keil and all I see is string to int, long nothing about byte. I've looked at INTPROMOTE, but I don't see the relevence since it is for porting code rules.

Can someone give me a pointer on this?

Thanks
Chris

List of 15 messages in thread
TopicAuthorDate
Scale offset using ints by byte position location            01/01/70 00:00      
   Does type casting make sense here?...            01/01/70 00:00      
      Show us more.........            01/01/70 00:00      
         Here are defs and original function            01/01/70 00:00      
      ints, at leastin Keil, at 16 bits wide.            01/01/70 00:00      
         Christoph,            01/01/70 00:00      
            That makes things clearer.            01/01/70 00:00      
               A detail            01/01/70 00:00      
            Take a look at the ranges            01/01/70 00:00      
               Brett, that is helpful, I should add....            01/01/70 00:00      
                  No floating-point math required.            01/01/70 00:00      
   Its working but I have a question on theory            01/01/70 00:00      
      Rounding instead of truncate            01/01/70 00:00      
         oh, that is interesting            01/01/70 00:00      
         Russ' comment is right, though.            01/01/70 00:00      

Back to Subject List