RP2040 Breakout Board

[phil-barrett]

Starting Pico breakout discussion here, as requested. The goal is a breakout board that can be manufactured with all the surface mount components. Final assembly with through-hole components is up to the end user. This is what I mean by unkit. I will give free ones to those participating in the development of the RP2040 port. I will sell any left overs on Tindie.

Suggested Specs: (please suggest any additions)

• 4 Axis
• 5V step/dir/en output.
• 2 step enables (one for Z, one for XYA)
• 12V opto isolated limits and control signals
• Flood and Mist outputs
• I2C header+strobe
• I2C I/O expander - asking for discussion/consensus on specific expander (see below).
• 3.3V UART header
• 0-10V spindle. 5V enable, direction, PWM
• Power inputs: +5V, USB 5V, I/O +12V, Spindle group +12V
• Power LEDs
• 5V ("TTL") Aux outputs routed from some left over I/O expander pins.
• size: approx 100x100 mm

Not on board: (but again, open to discussion)

• isolated spindle group
• Stepstick sockets (see discussion below)
• SPI (but see discussion below)
• no relay drivers
• Aux inputs

I/O Expander choice. First question is 8 vs 16. A number of people like the idea of 16 for flexibility. See below for discussion of pin count - 16 may be necessary. I have been prototyping with the PCA9555 (16 GPIO expander) and it works fairly well. Access times are not bad but also not trivial. I have not characterized the performance in grblHAL but would be surprised if it is less than 120 uS. The special case of reading the first I/O bank (port 0) is often fast(er) (2 8-bit I2C messages) in most 16-bit expanders.

I know Terje likes the PCA9654E but that isn't available from my board vendor (JLCPCB). For 8 bit expanders - the NXP PCA9554 looks good. For 16 bit, I like the NXP PCA9535 (same pinout and command set as the PCA9555). I am currently leaning towards the 16 bit chip.

Stepsticks/SPI. If there are enough pins to allow SPI, I would like to create a header that would allow a separate Stepstick board to connect to the BOB. I am also looking into the use of a few extra I/O expander pins for configuration and error signals.

SD Card. Will there be a free CS pin for this? Has to be on the Pico, not the expander.

I/O pins needed
Steppers: 10 - 8 step/dir + 2 enables
Limits: 4
Controls: 5 (cs, fh, probe, door, reset)
Coolant: 2 (flood and mist)
Spindle: 3 (pwm, en, dir)
SPI: 5 to support both Stepsticks and SD card
UART: 2
I2C/Strobe: 3

Total: 34
So, I believe there are 22 pins available on the Pico (pin 23 is not usable?). That leaves 12 that need to be on the I/O expander. Can we find 12 pins that will work on the expander? SPI is the biggest issue here at 5 pins (4 if no SD card). I would love to support it - not sure it is possible.

I think that is enough for now. Would like to hear what people think.

Since GPIO is on one 32 bit wide port I see no reason to stick to the generic map if moving pins will make routing simpler. The limitations are that UART, I2C and SPI ports are only available on some and step outputs has to be on consecutive pins.

I'll make a simple "unkit" board (with all the glue logic, optos and such) based on that and get a bunch made up.

Which features will it have? I2C io-expander? EEPROM or FRAM? SPI port for SD-card? ...

FYI I have HAL'ified my MPG & DRO, written driver code for RP2040 and made a prototype PCB. It still has a MSP430 for keypad/LED control but to make it simpler for possible end users I want to program it from the RP2040 with a precompiled blob...

I will start a separate discussion entry on this if people think the timing is good.

Best to do that at the new repo?

[Volksolive]

IMO, directly connected to Pico:

• 4 step (pin 2-5)
• 4 dir (pin 6-9)
• 3 i2c (pin 20-22)
• 2 uart (pin 0-1)
• 4 spi (pin 16-19)
• 4 limit (pin 10-13)
• 1 PWM (pin 28)
• 4 control (pin 14, 15, 26, 27) Reset, FH, Probe, Door, Cycle start is IMO less time critical
  = 26 pins (pico is full)
  the mapping doesn't have to be as described here but step pins must be contiguous pins and COMMS have limited pins where they can be attributed.

I think SD card is possible if the SPI CSs are on IO expander and ORed to pin 17 of the Pico to start SPI comm when CS is asserted. Of course in that case the CS pin need to be set has input not actual SPI CS output. The idea is that I2C assert the CS pin needed on the IO expander and when the IO expander actually assert the CS pin, that create a IRQ on the pico that can then start the SPI comm after a slight delay. then when SPI comm is done the I2C deassert the CS.

On IO Expander :

• 2 out stepper EN
• 2 out coolant
• 1 out Spindle EN
• 1 out Spindle DIR
• 2 out CS which are ORed back to pico pin 17
• 1 in Cycle Start
• 7 out aux ?
  = 16 pins

[fireup924]

Wouldn't it be easier to use something like the MPG/DRO boosterPack that Terjeio as made, think I have seen somewhere that he also ported (or is in the process) the code to the Pico.

I like this route as well if adding Host Mode to grblHAL will make it too complicated.

[terjeio]

@Volksolive That was fast - should I make a branch for testing/review? Did you create a new map file for testing this? IMO generic_map should be usable with no external parts for inputs and outputs other than conditioning (buffers, level shifters, optocouplers...).

Yes, I have HALified the MPG/DRO BoosterPack code and made a driver and prototype board for the Pico. The USB port is not used so host mode for a USB stick and/or pendant is possible to add. Perhaps better to use an ESP32 (or similar) instead of a Pico and add a Bluetooth module to the grblHAL side for a wireless connection? Or add a Bluetooth module on both sides?

[Volksolive]

should I make a branch for testing/review?

Yes, that would be nice to continue exploring/testing.

Did you create a new map file for testing this?

No I only created the PIO code on a separate project just to be sure that could work.
I haven't yet done the function that will update step EN signal when no steps are generated but this should be pretty easy to do. I believe the stepper enable/disable happen before/after the stepper ISR is enabled/disabled, so there should be no data corruption, can you confirm @terjeio? otherwise some precaution will be needed like disabling the stepper ISR while changing EN state.

IMO generic_map should be usable with no external parts

I think that too, the // or serial PIO program should be initialized based on the configuration during runtime or at compile time?
I haven't check yet how you manage a different mapping in code, anything I should be aware of?

I have given a second thought on having both step/dir/en and outputs signal on the same HCT595 chains, I think it could be done.
The outputs signal would be shifted in 2 occasions: during a step shift or when there is no step to shift.
The function that would take care of the outputs signal should check if there is steps in the step buffer and in this case just keep the variable that stores the outputs state updated in an atomically fashion so there would be no data corruption between foreground and ISR (but writing a 32 bit variable is atomic I believe), then when steps are shifted the updated output would be shifted too.
In case there is no step in the step buffer, the function should add the state of the dir? and EN to the outputs signal and send this to the pio FIFO to get it shifted, probably this should be done with the step ISR deactivated and reactivated right after.

But even though it seems it could work that way, I think it is still better to do it with the SPI because then it is very easy for the SPI to know when the CS pins are asserted (considering that asserting a CS pin would be done by a first SPI transfer to the SR) whereas with the steps it is depending on step rate (slow step rate increase the output update rate).

[terjeio]

A test branch has now been created.

I believe the stepper enable/disable happen before/after the stepper ISR is enabled/disabled, so there should be no data corruption

Correct, and there is a delay on both ends of a motion.

I haven't check yet how you manage a different mapping in code, anything I should be aware of?

It is selected by a #define in my_machine.h and the map file is included in driver.h.

I have given a second thought on having both step/dir/en and outputs signal on the same HCT595 chains, I think it could be done.

I think so too. Output signals are most likely to be changed when there is no motion, and if not I don't think it will be a problem if delayed until the next step is output. A pity that bitbanding is not supported by M0 processors - that would have made bit writes to a 32bit variable atomic.

Which frequency do you use to shift data? Is it possible to shift in 24 bits in 500ns or less?

[Volksolive]

A pity that bitbanding is not supported by M0 processors - that would have made bit writes to a 32bit variable atomic.

There is 3 alias registers for each registers of the RP2040 so bitmask set, bitmask clear and bitmask XOR can be done atomically. So we could use an unused register (for example DMA destination or source address register) as a 32 bit variable. Not something really conventional but it could work just fine.

Which frequency do you use to shift data? Is it possible to shift in 24 bits in 500ns or less?

Looking at the HCT595 datasheet it seems that an acceptable frequency should be around 24Mhz, that would means dividing the 125Mhz main clock by 3 which would give 41.6Mhz for the PIO and a bit shift twice as slow (shift clock every 2 PIO clock) thus a 20.8Mhz frequency and a 24 bits shift would be 1,152 us. However if the PIO uses the main clock undivided, that would give a 24 bits shift of 384ns.

[terjeio]

There is 3 alias registers for each registers of the RP2040 so bitmask set, bitmask clear and bitmask XOR can be done atomically. So we could use an unused register (for example DMA destination or source address register) as a 32 bit variable. Not something really conventional but it could work just fine.

A bit dangerous to do this if code is added later that needs the register for its intended use?

Looking at the HCT595 datasheet it seems that an acceptable frequency should be around 24Mhz,

My datasheet (Nexperia) has fmax (min) at 130MHz with Vcc 4.5 - 5.5V and 170MHz typical @ 25C. Careful layout is needed to achieve this speed?

[Volksolive]

Do you think it could be possible to add a 5V LDO to generate the 5V from the 12V. I believe the 5V is just for logic signal and not power signal, so something rather small like 500mA would suffice I guess. Just the footprint so that people can decide if they want to use an external 5V or solder an onboard one. In my case, I wouldn't have to add an external 5V step down in my casing. Maybe a good spot to place it, if space allows, would be underneath the Pico.

[Volksolive]

My code for the PIO:

; step serial program shift out step, dir for 4 Axes
.program step_shift
.side_set 2

.wrap_target ; Autopull from the FIFO, block execution is the FIFO is empty
set x 7 side 0 ; Set scratch register X to number of bit to shift minus 1
shift:
out pins, 1 side 0 ; Shift one bit from the OSR register to the data pin and reset the clock pin
jmp x-- shift side 1 ; Jump to the previous instruction as long as there is bit to shift and set the clock pin
out x, 8 side 2 [1] ; Put the remaining content of the OSR register in the X register, reset the clock pin and set the STCP pin
tempo:
jmp x-- tempo side 0 [3] ; Jump as long as the X register is not empty , each jump takes ~= 0.1 us (1 instruction + 3 delay * 3 clock divider * 8ns clock = 96 ns)
.wrap

% c-sdk {
static inline void step_shift_program_init(PIO pio, uint sm, uint offset, uint8_t dataPin, uint8_t clockPin) {
pio_sm_config c = step_pulse_program_get_default_config(offset);

// Map the state machine's OUT pin group to the provided data pin in parameters
sm_config_set_out_pins(&c, dataPin, 1);
// Map the state machine's SIDESET pin group to the provided clock pin in parameters
sm_config_set_sideset_pins(&c, clockPin);
sm_config_set_sideset(&c, 2, false, false);
// Set these pins GPIO function (connect PIO to the pad)
pio_gpio_init(pio, dataPin);
pio_gpio_init(pio, clockPin);
pio_gpio_init(pio, clockPin+1);
// Set the pin direction to output at the PIO
pio_sm_set_consecutive_pindirs(pio, sm, dataPin, 1, true);
pio_sm_set_consecutive_pindirs(pio, sm, clockPin, 2, true);
// Activate autopull and set the threshold to 24 (8 bits timing, 6 bits step, 6 bits dir, 4 bits en)
sm_config_set_out_shift(&c, true, true, 24);
// Set the clock to approx 41.7Mhz
sm_config_set_clkdiv(&c, 3.0);
// Initialise the pio with the provided config
pio_sm_init(pio, sm, offset, &c);
// Set the state machine running
pio_sm_set_enabled(pio, sm, true);

}

This code shift 8 bit of data and then wait for 0.1 us (depends on clock setting for the PIO but can be adjusted accordingly to get approx 0,1us) * the 8 last bit of the OSR register.
to generate a step, the C code send 3 times 16 bits to the PIO FIFO, the first data contains the Dir state + the step default state + the dir to step delay (which can be 0 if no dir change), the second data contains Dir state + step state + pulse length delay and finally the third data contains the same data as the first one but without the delay.

here's the C code that prep these data:

// This function send the step data to the pio to shift out the data to the SR
static void stepperPulseShift(stepper_t *stepper)
{
    // The third data to be shifted contains the state of the enable pins, the dir pins and the default value of the step pins
    uint32_t thirdShift = pio_steps_shift.value ^ (stepper->dir_outbits.value << 4);
    // The second data to be shifted contains the same value as the third shift + the actual value of the step pins + a 8 bit pulse length
    uint32_t secondShift = thirdShift | pio_steps_shift.length ^ stepper->step_outbits.value;
    // The first data to be shifted contains the same value as the third shift + a 8 bit delay
    uint32_t firstShift = thirdShift | pio_steps_shift.delay;
    
    // Send the 3 shift step data to the pio
    pio_sm_put(pio0, 0, firstShift);
    pio_sm_put(pio0, 0, secondShift);
    pio_sm_put(pio0, 0, thirdShift);
}

The pio_steps_shift.value variable is set at the setting_change function and contains the default state for step and dir (meaning inverted or not inverted). the pio_steps_shift.length and pio_steps_shift.delay are the delays value (didn't set delay to 0 if dir don't change though but can be implemented quite easily).

[phil-barrett]

Do you think it could be possible to add a 5V LDO to generate the 5V from the 12V. I believe the 5V is just for logic signal and not power signal, so something rather small like 500mA would suffice I guess. Just the footprint so that people can decide if they want to use an external 5V or solder an onboard one. In my case, I wouldn't have to add an external 5V step down in my casing. Maybe a good spot to place it, if space allows, would be underneath the Pico.

Yes, it is possible but USB will always be connected . 5V is needed to drive the 595s and some off board optos. I'd need to add a few caps as well. Let me think on it a bit.

[phil-barrett]

I started a discussion in grblHAL/RP2040 about putting a voltage regulator on the board. Please add your thoughts and anything I missed. (I'd like to move the conversation as this discussion section will be depreciated at some point)

[phil-barrett]

I added the latest take on the BOB to grblHAL/RP2040 discussion. I believe it is time to do a first set of boards. If I don't hear any issues, will send them off tomorrow.

[texasranger556]

Interested in helping with this effort. I'm in the process of getting a 4x8' router retrofitted with g2core/due and closed loop steppers but interested to compare it with grblHAL on Teensy 4.1 (just ordered the BOB on Tindie today), and of course now I found this project using the Pico, of which i have a few sitting around. I'll be watching to see how this project progresses, let me know if you need beta testers or something.

[phil-barrett]

Where is the RP2040 development activity going on? Neither the grblHAL nor Core repositories have been updated in the last 3 weeks. Should I assume that core/RP2040 is the correct place?

I sent the T41 Pro BOB off for a test manufacturing run and have some time to work on the PicoBOB. Trying to figure out the best pin assignment. I will put 3 '595s on the board. Stay tuned, film at 11.

[phil-barrett]

I'm fine with moving the discussion, don't know how move this thread though.

[terjeio]

I'm fine with moving the discussion, don't know how move this thread though.

I do not know either but I believe it is possible. PIO code first!

[Volksolive]

Unfortunately, I am too busy recently to spend time on GRBLHal, however I already made the PIO code with the Driver but didn't had time since to test it ... So I can make a merge request if you want so that maybe somebody can test it? I know the PIO code works as I tested it on a separate program, but I haven't tested it within the GRBLHal driver code ...

[terjeio]

So I can make a merge request if you want so that maybe somebody can test it?

Since you have not integrated it into the grblHAL driver it would be faster to just add it as an attachment here?

[Volksolive]

Since you have not integrated it into the grblHAL driver it would be faster to just add it as an attachment here?

I did integrate it to grblHAL, so the PIO code + c functions to generate steps are there but I haven't had time to tried it

[terjeio]

WiFi network/WebUI support has now been added for Pi Pico W. Currently only station mode (STA) is working, access point (AP) mode is not yet ready.

The good thing is that no pins is lost to the radio interface!

[WaGitCad]

Is there any activity in this item?
I designed a PCB for picoW and 2 stepper driver EZ2209 in kiCad for another project. Since the stepper drivers are connected by serial communication, many IOs are free for other purposes. I just use the 3 analog inputs for sensors.
The communication with stepper drivers includes homing, absolute and relative movement, substeps till 256 for silent movement, diagnostic and so on. Is there any interest in the community?

[phil-barrett]

Currently, I'm selling a Pico based board here. There are also several from Expatria. Why don't you post links to yours?

[WaGitCad]

Hello Phil-Barrett,
Your Breakout board is amazing, congratulations for all the features, especially for using the pi pico, which I like very much.
I myself have no commercial interest, so I'm not selling anything. My breakout board is for a special project I'm working on, its a "Sun-Tracker" which measures the sun elevation and declination as precise as possible, by using the pico-W and two stepper driver EZ2209. Since now I designed all the mechanics, printed it with my 3D-printer and also the breakout board. Next step will be to design the software.
Zeichnung.pdf

Perhaps you can help a friend of mine, he searches a slicer for generating G-Code for his nc controlled [ANNOYTOOLS CNC-Fräsmaschine All-Metal 3018 2.0 PRO]
(https://www.amazon.de/dp/B0CJ27CLVH/ref=pe_27091401_487024491_TE_item)

[phil-barrett]

Looks like you are on your way. The EZ2209 looks like a repackaging of the StepStick format. It looks designed for better heat sink capability since it has 2 sides exposed to air. I like that mounts the driver vertically and saves board space. Does it require large capacitors? The old StepStick format does. I don't see them on your board.

Perhaps "slicer" is a translation error. In CNC routing and milling, you do not use a slicer but something called a CAM (computer aided manufacturing). It takes a CAD design and turns it into toolpaths and, ultimately, GCode. Fusion 360, FreeCAD, VCarve and others have CAM capability. There are stand alone CAMs as well - CAMBAM, Bobs CAM and others. Even some GCode Senders have limited CAM capability.

[WaGitCad]

Thank you for your advices. My english is not as good as I would wish.
Regarding capacitos I have 2 ceramic capacitors C6,C7 with footprint 1206 which allows capacities till 22uF, if there is too much ripple on the Power line, I would solder a second pair on top of them, resulting 88uF. EZ2209 designer promise a high pwm rate, which eases for lower capacitors.
Did you mention the supply possibilities of the pico W? If you supply it from onboard micro USB, then there is a switched mode step down converter to source the 3.3Volts on board. Supplying direct the 3.3 Volts from an external step down from the motor voltage is also able by disenable the on board stepper.