I have been looking though teacup firmware and I believe I found a possible resolution to the speed calculation overflow issue.
There is also a minor change to reduce a few cpu cycles per G# line.
Diff list
The background in these ideas:
Calculation starts with the upper 16 bits and then process the lower 16 bits.
This doesn't return the exact same result as the original would have if it was 64 bit value, which would be a lot more processing.
at 65,536 the correct value would be 104,755,299, but this returns 104,752,103.
65,700; 105,280,243; 104,752,767
262,652; 1,682,587,148; 419,014,805
So as you can see, the returned value isn't completely accurate as the value goes up but it will not overflow. The 65535+ value is pre-calculated value.
I believe when it comes to those values for speed accelerations the variable would not be noticeable. ( does anyone have a setup that would clock that much per meter? )
As for the speed change.
By changing the function to a define it will force it to be inline and remove a CALL command, which consumes 4-5 clock cycles per G# instruction ( 6 instances of enqueue() just in gcode_process.c ).
Note: I have not been able to test out the speed effect as my current build ( plasma cnc table running completely stripped down TeaCup ) cannot run over 1500 without having quality issues. It is also, 2d so very little detail to bog the mpu down.
Setup:
Linux Ubuntu 10.04 32-bit
Pronterface
Teacup ( stripped, x/y only, added plasma trigger, no heater, no temperature, no z/e )
Gen7 1.4.1
ATMega644 @ 20Mhz
Let me know what ya think. I'd really like to see the sdcard/lcd setup and might work on it sometime too.
There is also a minor change to reduce a few cpu cycles per G# line.
Diff list
The background in these ideas:
Calculation starts with the upper 16 bits and then process the lower 16 bits.
This doesn't return the exact same result as the original would have if it was 64 bit value, which would be a lot more processing.
at 65,536 the correct value would be 104,755,299, but this returns 104,752,103.
65,700; 105,280,243; 104,752,767
262,652; 1,682,587,148; 419,014,805
So as you can see, the returned value isn't completely accurate as the value goes up but it will not overflow. The 65535+ value is pre-calculated value.
I believe when it comes to those values for speed accelerations the variable would not be noticeable. ( does anyone have a setup that would clock that much per meter? )
As for the speed change.
By changing the function to a define it will force it to be inline and remove a CALL command, which consumes 4-5 clock cycles per G# instruction ( 6 instances of enqueue() just in gcode_process.c ).
Note: I have not been able to test out the speed effect as my current build ( plasma cnc table running completely stripped down TeaCup ) cannot run over 1500 without having quality issues. It is also, 2d so very little detail to bog the mpu down.
Setup:
Linux Ubuntu 10.04 32-bit
Pronterface
Teacup ( stripped, x/y only, added plasma trigger, no heater, no temperature, no z/e )
Gen7 1.4.1
ATMega644 @ 20Mhz
Let me know what ya think. I'd really like to see the sdcard/lcd setup and might work on it sometime too.