XMEGA Performance and Peripherals

XMEGA performance and peripherals

This page records what the ATxmega192A3 can and cannot do for TinyG's speed, where the processor's time goes today, and which hardware features were reviewed as ways to go faster. It is a design reference for developers. Nothing here is an implemented change, and the cycle figures below are counted from the compiled code, not measured on a running board, unless the text says otherwise.

For how the work is divided between the main loop and the interrupts, read How TinyG keeps real time on an 8-bit processor first.

The budget

Resource	Amount	Notes
Clock	32 MHz	The maximum for this part at 2.7–3.6 V. TinyG does not overclock.
SRAM	16 KB (16,384 bytes)	Current edge firmware uses about 13,620 bytes for static data (data plus bss), leaving about 2.7 KB for the stack and nested interrupts.
Floating point	none in hardware	The ALU has an integer and fractional multiplier only; all float math is done in software by avr-libc.
Step clock	50 kHz	The step (DDA) interrupt runs 50,000 times a second, which leaves 640 CPU cycles per tick for everything.

Where the time goes

The step interrupt is the largest single cost while the motors run. From the compiled code, one tick costs about 267 cycles when no motor steps and about 431 when all four step, against 640 cycles available. That is roughly 42% of the processor whenever motion is running, most of it spent loading and storing each motor's 32-bit accumulator on every tick, including idle motors.

Software floating point is expensive per call (counted for avr-libc at 32 MHz): about 190 cycles for a float add or multiply, about 530 for a divide or square root, about 2,700 for a cube root, about 1,500 to convert one coordinate from text, and about 2,200 to format one number with three decimals. That is why TinyG converts text once per line, plans each move once (refined as later moves arrive), and keeps floating point out of the step interrupt entirely.

The main loop gets what is left. It parses lines, plans moves and writes reports in the remaining time, roughly 6 ms of processor time per line when streaming at about 80 lines per second. On very dense G-code (thousands of tiny moves) this becomes the limit: the machine runs slower than the programmed feed rather than losing steps, and the feed-limit advisor reports why (see Runtime session (rt)).

The serial link is not the bottleneck. At 115200 baud, 80 lines per second uses well under a quarter of the link in each direction, and serial interrupts cost about 1–2% of the processor.

Hardware features reviewed

Idea	Verdict	Why
DMA for USB transmit	Possible experiment; small gain	The XMEGA DMA controller can feed the USART one byte per request. It would save the transmit interrupt work (a few percent at most). It needs careful ownership of the transmit buffer and of XON/XOFF and CTS handling, and it would not raise the line rate, which is set by planning time, not by the serial link.
A hardware timer to end each step pulse	Not a drop-in	Only some step pins have a timer output, and those timers already run the dwell, load and segment interrupts. A second compare interrupt still waits behind the step interrupt. The practical route is to keep pulse widths bounded in the existing interrupt and measure them.
A hardware stop path (timer gating, AWeX fault)	Not a complete emergency stop	Timer gating can stop future step ticks, but not an interrupt already running or a pin already high, and the AWeX fault input only covers its own timer pins, not TinyG's step pins. Neither replaces a hardware E-stop.
Fixed-point math in the planner	Promising, but measure first	Float math is costly, but the step interrupt is already integer-only. Any fixed-point change needs a full range and precision analysis across units, rotary axes, speeds and jerk.
Faster clock or more RAM	Not available	32 MHz is the part's limit, and RAM, at about 2.7 KB free, rules out large new buffers or waveform queues.
High-resolution timer mode, flash CRC unit, interrupt round-robin	No help for motion	They improve waveform edge resolution, idle integrity checks and low-priority interrupt fairness respectively, not the work that limits throughput.

What would actually help, in order

1. Measure first. Add a profile build that marks the step interrupt, the segment interrupt and each stage of line handling on spare output pins, and capture them with a logic analyser. A debugger that halts the processor to sample it distorts the timing and cannot validate real-time behaviour.
2. Make the step interrupt cheaper. Skipping motors that have no steps in the current segment, and keeping the accumulators where the compiler does not reload them every tick, could cut its share substantially and give the main loop more time.
3. Then optimize whatever the profile shows dominates in planning and reporting: fewer divisions and roots per move, and fewer formatted numbers per report.
4. Treat deterministic pulse generation and an independent stop path as separate hardware projects, not as firmware tweaks.

However fast the firmware gets, software is not an emergency stop. Every machine needs a hardware E-stop that cuts motor power.

Related

• How TinyG keeps real time on an 8-bit processor
• Runtime session (rt)
• Introduction to the TinyG Code Base