Wish: SKR-pico

[kimstik]

It will be cool to support the configuration of a fresh board out of the box:
https://github.com/bigtreetech/SKR-Pico

[terjeio]

There is a board map available and the driver can be configured and built with the new Web Builder.
Are you thinking of something else?

[kimstik]

Funny tool.
Have to be referenced in README.md :)

[cstaton-ftlg]

Hello,
Firstly Thank you for this awesome project, it has opened many doors for me!

Secondly, I would like to bring to your attention a few issues with the SKR Pico board map:

First issue:

• (I think that) Lines 58-64 ("if N_ABC_MOTORS > 0") would enable the use of the 4th Trinamic driver (originally intended for 3D printer extruder) but on line 22 & 23 there is "if N_ABC_MOTORS > 1: error "Axis configuration is not supported!""
• Lines 110-115 will by default of N_ABC_MOTORS ==0, assign RESET_PIN, FEED_HOLD_PIN, CYCLE_START_PIN, AND SAFETY_DOOR_PIN to GPIO pins 16, 13,14, and 15 respectively, however it is not possible to physically use pins 13, 14, and 15 for those signals, because they are routed on the PCB directly to the 4th Trinamic driver (extruder DIR, STEP, EN) with no jumpers or other means of repurposing.
• If lines 22 & 23 were deleted (I assume) this would enable the use of the 4th driver, while "giving up" those 3 signals which really aren't available anyway, so all gain and no loss.
• There is a pin which is not referenced in board map, which could be used for one of the 3 input signals mentioned above: GPIO 29. On the SKR Pico, this is called "SERVOS_ADC3" and is available on Pin3 of connector P11. This is connected directly to the RP2040 chip, no buffer or other interface circuitry.
• Another two pins are (probably) available for the other two signals: GPIO0 and GPIO1. These are available on connector P5, pins 4 and 5, and also go directly to the RP2040 with no interface circuitry. SKR intended these for serial communication to a Raspberry Pi, in the case that one does not want to use the USB connection for comms. I do not think the grblHAL SKR Pico board map is referencing these pins at all, but I'm not 100% sure and it may be referenced by MODBUS at the end of the file?

Second issue:

• There are two more pins not referenced in the grblHAL SKR Pico board map, which could be used for AUX relay outputs or for the flood/mist coolant outputs which are currently commented out on lines 100-105 because of duplicate pin assignments: GPIO21 ("HB_PWM") and GPIO23 ("HE_PWM"). SKR intended these for heating the print bed and the extruder of a 3D printer and the outputs are via low-side switched MOSFETs rated 120A/40V and 65A/40V respectively.
• And then there is GPIO24, not referenced in the grblHAL SKR Pico board map. This pin is connected through a 74HCT365 line driver to connector P24, pin 2, and also to a neopixel LED on the board. I think SKR intended it to be used for controlling more off-board neopixels, but it could be used as an AUX relay output or some other kind of PWM output (on-board neopixel might illuminate randomly but probably not).

In summary, my (maybe misguided) suggestions are:

• Comment out or delete lines 22-24, 58, 64, 107, and 117
• Uncomment lines 100-105
• Change line 103 COOLANT_FLOOD_PIN from 2 to 21
• Change line 104 COOLANT_MIST_PIN from 3 to 23
• Change line 110 RESET_PIN from 16 to 0
• Change line 111 FEED_HOLD_PIN from 13 to 1
• Change line 112 CYCLE_START_PIN from 14 to 29
• Comment out or delete lines 113-115. There are simply no more GPIO pins available to support a SAFETY_DOOR_PIN input.
• Add GPIO24 as an AUX relay or whatever the next most important output is.

I would make and test these changes myself but currently I only know to generate grblHAL firmware via the Web Builder. I am going to get started now on learning how to rip the training wheels off, and if I manage to make & test these changes before anyone else I will report back.

[cstaton-ftlg]

I have figured out how to compile firmware independent of the web builder and I am currently testing the modifications I mentioned.

[cstaton-ftlg]

Hello,
I have finished testing changes, seems like everything works, and my modified btt_skr_pico_10_map.h file is attached. I ran into a couple of other issues and "fixed" what I could but I am not fluent in C and never used this IDE.

Issue1: This board has to be 4 axis; pins 13-15 can't be used for anything but the 4th axis, and I didn't see any way in my_machine.h or btt_skr_pico_10_map.h to set it to 4 axis, so I made this change in grbl/config.h:

Issue2: When the board is configured as 4 axis, the "Invert stepper enable pins" shown in ioSender is correct for XYZ but not A. I addressed this with another change to grbl/config.h:

Issue3: Whether using firmware generated by web builder or complied by myself, the trinamic driver option in ioSender ($338) is not selected for any of the axes. I can turn it on by sending $338=15 but I wanted to address it before it gets to the board. I was unsuccessful. This is what I tried:
(in driver_opts.h):

(in btt_skr_pico_10_map.h):

I'm not sure where the problem is. I will just add $338=15 to my post processor for now.

updates.zip

[terjeio]

If lines 22 & 23 were deleted (I assume) this would enable the use of the 4th driver, while "giving up" those 3 signals which really aren't available anyway, so all gain and no loss.

Do not delete these - they are there to fail compilation if more than 4 axes (or 4 motors, see below) is configured.

Lines 110-115 will by default of N_ABC_MOTORS ==0, assign RESET_PIN, FEED_HOLD_PIN, CYCLE_START_PIN, AND SAFETY_DOOR_PIN to GPIO pins 16, 13,14, and 15 respectively, however it is not possible to physically use pins 13, 14, and 15 for those signals, because they are routed on the PCB directly to the 4th Trinamic driver (extruder DIR, STEP, EN) with no jumpers or other means of repurposing.

Ok, I did not know that as I do not have a board at hand.

In summary, my (maybe misguided) suggestions are:

Comment out or delete lines 22-24, 58, 64, 107, and 117

Don't do that, see above.

Uncomment lines 100-105
Change line 103 COOLANT_FLOOD_PIN from 2 to 21
Change line 104 COOLANT_MIST_PIN from 3 to 23

Ok.

Change line 110 RESET_PIN from 16 to 0
Change line 111 FEED_HOLD_PIN from 13 to 1

Surround the lines with #if !MODBUS_ENABLE ... #endif

Change line 112 CYCLE_START_PIN from 14 to 29

Comment out or delete lines 113-115. There are simply no more GPIO pins available to support a SAFETY_DOOR_PIN input.

Pin 16 (M3 limit) can be used in a 3 axis configuration.

Add GPIO24 as an AUX relay or whatever the next most important output is.

Ok.

Issue1: This board has to be 4 axis; pins 13-15 can't be used for anything but the 4th axis, and I didn't see any way in my_machine.h or btt_skr_pico_10_map.h to set it to 4 axis, so I made this change in grbl/config.h:

The configuration for four axes is indeed in grbl/config.h and should not be changed unless configured for four axes. The fourth motor (M3) can also be configured to be used for a ganged/autosquared axis in my_machine.h and if so N_AXIS should be left at 3.

Issue2: When the board is configured as 4 axis, the "Invert stepper enable pins" shown in ioSender is correct for XYZ but not A. I addressed this with another change to grbl/config.h:

The default should be #define DEFAULT_ENABLE_SIGNALS_INVERT_MASK AXES_BITMASK, I'll fix this in the next commit.

Issue3: Whether using firmware generated by web builder or complied by myself, the trinamic driver option in ioSender ($338) is not selected for any of the axes. I can turn it on by sending $338=15 but I wanted to address it before it gets to the board. I was unsuccessful. This is what I tried:

Do not change this file. The TRINAMIC_MOTOR_ENABLE symbol is used for an I2C interface I made to configure the drivers.

I'm not sure where the problem is. I will just add $338=15 to my post processor for now.

The correct way to do this is to add #define TRINAMIC_MIXED_DRIVERS 0 to the board map, I forgot to do that. This will disable/remove the $338 setting.

[cstaton-ftlg]

Do not delete these - they are there to fail compilation if more than 4 axes (or 4 motors, see below) is configured

I realized that as I dug deeper into it and did not change it.

Ok, I did not know that as I do not have a board at hand.

I assumed that you did not, so I provided my observation. I have read enough of your comments to understand that you are flying blind for most of this and I wish I had the skills to provide real help, because just pointing things out feels too much like complaining or criticizing and this is something I absolutely don't wish to criticize or complain about.

Surround the lines with #if !MODBUS_ENABLE ... #endif

ok

The configuration for four axes is indeed in grbl/config.h and should not be changed unless configured for four axes

ok, cool I did something right!

The default should be #define DEFAULT_ENABLE_SIGNALS_INVERT_MASK AXES_BITMASK, I'll fix this in the next commit.

Ok thank you

Do not change this file. The TRINAMIC_MOTOR_ENABLE symbol is used for an I2C interface I made to configure the drivers.

ok

The correct way to do this is to add #define TRINAMIC_MIXED_DRIVERS 0 to the board map, I forgot to do that. This will disable/remove the $338 setting

I actually did that (I tried more things than I could remember when posting), and it didn't work. I tried setting it to 0 and to 1, neither made a difference. Since TRINAMIC_ENABLE is already set in the board map, then I think TRINAMIC_MIXED_DRIVERS should be set automatically in driver.h, but (conjecture warning) it seems like driver.h is being examined earlier in the compile sequence than the board map.

[terjeio]

Since TRINAMIC_ENABLE is already set in the board map, then I think TRINAMIC_MIXED_DRIVERS should be set automatically in driver.h

It is but it is set to 1 if not defined in the board map, you want it set to 0.

it seems like driver.h is being examined earlier in the compile sequence than the board map.

The board maps are included in driver.h so kind of becomes a part if it.

IMO the Reset (or E-stop) pin should get priority over Cycle start/Feed hold.

[cstaton-ftlg]

Since TRINAMIC_ENABLE is already set in the board map, then I think TRINAMIC_MIXED_DRIVERS should be set automatically in driver.h

It is but it is set to 1 if not defined in the board map, you want it set to 0.

it seems like driver.h is being examined earlier in the compile sequence than the board map.

The board maps are included in driver.h so kind of becomes a part if it.

Ok, you were right of course. When I put #define TRINAMIC_MIXED_DRIVERS 0 into the board map, the 338 parameter is no longer shown in ioSender or in response to $$ sent over terminal, and I suspect that is why I thought it didn't work. I was expecting to see 4 boxes ticked by default (as in the case of enable signal invert), so I probably said to myself "great, now the option has disappeared entirely; that obviously wasn't the right solution."

IMO the Reset (or E-stop) pin should get priority over Cycle start/Feed hold.

Agreed. I don't need any of those signals so I am leaving it as is, but others will probably want it that way.

[brandonsherring]

Just got my btt pico in today trying to get it to compile from your update and can't figure out how to compile it. Will keep looking at it, if you have any pointers or instructions on vs that would be helpful

[terjeio]

Just got my btt pico in today trying to get it to compile from your update and can't figure out how to compile it.

Use the Web Builder?