Help with Design: Using processor time efficiently when dealing with serial

Projects General Guidance
6

Hey,

thanks for all the replies.

It sounds like I don't need to worry too much about time wasted for sending/receiving serial messages.

I should regularly check the state of the temp monitor and USB slave device, and store the values in variables so that they can be sent when requested (this will usually be once per loop anyway). eg

int temp;
unsigned long lastGotTemp; // time I last saved temp
int usbSlaveState;
boolean msgRcvd = false;

void getTemp(){
    char buf[bufLength];
    int temp;
    sendRequest("TEMP");
    lastGotTemp = millis();
    receiveRepy(buf);
    disablePIDInterupt();
    temp = atoi(buf);
    enablePIDInterrupt();
}

ISR pidControl(){
    // called when a timer over flows
    // using current temp etc values, calculate new output and applies it
    // restart timer
}

loop(){

    getTemp();
    getUSBSlaveState(); // similar to getTemp()

    if (msgRcvd ){
        // figure out what the display wants done
        // ...
    
        if(setSomethingOnUSBSlave)
            // set thing on USB slave
            
        if(someThingElse)
            // do other thing

       sendReplyToDisplay();
       msgRcvd = false;
    }

    automate(); // state machine function for opening closing valves etc

}

SerialEvent(){
    //Saves received characters to a circular buffer.
    // checks if full message received yet
    // if full msg received, sets a flag to true
}

If I used a finite state machine to process requests from the display, wouldn't I need to create a state for every single combination of requests i could receive from the display? as a received message could contain a request for several things at once eg current temp, set some value, get some other value ...

wildbill:
Just steer clear of delay.

Why should I steer clear of delay(), what should i use instead?

Should I have my PID function in an interrupt? Or should I do this in the loop also? I initially thought to use interrupts as it is pretty critical that it happens regularly (I'm meant to be aiming for +/- 5 milli Kelvin stability), which is why I also thought I would need to check the temp just as often.

Thanks again for your help