Pico 2/RP2350 Support?

[phil-barrett]

This is a nice evolution of the RP2040. Adds FPU and more PIOs. I'd be happy to help testing and update PicoCNC to support it.

[JosephRBiden]

I agree, but It would especially be nice to have support for the RP2350B variant, as this carries and extra 18 GPIO pins compared to the A model, and 2040, which would allow for more accessories, use in more machines, and/or allowing for a good 4 axis board, without using shift registers, which could allow for an even cheaper and smaller option.

[terjeio]

I'd be happy to help testing and update PicoCNC to support it.

The pinout of Pi Pico 2 is supposedly the same as the Pi Pico so my guess is that initially it will be a matter of compiling for it, perhaps with tweaking a few clocks to get timings right.

... It would especially be nice to have support for the RP2350B variant

If somebody comes up with board design(s) I'll add the code...

[phil-barrett]

Looking into the 2350 as we speak.

[phil-barrett]

Pico 2 doesn't seem to be available in the US yet. I have a couple on pre-order.

The RP2350B (80 pin package) has 48 GPIOs so we could skip the SRs and support 5 Axes with limits, I2C (inc strobe), SPI, 4 Aux in, 4 Aux out, 2 probes, Rx/Tx, ethernet, standard PWM spindle with a few pins left over. With the FPU, we could support spindle sync.

Now we get to the reality point. None of the RP2350 chips appear to be available yet - A (QFN60), B (QFN80) and RP2354 A or B (with 2MB flash) don't show up in the usual distis. Various sources say end of 2024 for all the chips but I suspect the 2350s will be sooner than that. I can't believe that the Pico 2 is delayed that long.

[JosephRBiden]

[JosephRBiden]

I asked them if the 2350Bs would be available, this is the response I got. Not very sure what the sample program is, but the form is the thing on the bottom of the page about the 2350s, or when you click "register interest" on their page...

[phil-barrett]

A bit more digging this morning. There are a number of products being sold (at least advertised) with the RP2350B on them. In particular, there is the PGA2350 carrier board that has the RP2350B on it. The image of the chip says it is an A2 stepping which implies some level of stability. I think the outfit (Pimoroni, UK) is fairly reputable so I bought a couple with DHL shipping. If they are really in stock, I should have them in my hand this coming week. Am laying out a test board for it. Won't sell this board as I don't trust the PGA2350 to have long availability but worth it to get some testing in before the RP2350B becomes widely available (especially to my CM in China).

[JosephRBiden]

Yea, I saw the same thing. I bought 4 of those on Friday, but they haven't shipped yet, I guess they don't ship out on weekends...

[phil-barrett]

Here's an initial pin mapping for the RP2350B. Note that it uses KiCAD global labels in an odd way. The purpose of that is to allow quick reorganization during design and make for an easy way to move from the PGA2350 board to the actual RP2350B when available for board manufacturing. Pin assignment has been done by groups to make general routing easier

I wasn't able to get to 4 aux input pins but think 3 will be sufficient. Not sure how I will condition them. The RP2350 GPIOs are 5V tolerant when the chip is running at 3.3V so maybe just an LPF? They appear to be Schmitt triggered.

Also, I wonder how useful individual Enables are for each axis. Would a single Enable for all be acceptable? I could gain back 4 pins.

[phil-barrett]

I haven't used it but my gut instinct says that for 2 SRs the performance will fall off. Right now, with 4 axes, I'm seeing about 230 kHz. To me, 200 kHz is kind of the lower bound for a good motion controller.

[phil-barrett]

By the way, the data sheet does not show how to use an LDO for DVDD in place of the SMPS. I'm guessing that you don't connect VREG_FB and VREG_LX. Not clear about VREG_PGND, probably connect to ground to prevent floating circuitry. I assume you do connect VREG_IN and VREG_AVDD to 3.3V (assuming that's what IOVDD is using).

[andrewmarles]

You can find a pretty detailed example of driving the 1.1V with an LDO here:

https://hardware.buspirate.com/rp2350

[phil-barrett]

Thanks. Their blog goes into some detail. Looks like VREG_AVDD and VREG_VIN are fed filtered 3.3V, the other 3 VREG pins are left unconnected (including VREG_PGND). The blog mentions that, initially, they didn't connect VREG_IN (and the board worked) but the RP people later said to connect it. The HW design guide really should have that info after their "scare tactics" on the inductor choice.

[phil-barrett]

By the way the Bus Pirate guys are using the 2350B on a version of the BP (BP 6). In the blog the designer goes on about how satisfying it was to get rid of their shift regs. Space was a bit tight for them. I chuckled over that because of the SR discussion we had.

[phil-barrett]

Quick update on the 2350B board. Design for the PGA2350 is done - it fits on a 2 layer board though I might move to 4 layer for cleaner power distribution. The current design uses a buck converter for 5V which I am not happy with. I'll probably use a buck for 3.3V and an LDO for 5V and 1.1V. There are a lot of potential users of 3.3V so I want that to be pretty robust. I have a revised pin out shown below. I may tweak it a bit going forward (moving the SPI and I2C pins around a bit to make for a simpler layout.

Here's the current board with the Ethernet adaptor and an (admittedly crude) PGA2350 model.

[terjeio]

Can aux in 0/1 be optionally used as a second UART port? For those who have a RS485 VFD that want to use a MPG.

[phil-barrett]

Not with this pin assignment. Aux 0/1 can be used for UART 0 but the the other UART pins are for UART 0 as well.

However, I think this is a good idea and worth doing. I might be able to swap some pins around. I'll need to make some changes to the HW to allow output (if I use aux in) or input (if aux out) on one of the pins.

[phil-barrett]

Update on progress.

RP2350s are still not available in China so I'm not in a big hurry. I'm still hearing end of the year. But, I've got a prototype board back based on the Pimoroni PGA2350 and it seems to work well with initial testing. 0-10V is rock solid linear. Other than one bodge wire (stupid mistake) it's pretty clean. No grblHAL for it yet, though. I will not be releasing this board, will move to the RP2350B chip.

It is very similar to the Teensy 4.1 board. It does not use shift registers.
Some quick specs:

• 5 axis - step dir, enable, limit
• 7 relay coil support with 5/12V selection
• 5V outputs for Flood, Mist, AuxOut, Spindle Enable, Vac/DC
• 3 digital outputs (AuxOut0-AuxOut2)
• 3 digital inputs (AuxIn0-AuxIn2) with LPF. 5V tolerant.
• Standard Grlb control inputs - Start, Hold, Estop/Halt, Door, Probe
• 2 UARTs, UART0 and UART1. UART1 Steals AuxIn2 and AuxOut2 via board level config.
• UART0 selectable for 3.3V or 5V.
• I2C Header with strobe and Halt pass through.
• SPI Header
• WizNet Ethernet Support
• Spindle support - Enable, Direction, 0-10V, PWM, experimenting with open collector for EN and Dir

I have removed some pin headers. It appears very few people are using them for Stepper Driver and VFD interface.

I am hoping that grblHAL on this board will support spindle sync to make it a good lathe board.

Pin Map:

[axxel]

I'm about to build a standard 3-axis table CNC machine and am looking for the best "driver" hardware option. It seems to me the most mature and reliable option would be the ESP32? But since I'm using the RP2040 for another project with my own firmware already, I'd prefer that one to spare me the dive into yet another SDK and platform in case I want to contribute down the road. Based on the "stars" in github, RP2040 seems actually more popular, too.

Questions:

1. is there a clear advantage of one over the other?
2. does the arrival of the RP2350 on the scene change that picture significantly, considering the FPU unit and the higher clock speed?
3. what is the current status of the RP2350 support?

(Disclaimer: If this is considered off topic in this discussion, I'll start a new one)

[terjeio]

is there a clear advantage of one over the other?

For the end user likely no.
For a developer yes, for now SDK updates from Raspberry Pi is has been backwards compatible, updates from Espressif not necessarily so sometimes causing a lot of trouble. Debug support for the Pico is excellent, for the ESP32 not so. Espressif also forces one to use FreeRTOS which, IMO, adds overhead and complexity.

does the arrival of the RP2350 on the scene change that picture significantly, considering the FPU unit and the higher clock speed?

I think so, not only by having a FPU but also more PIOs, and the B variant having significantly more GPIO pins.
In practical terms this means the RP2350/54 can be more easily extended with optional features such as ethernet, spindle sync, step injection (for plasma THC and stepper driven spindle), general I/O (digital and analog) etc. The FPU also allows for more headroom to tune for faster laser raster engraving where lots of small movements are commanded.

what is the current status of the RP2350 support?

Nearly complete compared to the RP2040 since the driver codebase has been updated to support both the RP2340 and the RP2350/54. Only RTC (real time clock) support is missing for the latter for now, causing files uploaded to a SD card to not be time stamped. And currently step pulse timing is a bit off for the RP2350/54, I have a pending commit that will fix that and add some other improvements for both.

Are there "official" max step rates to be found somewhere for the ESP, RP2040 and RP2350?

These are somewhat hard to determine since many factors affect them: interrupt latency, FPU availablility/speed, planner buffer size, number of axes enabled and moving, ... There is a hard lower limit though, mainly determined by interrupt latency and how long it takes to output steps from the steps (segment) buffer. Using RP PIO or ESP32 RMT for step generation removes one interrupt latency/interrupt processing time from the equation allowing for higher step rates compared to what is possible with other processors/configurations.

[phil-barrett]

RP235x update. I have received a batch of beta build V0.92 RP2350B boards. So far in my testing, it works pretty well. One thing to change is the LDO for 5V from 12V. With the ethernet module, it gets a bit too hot for my liking. Have replaced that with a buck converter. For more detail, check out my RP23CNC github repo for it. I will be sending boards to beta testers in the next few days. If you are interested in beta testing the board, contact me on the discussions section of the RP23CNC github repo. I have a small number of boards available.

[axxel]

Thanks for background info! After lots of delays my machine is now finally actually moving. I went with a Pico/RP2040 I still had and basically a bread board. Very simple setup. I still have not come around to touch the code, yet. But just stumbled upon the news about the RP2040 now supporting 200MHz via a simple #define SYS_CLK_MHZ=200. I was wondering whether any of you have given this a shot, yet?

[terjeio]

I was wondering whether any of you have given this a shot, yet?

I just tried and gave up for now - VSCode will not create the necessary build files when switching board from Pico2 W to Pico W or Pico so building does not even start.

[terjeio]

Got it working, a small typo was the cause - and the error I got was completely unrelated.
I had to change some code to get step timing correct, this will be in the next commit along with max frequency (200 MHz) automatically selected if building with SDK >= 2.1.1.

By changing the min. step pulse allowed temporarily to 1 microsecond I managed to push the max step rate to 400KHz for single axis straight moves:

[phil-barrett]

That was with an RP2040 at 200 MHz? Wow.

This makes me bring up a previous discussion point. Should the overall grblHAL 2 uS pulse limit be lowered? And, should the default of 10 uS also be lowered? I know the previous response has been to avoid making it possible for people to screw themselves. However, I think you can't really idiot proof this because idiots can be quite determined. I propose we have a 1 uS lower limit and a 2 uS default. Add a stern warning about lower than 2 uS. Even the cheapest drivers I am aware of handle 2 uS just fine.

[terjeio]

Should the overall grblHAL 2 uS pulse limit be lowered?

If so it has to be driver specific because most cannot go much below 2 uS due to interrupt latency. The RP2040/2350 and ESP32 (with RMT generated step pulses) are the only ones that does not use a second interrupt for turning off the step pulses - it is done without processor intervention.

And, should the default of 10 uS also be lowered?

This should be less problematic.

[phil-barrett]

Fair point though doesn't the iMXRT1062 also allow shorter pulses? I recall someone (Jim Fong?) testing a custom build down to about 1 uS.

And, should the default of 10 uS also be lowered?

This should be less problematic.

Definitely the more beneficial one. 10 uS limits to around 80 kHz.

[axxel]

Interesting subject. I was curious what my DM542 have to say. I actually could not find proper information about this from the vendor I got them from (ACT Motors) but the 'original' (Leadshine) datasheet says 2.5µs minimal pulse length at max 200kHZ.

If I understand correctly, the default can currently not be changed via the webbuilder, right?

[phil-barrett]

It's a Grbl Setting - $0. Default is set in the code.

I'm pretty sure those are ultra conservative specs - most can handle much faster.

[terjeio]

Fair point though doesn't the iMXRT1062 also allow shorter pulses?

True, it is the only one I have tested, some years ago now, that had sub microsecond interrupt latency.

[phil-barrett]

By the way, I am moving my RP235x discussions to the RP2040 driver repo. Probably doesn't belong in grblHAL/Core.

I have updates on the RP2350B beta boards there.