You can use millis() to get reasonably accurate timed activities.  Example:

Your example fails to work correctly as millis approaches the wrap.

Good point.  Couple minor tweaks can fix that.
1.Change the assignments to timer = millis();
2.Change the if condition to (millis() - timer > 2000)

The standard method of initializing a stepper motor position is with a "home" position switch.

If you want your stepper motor to have a 0-180º range of motion, set up a mechanic switch at the 0 or 180º point.  During startup, move the stepper motor in the direction of your home switch until the switch is activated.  Now you know the position of the motor, and can move it to the 90º starting position.

Another option (since you do not require continuous rotation) is using a potentiometer as a voltage divider tied to the stepper motor shaft.  This will allow you to determine it's current position without having to move the motor.

delay() is a blocking delay, won't work for what you are trying to accomplish.

You can use millis() to get reasonably accurate timed activities.  Example:

Code:

unsigned int timer = millis() + 2000;

void setup(){
  Serial.begin(115200);
}

void loop(){
 
  if(millis() > timer){
    //run myRoutine every 2 seconds
    myRoutine();
    timer = millis() + 2000;
  }
 
  //Rest of program here
 
}

void myRoutine(){
  Serial.println(millis());
 
}

Use an unsigned long.

unsigned int is a 16bit type with a range of 0-65535.
unsigned long is a 32bit type with a range of 0-4,294,967,295.

tinkering with my attiny84 @ 16MHZ

What's the clock source for your attiny?  Is it a resonator or crystal?  Resonators are not very accurate and could easily account for the discrepancy you're seeing.

To trigger a task off a specific character received through the serial port:

Code:

if(Serial.available()){
  if(Serial.read() == '1'){
    //do task here
  }
}

If you need that task interrupted and restarted on another value being received from the serial port... that's a bit trickier.  You're either going to have to regularly check the serial data throughout the task you're doing, or generate a timed interrupt that checks the serial port at regular intervals, and somehow abort and restart the current task if another '1' is received.  It all depends on how instant your real time response needs to be.

If you also need to respond to other serial data coming in through the serial port, that only further complicates things.

So, store the "expected/ideal" gear ratio in your array.

Take your actual reading, calculate it's adsolute deviation from each of your ideal gear ratios, and select the one with the smallest deviation as the gear you are in.  So long as there is no overlap, the smallest deviation will always be the gear you are in.

For any given gear, there should only be one actual ratio.  Why do you have a min and max ratio for each gear?

The following should work to convert the two ints back into a long:

newlong = ((long)H << 16) | L;

But it will depend on the platform and programming environment you are working in to conver it back.  This assumes that H and L are two 16 bit variables, and that (long) is a 32 bit variable.  On most modern PCs and programming languages, ints are 32 bit variables and longs are 64 bit variables.  H and L may need to be declared as shorts and your 32 bit variable just declared as an int. (and the cast would be (int) instead of (long) as well)

I'm not quite sure what your expectations are here.  The intermediate int decimal values will in no way correlate to the original long decimal value.  If they are only being used as a necessary step to transfer the entire data, then that doesn't matter.

What matters is that the bit representation is maintained.
Say you have a long value of (just for example) 1,582,081.
It's binary representation would be:
00000000 00011000 00100100 00000001

If you then assign that value to two ints with bitwise shifting, you would end up with
high int 00000000 00011000
low  int 00100100 00000001

If you then properly recompose that back into a new long, that new long will have the same decimal value as the previous one (assuming the binary representation of that decimal value is the same across any platform transitions).

You could use unsigned ints for your intermediate variables and it wouldn't make a difference.  You could even use 4 bytes or chars instead.

With -1 as ValueLong I read on serial monitor:

L = 11111111111111111111111111111111
H = 11111111111111111111111111111111

That looks completely correct.  Signed ints are stored in a twos complement format.  Google it for more info on how twos complement works, and why it's an ideal format to use for signed ints.

Bitwise manipulation in general doesn't care one bit (no pun intended) about the sign or format of the variable they are operating on.

If you decompose a 4 byte variable into two 2 byte variables, and then later recompose them back into a 4 byte variable, the bit patterns will remain identical.

That's not to say there won't be any sign issues, but they will not be related in any way to the bitwise operations (for example, there may be endian problems if you are transferring the data between platforms with different endian'ness').

Just use:

HighINT = ValueLong >> 16;
LowINT  = ValueLong;

And be done with it.  The masking is unnecessary.  The results won't match your other method, but that is because, as AWOL has correctly pointed out, your other method is incorrect.

What you have is almost what you need.  Just needs two tweaks...

change +output to -output in your second analogWrite.

One of your if statements should handle the case where outputValue = 0.  Either use >= in the first line, or <= in the second line.

You shouldn't be using separate serial reads in your code.  Add your motor control code into the first serial read switch/case.

Code:

if ( Serial.available()) {
    char ch = Serial.read();

    switch(ch) {
        case '0'...'9':
           switch(readState) {
             case STATE_NONE:
               break;
             case STATE_PINNUMBER:
               pinNumber = pinNumber * 10 + (ch -'0');
               break;
             case STATE_POSITION:
               position = position * 10 + (ch -'0');
               break;
           }
           break;
        case 'g':
           servos[pinNumber].write(position);
           pinNumber = 0;
           position = 0;
           readState = STATE_NONE;
           Serial.print("p");
           Serial.print(pinNumber);
           Serial.print("m");
           Serial.print(position, DEC);
           Serial.print("OK");
           break;
        case 'p':
           readState = STATE_PINNUMBER;
           break;
        case 'm':
           readState = STATE_POSITION;
           break;
        case 's':
            motor3.run(FORWARD);
            motor4.run(FORWARD);
            delay(17);
            motor3.run(RELEASE);
            motor4.run(RELEASE);
            break;
        case 'w':
            //motor control code
            break;
        case 'a':
            //motor control code
            break;
        case 'd':
            //motor control code
            break;
    }
 }

If I have a latitude (as a string) of say 12345678, I can convert this to a float or double such as 123.45678.

This may be part of your accuracy problem (if it's not just a trivial example without proper conversion).

In your first post you say you're getting a string as  DDDMMmmm, which is degrees, minutes, and decimal fractions of a minute.  Based on this format, 12345678 does NOT equal 123.45678 degrees.

It is 123 degrees and 45.678 minutes.

45.678 minutes = 45.678/60 degrees, or 0.7613 degrees.

So 12345678 would then equal 123.7613 degrees.  If your actual calculations are indeed making the proper conversion, then ignore this post.