N_AXIS = 8

[TPMoyer]

Am building a 4 tower tensile truss CNC machine, and thus need to co-ordinate 8 motors.
Motivation is to make larger CNC for lower cost. First iteration will cut a 4x8 ft sheet of plywood. Fantasy app is to 3D print houses.
Status: Breadboard RP2040... XYZABC work. U and V not toggling IO lines.

Forked the RP2040 to RP2040_8 and have a breadboard setup with a logic analyzer peeking at what should be the 8 step lines.

First try at N_AXIS = 8 was to mutate the generic_map_4axis.h instead of extending the shift register implementation of pico_cnc.
This fit within the 27 IO of the pico because the truss build will not use any limit switches. Each of the 8 Axies will have absolute position determined from steppers-with-indexers giving position within the cable drum sheave rotation, and will use BoofCV computer vision on Raspberry Pi's to count the number of cable wraps.

Created generic_map_8axis.h implementing and put the #define BOARD_GENERIC_8AXIS into my_machine.h
PIN 00 TX,Primary UART
PIN 01 RX,Primary UART
PIN 02 PIO X step
PIN 03 PIO Y step
PIN 04 PIO Z step
PIN 05 PIO A step
PIN 06 PIO B step
PIN 07 PIO C step
PIN 08 PIO U step
PIN 09 PIO V step
PIN 10 X dir
PIN 11 Y dir
PIN 12 Z dir
PIN 13 A dir
PIN 14 B dir
PIN 15 C dir
PIN 16 U dir
PIN 17 V dir
PIN 18 Emergency stop
PIN 19 Feed hold
PIN 20 Cycle start
PIN 21 Steppers enable
PIN 22 Probe
PIN 25 XYZABCUV Limits. No actual wires 2B connected. $5=255
PIN 26 Spindle on
PIN 27 Spindle direction
PIN 28 Spindle PWM

in /grbl/config.h set
#define N_AXIS 8 // Number of axes

In driver.json added for the RP2040
{
      "name": "Generic 8 axis",
      "symbol": "BOARD_GENERIC_8AXIS",
      "MAP": "boards/generic_map_8axis.h",
      "caps": {
        "axes": 4,
        "i2c_strobe": 1,
        "wifi": 1,
        "bluetooth": 1
      }
    },
In driver.json added for the RP2350
,
    {
      "name": "Generic 8 axis w/RP2350",
      "symbol": "BOARD_GENERIC_8AXIS",
      "MAP": "boards/generic_map_8axis.h",
      "caps": {
        "axes": 8,
        "i2c_strobe": 1,
        "wifi": 0,
        "bluetooth": 1
      },
      "symbols": {
          "RP_MCU": "2350",
          "RP_BOARD": "pico2"
      }
    }

driver.h added
#elif defined(BOARD_GENERIC_8AXIS)
  #include "boards/generic_map_8axis.h"

First pass will implement the kinematics of converting platform position+orientation (X,Y,Z,Pitch,Roll,Yaw) into extensions/retractions for the 8 motor driven cables within my Grbl4P sender. Later may push that into the GrblHAL kinematics but first need to get it figured out.

Upon Grbl4P fire up, after sending $6=1 $5=255 $14=70 the Grbl4P sender causes IO step lines to toggle for X,Y,Z,A,B,C but not for U or V. Internally the GrblHAL seems to believe it twiddled all 8, as the status gives updated positions:
<Idle|MPos:2.000,2.000,2.000,2.000,2.000,2.000,2.000,62.000|Bf:100,1023|FS:0,0>
Also sending G91 x1 y1 z1 a1 b1 c1 u1 v1 gives

and increasing only the v distances causes all the other axies to pulse slower

It seems not to be the case that U and V are remapped to A and B. G91 v2 toggles none of the step IO lines.

Went into driver.c and extended the several sections which had A_AXIS sections (some of which had B_AXIS and C_AXIS sets) and added appropriate B_AXIS, C_AXIS, U_AXIS, V_AXIS sections pointing to matching m4, m5,... etc.
No change after loading flash_nuke.ufe (a behavior taken on after noticing that a simple re-compile + grblHAL.uf2 load did not reset the $ variables) recompile and load of grblHAL.uf2.

noted that several of the variables have .u and .v instances... enumerating only the .u versions:
dir_out.u
limit_fei.u
settings->limits.disable_pullup.u
settings->steppers.dir_invert.u
settings->steppers.step_invert.u
signals.min.u
step_out.u
step_out1.u
DId not get compile nor run time errors, but wonder if the .u and .v are accessing the [6] and [7] members of these arrays.

Unlike driver.c, the full code implementation/extensions to U_AXIS and V_AXIS seem to have been made in
gcode.c
gcode.h
motor_pins.h
nut_bolts.h
settings.h
settings.c
stepper.h
system.c

Any direction as to where to peek/poke to get the 7'sh and 8'th axies moving?

[terjeio]

Any direction as to where to peek/poke to get the 7'sh and 8'th axies moving?

RP2040 has 8 PIO state machines, not enough for 8 axes. You need a RP2350 which has 12 - and a FPU...