System architecture: host, Teensy, drivers

15.1 Where to put each piece

You have a fast microcontroller and, presumably, a much faster PC. Where the work runs is a genuine choice, with two defensible answers.

Thin Teensy, thick host. The PC does path planning, trajectory generation, and inverse kinematics, and streams joint-space or even step-space commands to the Teensy at some fixed rate. The Teensy runs the step generator and the safety checks and nothing else. This is easy to develop — you get to write your motion planning in Python with proper debugging tools and visualisation — and it is how PAROL6's own software stack is arranged.

The weakness is dependency. The arm cannot move without the PC, and any hiccup in the PC's scheduling — a garbage collection pause, a Windows update deciding to do something — shows up as a gap in the command stream. Deep buffering hides most of this.

Thick Teensy, thin host. The Teensy holds the kinematic model and does IK itself. The host sends high-level commands: move to this pose, at this speed. The Teensy is autonomous and deterministic.

This is more work to build and harder to debug, since you are developing numerical code on an embedded target. The result is an arm that works regardless of what the PC is doing, can run a stored program with no host at all, and has a single coherent notion of its own state.

My suggestion is to start thin and migrate. Build the host-side stack first: you will iterate on the kinematics many times, and doing that in Python is far quicker than doing it in C++ on a microcontroller. Once the kinematics are settled and verified, port the IK to the Teensy — a few hundred lines, and the Cortex-M7 runs it in tens of microseconds. Keep the host path working as a development and diagnostic route.

15.2 What the Teensy must own regardless

Some responsibilities belong on the Teensy no matter which architecture you choose, because they must work when the host does not.

Step generation and timing. Soft limit enforcement. The communication watchdog that stops the arm if the host goes quiet. Driver fault monitoring — polling DRV_STATUS for over-temperature and short-circuit flags and reacting. Emergency stop handling. And the authoritative position counters, because if the host and the Teensy disagree about where the arm is, the Teensy is the one holding the actual step counts.

15.3 A suggested pin allocation

A sketch rather than a prescription, but it shows how comfortably it fits.

Six STEP pins and six DIR pins takes twelve. A single shared enable takes one, though giving each driver its own enable costs six pins and buys you per-axis control — worth it. Six DIAG inputs take six. Six limit switch inputs take six. Two UART pairs for the drivers take four. A gripper output takes one or two.

That is somewhere around thirty-five pins out of fifty-five, leaving room for status LEDs, an emergency stop input, an encoder or two if you go closed-loop later, and expansion.

On placement: put the six STEP pins on the same GPIO port if you can, so a single register write sets them all at once. That removes the small skew between axes that comes from setting pins one at a time, which matters for multi-axis coordination. Check the Teensy pin card for which pins map to which of the fast GPIO ports. Keep the UART pins away from the step pins physically on the board and in your wiring, since the step lines are the fastest-switching signals in the system and will couple into anything adjacent.

15.4 Grounding and cable routing, again

Chapter 6 covered this, and it deserves a second pass at the point where you are laying out the real machine.

Motor cables carry amps of fast-switching current and they radiate. Signal cables — especially the UART lines to the drivers, and the DIAG lines — are high-impedance and receptive. Run them apart. Where they must cross, cross at right angles. Twist motor pairs together, which cancels most of the radiated field. If you have persistent problems, use shielded cable for the motors with the shield grounded at one end only.

Ground the system at a single star point. Every ground return — driver power ground, Teensy ground, limit switch commons, the shield — meets at one physical location, and nowhere else. Ground loops turn a working bench setup into an intermittently failing assembled robot, and they are much easier to avoid up front than to diagnose afterwards.