Servo controller design with a broom engine on RT-Thread + RA6M4

• 1
  What a broom engine does inside a servo controller design
• 2
  Task and interrupt layout on RT-Thread
• 3
  Choosing the control period and PWM frequency
• 4
  Encoder and sensor feedback paths
• 5
  Where RT-Thread and RA6M4 stop being the right choice
• 6
  Control platform comparison for servo controller design

A broom engine is a low-level motion scheduler. It is not a control law by itself. It keeps a table of motion segments, decides which one is active, and hands the next setpoint to the current loop at a fixed tick. The name comes from the way it sweeps expired segments off the queue, the same way a broom clears a floor.

That split matters. The control law stays small and deterministic, while the segment table can grow to hundreds of entries for a multi-axis move. On the RA6M4 the table lives in SRAM, and the engine only touches it between control ticks so the current loop never waits on a memory copy.

The RA6M4 is a Cortex-M33 part with a hardware trigonometric unit and a 12-bit ADC that can be triggered directly by a timer event. That trigger path removes software jitter from the current sampling. On a servo controller design, sampling jitter is often the largest single source of audible noise and torque ripple.

RT-Thread sits above the engine. It owns the network stack, the file system and the command shell, none of which may run at control priority. Keep that boundary clean and the loop stays predictable even when a Modbus frame arrives mid-move.

• 1
  Engine owns timeIt decides when a new setpoint is published, not the application thread.
• 2
  Control law owns shapePID, feedforward and notch filters run on the published setpoint.
• 3
  RTOS owns the outsideComms, logging and UI run below control priority.

Three execution levels are enough for most builds. The current loop runs in the timer interrupt at the highest level, the broom engine runs as a high-priority RT-Thread thread, and everything else runs below it. Adding a fourth level usually adds latency rather than removing it.

Run the current loop in the ADC end-of-conversion interrupt, not in a periodic timer. The ADC trigger comes from a timer compare event, so the loop starts at a fixed point in the PWM period. This ties sampling to the switching cycle and keeps the phase margin stable as bus voltage moves.

Give the broom engine a thread priority of 8 or higher on RT-Thread, and the comms thread something like 20. RT-Thread schedules by priority with time slicing only among equal priorities, so a higher-priority thread preempts cleanly. Do not enable time slicing on the engine thread; a sliced engine can miss a segment boundary.

Shared data between the engine and the current loop should be a single struct written by one side and read by the other. Use a short critical section or a double buffer, not a mutex. A mutex inside an interrupt path is a bug waiting for a busy network.

• 1
  Sampling in the ADC ISRTriggered by the same timer that drives PWM, so jitter stays under one clock.
• 2
  Engine at priority 8+It must preempt comms, not queue behind it.
• 3
  No mutex in the ISRUse a double buffer or a flag bit instead.

Start with a 1 kHz current loop and a 10 kHz PWM carrier. That ratio gives ten switching cycles per control update, which is enough to keep current ripple bounded without asking the MCU to do heavy math every 100 μs. On a 200 MHz M33 core, a field-oriented current loop with two PI regulators and a park transform fits comfortably in that budget.

Raise PWM to 20 kHz only if the motor inductance is low enough that current ripple is a real problem, or if the audible band matters. Each doubling of carrier frequency costs switching loss and ADC settling time. The RA6M4 ADC needs a defined sample window; a 20 kHz carrier plus a long sample window can eat most of the period.

Position and velocity loops run slower. A 1 kHz position loop is common, and a 500 Hz velocity loop is often smoother on a flexible load. The broom engine publishes setpoints at the fastest loop rate, and the slower loops consume the filtered result.

Measure the loop before you tune it. Toggle a GPIO at the start and end of the current ISR and watch it on a scope. If the ISR body is longer than 40 percent of the period, the design has no headroom for a second axis.

• 1
  1 kHz current loopFits a full FOC pass on a 200 MHz M33 core.
• 2
  10 kHz PWMTen carrier cycles per control update; keep switching loss low.
• 3
  500 Hz velocity loopMore forgiving on compliant loads and flexible couplings.

The RA6M4 has a 32-bit encoder counter that can be clocked from an external signal, so an incremental encoder can drive position without CPU load. Read the counter in the position loop, not in the current loop. Reading it every 100 μs burns cycles and adds nothing, because the position does not move far in ten carrier cycles.

For a resolver or a sin/cos encoder, the trigonometric unit does the arctangent in hardware. That saves the software CORDIC loop and keeps the position loop deterministic. Hardware trig also removes the temptation to approximate arctangent with a low-order polynomial, which introduces position error near the quadrant boundaries.

Watch the sensor bandwidth. A 2,500 line encoder at 3,000 rpm gives an edge rate in the low megahertz range after quadrature decoding. Route those signals as a differential pair or with a shielded cable, and terminate at the MCU side. Noise on the index line causes the worst kind of fault: a position jump that looks like a mechanical problem.

Add a plausibility check between the encoder and any secondary sensor. If the two disagree by more than a defined window for more than a few milliseconds, cut the drive enable. This catches a broken encoder cable before the axis runs away.

• 1
  Hardware encoder counterPosition read in the slow loop, not the current loop.
• 2
  Trig unit for resolverDeterministic arctangent with no polynomial approximation error.
• 3
  Cross-check sensorsDisagreement above a window disables the drive.

This platform suits one to four axes at moderate power, with a control period down to about 100 μs. It is a good fit for pick-and-place heads, laboratory stages, small CNC axes and pump drives where the load is known and the ambient is controlled.

It is the wrong base for a multi-kilowatt drive that needs cycle-by-cycle current limiting at 50 kHz, or for a machine with more than six synchronized axes and sub-microsecond phase alignment. Those jobs need an FPGA, a dedicated motion ASIC, or a DSP with a faster control path and a hardware current limiter.

RT-Thread adds value when the product needs connectivity, a file system or over-the-air updates. If the controller only runs a fixed motion profile and never talks to anything, a bare-metal loop is smaller and easier to certify. Adding an RTOS to a device that does not need one creates work, not capability.

Thermal and supply design limit the platform more often than the software does. A 200 MHz core in a 48-pin package with a 3.3 V rail still needs a clean analog supply, a solid ground plane under the ADC, and gate drive that does not dump current spikes into that plane. Get the layout wrong and no amount of tuning fixes the noise.

• 1
  Good fit1–4 axes, 100 μs control period, controlled environment.
• 2
  Wrong fitHigh-power drives and 6+ axis synchronization below 1 μs.
• 3
  RTOS only when neededConnectivity, storage and updates justify it.