here are a number of futher optimizations for the g3firmware

[craiglink]

besides the various template optimization that I've already sent, I've done a number of further optimization in the firmware:

1. I've made a number of simple functions which returned a value or just called another function inline instead of being defined in .cc file. This allows a compile time opimization and reduces the call stack, thus saving a few instructions along the way.
2. I've optimized use of the Point struct. This structure was being returned from a function which caused a huge number of instructions to be generated to save off registers, etc. By returning the struct as an out by reference argument there is a 40% saving in instructions around it's use.
3. I've fixed a number of atomic block issues. There were several places that were disabling interrupts unnecessarily. Worse, there were several places that they were necessary and weren't there. Most of these had to do with protecting the computation of the current position from interrupts.
4. Modify the "in" packet code which receives data. It now computes the CRC once all bytes have been received instead doing it after each byte was received. This allows the UART interrupt to be a lot faster and the CRC to be computed while interrupts are enabled.
5. Increased the baud rate between the extruder controller and the motherboard. There is no real reason to run it 38400 baud that I know of.
6. Used int16_t's in the PID controller code. This saves a number of instructions since the temperatures can easily be represented in 16bits and no the math only needs to operate on 16bits.
7. In a few places change the code to use switch statements instead of cascading if's so the compiler could make a jump table for a bit performance boost.
8. I've also added a few placeholder command messages for sending the point coordinates as int16_t instead of int's. which would result in close to a 50% savings of transmitted data. For most cases sending 32bits is just a waste because the point coordinates contain the number of steps that must be moves for a give number of millimeters. Given the build size and StepsPerMM these values could easily be represented in a int16_t. The one place this doesn't work in on a Cupcake running with Gen4 steppers on the Z-axis with 1/8 steps. Switching the dip switchs 1/4 steps for a Z-axis on the Gen4 Cupcake would allow int16_t to be used.

[FarMcKon]

Phew. Ok, that is a pretty big stack of things. I'll try to dedicate some time to looking at this soon.

Thanks for the awesome code!