Extend shift register PIO code to > 4 axes

[andrewmarles]

I have dabbled with it, but I am just wondering if there is a fundamental reason we couldn't extend the PIO shift register code to drive additional axes. In my testing the implementation is certainly fast enough to drive high step rates even with double the serial bitload. Feedback that I have gotten is that people really do need 5 axes of motion - this is part of the reason I did the PicoBOB instead of releasing a breakout design based on the shift register (which I have build and basically have working on my bench) implementation, even though I really like this design a lot. Many hobbyists are using moving gantry machines with ganged axes (not just PrintNC, but that is my main area of interest) because these machines are the most space efficient, and they are also easiest to square because the final alignment is done in software. At the same time, people do seem unwilling to commit to a platform that doesn't allow for the future option of a 4th axis.

I am certainly willing to work on the implementation, I am just wondering if there are any walls that I might run into before I dig into it.

[terjeio]

The PIO program step_pulse can handle up to 6 axes but needs additional support code in driver.c for that. This program is used by your BOB and requires all step and direction signals to be connected directly to the MCU.

However, I guess you are talking about the the other one that uses a single external shift register supports up to 4, this since both step and direction signals are handled by it. It is not possible to modify this program as the PicoCNC map depends on it as it is now, another is that there is only a few (1 or 2?) instruction slots free for extensions.

It should be possible to add yet another that uses two shift registers instead which could then support up to 8 axes. Or perhaps use only one and connect the direction signals directly to the CPU? If using two shift registers it could be a simple as copy the current program and increase the loop count - and define a data structure to match with support in driver.c.

[TPMoyer]

Had previously opened a “general” discussion N_AXIS=8 and have now fixated on the RP2040/RP2350. The PIO is the primary reason, the as-of-yet untapped resource of a second CPU is secondary. Faith in the RPI folks is the hat trick.

HISTORY QUESTION: Why did .program step pulse{} have N_AXIS=6 as a limit. Was something encountered that was beyond resource capabilities, or was it just that no-one expected a need for N_AXIS=8

N_AXIS=8 Implementation Strategy: Presented in the order: best first, worst last…

1. Dual SR8 State Machines
   Steal 3 pins from the PicoCNC GPIO allocation, set up a second State Machine on PIO1.
   Pro’s:
   Could work on an RP2040 as the same PIO1 code can support a second of it’s 4 SM’s
   Con’s:
   a) Need to modify the as of yet opaque sender-of-steps-and-directions to have a second of same which sends the second SM the 4steps4dirs for axis B,C,U,V.
   b) am new to 74HCT595 proto-board and board build

2. Extend generic_map_4axis to generic_map_8axis
   Pro’s: KISS said try this first. Success on steps for X,Y,Z,A,B,C and directions on X,Y,Z,A,B,C,U,V
   Con’s Applicable to only those machines not needing 1 limit switch per axis
   1’st driverPIO.pio mod: Believe not wrong, but did not provide U,V steps.

   Within .program step_pulse changed both instances of out pins,6 ==> out pins,8
   The driver.c driver_init function for STEP_PORT == GPIO_PIO launches step_pulse_program_init with pincount == N_AXIS+N_GANGED, so believe I have isolated the UV output step omission to whatever forms the stepPulse directed into pio_sm_put(pio, sm, stepPulse);

   Question to those experienced with PIO: Does the above paragraph seem like good initial steps into the driver/PIO realm?

3. Dual SR16 State Machines
   Push the step and direction pins onto a second SM on the PIO0
   Pro’s:
   a) Could work on an RP2040 as the same PIO0 code can support a second of it’s 4 SM’s
   b) can use same the pin allocation as picoCNC
   Con’s:
   a) Need to modify the as of yet opaque sender-of-steps-and-directions to remix the bits as 8step8dir
   b) am new to 74HCT595 proto-board and board build
   c) will delay steps by 8 clock cycles, vs dual SR8’s running in parallel.

4. Dual RP2040’s
   Pro’s: quick and dirty for someone able to mod a gcode sender like Grbl4P
   Con’s:
   a) Self serving, inadequate give-back to the community.
   b) Axis position alignment limited to 5 or 10Hz (from status reports)

[terjeio]

HISTORY QUESTION: Why did .program step pulse{} have N_AXIS=6 as a limit. Was something encountered that was beyond resource capabilities, or was it just that no-one expected a need for N_AXIS=8

Resource capabilities (pins, hardware and time for testing etc.) and I believe not many users for 8 axes. Can be extended.

Question to those experienced with PIO: Does the above paragraph seem like good initial steps into the driver/PIO realm?

I think so.

Dual SR16 State Machines

Cannot be used for step generation without adding an interrupt for turning off the step pulses.

[TPMoyer]

Noticed a couple things about set pins in driverPIO.pio

1. there is a sm_config_set_set_pins(); in
   % c-sdk {
   static inline void step_pulse_program_init void step_pulse_program_init()

2. The number of PIO set pins is limited to 0 <= set_count <= 5 per the Parameters paragraph immediately following the pico-sdk documentation sm_config_set_set_pins, also shown in section section 4.1 sm_config_set_set_pins portion of the raspberry-pi-pico-c-sdk.pdf.
   I first encountered this set pin quantity limitation at 6:30 into stacksmashing's In-depth: Raspberry Pi Pico's PIO - programmable I/O!

3. the max set pin quantity=5 is violated when N_AXIS +N_GROUPED >= 6
   as is the case for the present exercise of N_AXIS =8

4. none of the programs in driverPIO.pio actually set any of the pins with the set instruction ie. the
   set pins, #
   instruction does not occur anywhere in driverPIO.pio

Net:
No one is using set pins,
and for N_AXIS=8, retention of sm_config_set_set_pins(&c, startPin, pinCount);
puts me at best in the always-to-be avoided state of “undefined”,
and at worst, in the violation of documentation parameter limits.

Would it be Ok to comment out the
sm_config_set_set_pins(&c, startPin, pinCount);
within the https://github.com/grblHAL/RP2040
step_pulse_program_init()?

[terjeio]

It has been a while since I worked with PIO code so I cannot answer without digging into this again.

[TPMoyer]

Success on N_AXIS=8!
Albeit with generic_map_8axis.h, not one of the Shift Register approaches.
This first diagnostic implementation is on a protoboard with logic analyzer attached.

sent a gcode of
g91 x-1 y-0.5 z-0.2 a-1 b-1 c-1 u-0.2 v-0.5

Swapped in a pico RP2040

sent a gcode of
g91 x-1 y-0.5 z-0.2 a-1 b-1 c-1 u-0.5 v-0.2

Mods from github.com/grblHAL/RP2040 are:

Added \grblHAL\RP2040\boards\generic_map_8axis.h
Added sublAllRP2040.bat to grblHAL\RP2040 to easily pull all files into a sublime text session
Added sublAllGrbl.bat to grblHAL\RP2040\grbl to easily pull all files into a sublime text session

in my_machine.h added
#define BOARD_GENERIC_8AXIS

In driver.jason added two sections
{
"name": "Generic 8 axis",
"symbol": "BOARD_GENERIC_8AXIS",
"MAP": "boards/generic_map_8axis.h",
"caps": {
"axes": 8,
"i2c_strobe": 1,
"wifi": 1,
"bluetooth": 1
}
},
{
"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"
}
}

in driverPIO.pio .program step_pulse
changed both occurrences of out pins, 6 to out pins,8

in driverPIO.pio
% c-sdk {
static inline void step_pulse_program_init()

commented out
// sm_config_set_set_pins(&c, startPin, pinCount);
which is allowed as none of the .program methods used set pin
and is needed as with my N_AXIS=8, this config is in violation of the SDK limit of 0 <= pincount <= 5 for set pins

In driver.c modified pio_steps_t to have set:8 and reset:8

typedef union {
uint32_t value;
struct {
uint32_t delay :8,
length :8,
set :8, /* prior to generic_map_8axis had value of 6 /
reset :8; / prior to generic_map_8axis had value of 6 */
};
} pio_steps_t;

In driver.c Extended several sections to include axies BCUV
In driver.c Enhanced readability by
a) having #ifdef and #ifndef cause indentation
b) put brackets on single-line if, else, and while statements
c) moved opening { to right of method declaration to match position in if, else, switch, while

Current effort is a fork at github.com/TPMoyer/RP2040

Is there an assessment protocol to demo this is correctly extended to N_AXIS=8,
without collateral dings to previous function?

[terjeio]

Great you got it working - I'll look into this later, I need a break from coding now.
Later I will also improve PIO state machine assignment and add support for spindle sync so adding this to my task list then suits me well.

[terjeio]

In driver.c Enhanced readability by
a) having #ifdef and #ifndef cause indentation
b) put brackets on single-line if, else, and while statements
c) moved opening { to right of method declaration to match position in if, else, switch, while

Do not change any code not related to what the actual changes are, it makes it much harder to review a PR and I would simply dismiss it.

[TPMoyer]

Changed mods of driver.c to be only those required by this PR.
Current full list of mods is:

Added \grblHAL\RP2040\boards\generic_map_8axis.h

in \RP2040\grbl\config.h
changed N_AXIS = 4 to N_AXIS=8

in my_machine.h added
#define BOARD_GENERIC_8AXIS

In driver.jason added two sections
{
"name": "Generic 8 axis",
"symbol": "BOARD_GENERIC_8AXIS",
"MAP": "boards/generic_map_8axis.h",
"caps": {
"axes": 8,
"i2c_strobe": 1,
"wifi": 1,
"bluetooth": 1
}
},
{
"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"
}
}

in driverPIO.pio .program step_pulse
changed both occurrences of out pins, 6 to out pins,8

in driverPIO.pio
% c-sdk {
static inline void step_pulse_program_init()

commented out
// sm_config_set_set_pins(&c, startPin, pinCount);
which is allowed as none of the .program methods used set pin
and is needed as with my N_AXIS=8, this config is in violation of the SDK limit of 0 <= pincount <= 5 for set pins

In driver.c modified pio_steps_t to have set:8 and reset:8

typedef union {
uint32_t value;
struct {
uint32_t delay :8,
length :8,
set :8, /* prior to generic_map_8axis had value of 6 /
reset :8; / prior to generic_map_8axis had value of 6 */
};
} pio_steps_t;

In driver.c pio_steps_t; changed
set: 6 to set: 8
reset :6; to reset :8;

In driver.c outputpin[]
in both first and trinamic sections, added U and V axies

In driver.c stepper_set_step
added U and V axies

In driver.c stepper_step_out1
added U and V axies

In driver.c stepper_set_dir under #else // DIRECTION_OUTMODE <= GPIO_MAP
added U and V axies

In driver.c limitsGetState
added U and V axies

In driver.c settings_changed

under 
#if SD_SHIFT_REGISTER
#else // PIO step parameters init     
	added    U and V axies

under 
/***********************
 *  Input pins config  *
 ***********************/	

added Input_LimitU and Input_LimitV 

In driver.c driver_init
#if STEP_PORT == GPIO_PIO_1
#if N_ABC_MOTORS
added U and V axies

The mods to RP2040 are in https://github.com/TPMoyer/RP2040
The add to /RP2040/boards is in https://github.com/TPMoyer/RP2040-boards
The N_AXIS=8 change to config.h is in https://github.com/TPMoyer/RP2040-grbl

[phil-barrett]

This is an interesting discussion. The one place where I have seen demand for a large number of stepper channels is in the Pick-and-Place groups. The max step rate is one area of concern but perhaps not as big an issue for the PNPers.

Note that if you want 8 axes and don't care about individual enables for the steppers, you can easily get to 8 with the RP2350B and no SRs involved.

The PNP folks also like a large number of digital I/Os so maybe that is a good role for SRs (input and ouput).

[HubertBloom]

Is this PR accepted and integrated now?
The table in the drivers readme still lists 6 axes maximum for RP2040 and RP2350.

[terjeio]

There is no PR to accept, anyway I have now updated the driver to support up to eight axes and added an example generic map file. I will not add the eight axis map file to the Web Builder since is hardly usable, PRs for map files for boards that make use of more than six axes are welcome.
I have also moved the code for 16-bit shift register based outputs from the Pico CNC board to a separate file so that it can be easily incorporated in other board maps, this plus the extended ioports API makes it easy to add more I/O - for now max 24 digital in/out ports and max 8 analog in/out ports.