Klipper: Feature Request: Porting Klipper to the new STM32MP1 MPU series which has an integrated MCU?

[Gamester17]

Can I suggest that you port Klipper firmware to the new STM32MP1 MPUs which have an integrated MCU?
https://blog.st.com/stm32mp1-mpu-stm32mp157a-ev1-stm32mp157c-dk2/

I am only a technology enthusiast myself and I do not actually know if anyone else is already working on a 3D-printer controller board based on the new STM32MP1 MPU series or not, however reading about it I can not help think that it would fit perfect for 3D-printer controller boards as it combines a single very fast 32-bit Cortex-M4 MCU core @ 209MHz alongside one or two 32-bit Cortex-A7 MPU cores @ 650Mhz.

I read that STMicroelectronics claims that the MCU core in STM32MP1 architecture is backwards compatible so it enables developers to use the same software made for their STM32 MCU series (like example STM32F0 and STM32F1 that are common in 3D-printer controllers boards today), and theoretically, with the STM32MP1 MPU series which now have an integrated MCU core you could for example run both Klipper firmware as well a full Linux distribution like OctoPi with OctoPrint on the same board in a single chip package, keeping cost down and making it a uniformed platform running in only one single chip package (a.k.a. chiplet).

It should be noted though that even the fastest Dual Cortex-A model of STM32MP1 only run at 650MHz per MPU core and only supports up to 1GB of external RAM so that part is on paper maybe only twice as powerful as a Raspberry Pi Zero W, however when considering STM32MP1 integrates on an ARMv7 based Cortex-A7 instead of the older ARMv6 it should still be enough to enable users to run a full Linux distribution similar to OctoPi with OctoPrint smoothly on, and again the Klipper firmware would run on the integrated MCU core alone.

This request is kind of related to #470 but not quite as the STM32MP1 MPU series is a different beast!

For technical specification on summery on the new STM32MP1 MCU series checkout:
https://www.cnx-software.com/2019/02/21/stmicro-stm32mp1-cortex-a7-m4-mpu/

There are already a few developer boards and evaluation kit available for developers:

STM32MP157A-DK1 and STM32MP157C-DK2 Discovery kits are $99 with LCD or $69 without

• https://www.st.com/en/evaluation-tools/stm32mp157a-dk1.html
• https://www.st.com/en/evaluation-tools/stm32mp157c-dk2.html

STM32MP157A-EV1 Evaluation kit for PCB engineers does have a steeper price at $399

• https://www.st.com/en/evaluation-tools/stm32mp157a-ev1.html

PanGu board from I2Som

• https://www.cnx-software.com/2019/06/25/pangu-board-stm32mp1-sbc/

[klipper-gitissuebot]

Hi @Gamester17,

It did not look like there was a Klipper log file attached to this ticket. The log file has been engineered to answer common questions the Klipper developers have about the software and its environment (software version, hardware type, configuration, event timing, and hundreds of other questions).

Unfortunately, too many people have opened tickets without providing the log. That consumes developer time; time that would be better spent enhancing the software. If this ticket references an event that has occurred while running the software then the Klipper log must be attached to this ticket. Otherwise, this ticket will be automatically closed in a few days.

For information on obtaining the Klipper log file see: https://github.com/KevinOConnor/klipper/blob/master/docs/Contact.md

The log can still be attached to this ticket - just add a comment and attach the log to that comment.

Best regards,
~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.

[Gamester17]

Is it ok to submit a feature request here without a klippy.log file?

[FHeilmann]

Seing as this would be the first non-single-core processor I don't see how porting it would be possible without significant architecture changes to klippers MCU code (as it currently stands the code assumes a single core and cannot utilize multiple cores so it involves a ton of rewriting, while still requiring backwards compatibility to single-core MCUs). I misunderstood that part, apologies.

IMHO it's also overkill since the MCU part of klipper doesn't even come close to putting significant loads on the more up-to-date 32 Bit MCUs (like the ATSAM3/4 and SAMD21/51 series of chips). I.e. my Duet Wifi, based on the ATSAM4 rarely, if ever goes over 20% load on a quad-z, 1/32 microstepping, 400mm/s printer.

Running octopi on this board would be a significant step back as any raspberry pi (even a first generation or zero) will eclipse the klippy performance of this board, not to mention running octoprint and a full linux distribution alongside it.

[dragonnn]

Why significant changes?
Only thing with would be need is somehow simulating an UART communication between the A7 cores and the M4 core. They is no true multiple cores on MP1, only two cores for running Linux and one for running the MCU code. And that it have two cores for Linux isn't a problem since Pi have 4.
About octoprint, you can use Duet Web Control for Klipper with is much faster then octoprint.
I agree that the MCU M4 would be an overkill for Klipper but still it would be a nice option to have klipper integrated in one physical chip.

And simulating UART communication would be done only in the MCU code (and already other MCU on klipper are simulating UART over USB) and in a Linux kernel driver so no problem here. No significant changes need in klipper

[jannau]

The missing piece is the support for the IPC channel between the Cortex-A7 and M4. The concept would be similar to the already supported beaglebone/replicape hardware. I'd recommend the dual core cortex-a7 when running octoprint and klipper though. The single core Cortex-A8 (1 GHz) is not fast enough to print curvy without virtual sd card.

[Gamester17]

@FHeilmann this new STM32MP1 MPU does not contain multiple MCUs, it still only contains a single-core Cortex-M4 MCU which Klipper would run on. What it does is combine a single-core MCU with one or two MPU cores in a single chip package. And again, the MCU architecture on this new STM32MP1 MPU should be backwards compatible with software written for older STM32xx architecture, which is something that Klipper already is. That is. the Klipper firmware would run alone on the integrated Cortex-M4 MCU core and Linux with OctoPrint would run on the Cortex-A7 MPU cores.

In regards to it being overkill, modern Trinamic stepper drivers in their TMC21xx series already support up to 256 microsteps today and future stepper drivers might support even more microsteps, and you should also consider that both Delta and CoreXY style printers require more compute power than a Cartesian style printers, and there are also 3D printer designs with more stepper motors that your average simple printer. Recommend that you checkout this video => https://www.youtube.com/watch?v=729Xglg6hec it does a good job describing exactly why more a powerful 32-bit MCU is not overkill.

[FHeilmann]

@Gamester17 Sorry, I misunderstood that part.

However, that integrated MPU is still orders of magnitude weaker than the quad_core SoCs provided by raspberry-pis, so no matter whether you run duet web control or octoprint on it, it is going to run significantly slower.The video you linked talks about Marlin, which executes the entire path planning on the MCU itself. So while Marlin might struggle with 1/256 microstepping, even on a 32 bit board, that argument does not apply to klipper at all.

In the end having everything integrated on one board might be a nice idea, but you'd end up with significant software development and hardware development costs (since the board would have to essentially have to combine all the components of a linux machine and, at least, a massive breakout board for the Cortex-M4 so you can slap some sort of RAMPS-esque board on it) to get a system that is expensive, slower and more complex. It is due to this reason that the replicape was not really successful.

@dragonnn Given my misunderstanding of the first part, and yes, given a running linux distribution with a well-defined interface to the Cortex-M4 the changes to klipper would be minimal, there is still some work required to get a Linux distribution up and running that supports all dependencies of klipper.

[Gamester17]

@FHeilmann yes it is correct that the STM32MP1 MPU cores would not make the board as powerful as even a Raspberry Pi 2 Model B, but as do they really have to be just run a minimal Linux distro similar to OctoPi that only runs OctoPrint and Klipper dependencies?

At least on paper, it should be powerful enough for that as some people already run OctoPrint on Raspberry Pi Zero W today and based on the specification of an STM32MP1 with Dual-Core Cortex-A7 should make such an STM32MP1 based board have about twice the compute power of a Raspberry Pi Zero W.

Please understand cannot compare MHz against MHz. Fact is that the more modern ARMv7 CPU instruction set used by cores with ARM Cortex-A7 architecture in these STM32MP1 MPUs means that they can do more calculations per Hz clock cycle than the older ARMv6 CPU instruction set that is used by the ARM11 core in Raspberry Pi Zero W, and thus the each MPU core in STM32MP1 has more computing power per MHz.

And again, relatively inexpensive developer boards for the STM32MP1 is already available to buy.

STM32MP157A-DK1 and STM32MP157C-DK2 Discovery kits are only $99 with an LCD or $69 without

• https://www.st.com/en/evaluation-tools/stm32mp157a-dk1.html
• https://www.st.com/en/evaluation-tools/stm32mp157c-dk2.html

STM32MP157A-EV1 Evaluation kit for PCB engineers and developers does have a steeper price at $399

• https://www.st.com/en/evaluation-tools/stm32mp157a-ev1.html

PanGu board from I2Som is about $80 from China if you only buy one but their price can be negotiable

• https://www.cnx-software.com/2019/06/25/pangu-board-stm32mp1-sbc/

[FHeilmann]

Klipper recommends a pi 2b at the very least to cover the increased performance requirements of a octoprint+klipper setup over a octoprint+marlin setup.

While I agree the SoC in this would probably be faster than a pi zero (assuming your load is sufficiently parallelizeable), a Pi2 v1.2 uses 4x1 Ghz Cortex-A53 (which is newer and faster than the Cortex-A7), so this board will be significantly slower than the recommended minimum for klipper.

The cheapest option you list (69$ for just the evaluation board) only has an rpi compatible GPIO header (27 usable input/output pins which is not a lot once you remove step/dir/enable/uart for each stepper). On top of that you'd still need a hat of sorts to actually mount the stepper drivers. Compare this to the 35 bucks for an rpi3 (which will be more powerful) and a 32-bit board such as the SKR 1.3 for about 20 bucks and you're already undercutting the price for the evaluation board alone.

I am not saying it can't be done or that it won't run at all. But since you already lectured me on 1/256 microstepping and corexy printers I expect this board to not be up to the task. You posted this as a feature request so you're looking for someone to do the porting work. I merely offered my input on why I think this port is not worthwhile. Both financially and performance-wise there are many more attactive solutions, albeit with a larger footprint because two separate boards are needed.

That said I'll leave this up to the other contributors here and stop being a debbie downer.

Good luck,

Florian

[dragonnn]

The performance problem is Octoprint, Klipper alone can easily run on something much slower.
I am pretty sure that Klipper + DWC or Klipper using virtual sd card will run easily on 2xCortex A7.

[Maglin]

BTW actual speed or MHz does matter here. The MCU is either running a sudo (puns) RTOS type of FW or actual RTOS FW and the OS/python/klipper (non-RTOS) has to be able to supply the data to the MCU fast enough along with precision and timing needed. This requires clock cycles. This is also why faster MCU's can achieve much higher step rates. It's not that it's 32bit. It's the actual speed of the MCU. More work/compute per cycle helps but it can't do say a floating point calc and output in the same clock cycle.

But to the OP request. This is a lot of work for something that isn't currently in use on any controller. (correct me if I'm wrong there) These requests like this are always from someone that isn't a programmer. I'm not a programmer but I understand the sheer amount of time involved (not to mention the high and low-level knowledge needed). The documentation says it's an easy port from older MCU's. Well, we've been down that road before. Only took about 200 hours worth of work to get something like the SAM4E ported over. And that is a rough guess. It might have been more. You've already talked to that guy. We will see what the future holds.

[Gamester17]

@FHeilmann I think you misunderstood my OCD-brain's thoughts behind this feature request as I did not mean to suggest that using a board based STM32MP1 would make economic sense when building DIY 3D-printers as a recommendation to save you money on a one-off DIY 3D-printer today. What I meant to suggest was instead that using a board based STM32MP1 could make financial sense for a commercial company who wants to create a cheap all-in-one board to mass-produce and sell as an all-in-one board for other companies that make 3D-printers in the future.

That is, I, of course, know that and understand that buying existing STM32MP1 based developer board makes no sense for someone wanting to build a one-off DIY 3D-printer today. Of course, it is today cheaper for you as an individual to just buy a Raspberry Pi and one of the existing 32-bit board from China.

And no, I have personally no commercial interest in this myself nor do I know or am I affiliated with anyone who would have a commercial interest in this. Again I am just a technology enthusiast who just happened to read about it and thought it sounded like a very cool idea and indecently thought that I could just post it is a feature request to throw the idea out there, cause perhaps someone with a commercial interest could make such a board and make 3D-printers even more accessible which would benefit the whole community regardless who if any makes money of idea. That is just an idea that could save that companies money compared to integrated a full Raspberry Pi into their commercial printers.

In the end, the whole 3D-printing community have benefited from companies like Anet and Creality manufacturing cheap printers in China which is faster than at least I expected making 3D-printing into a hobby that almost anyone can afford. More competition means more innovation and lower prices for us consumers. Therefore I am sure that if cheaper 3D-printer controller boards with more integrated features like OctoPrint would also be commercially manufactured and eventually cloned by Chinese companies that the whole 3D-printing community would benefit from that too.

That said, I to will bow out from this discussion now and leave this as an idea for Klipper developers.

[Maglin]

@Gamester17 What a minute. So someone in this community should invest call it 200 hours of there time and $70 of their own money to create a Klipper port so that some commercial company would make a controller board and be able to save R&D money by just using Klipper? In what world does that make any sense? I don't think that makes sense even in a flat world.

[KevinOConnor]

FWIW, it's fine if someone wishes to port Klipper to the given chip. (If interested, start with https://www.klipper3d.org/Code_Overview.html ). If I understand this thread correctly, it would require installing Linux on the main CPU and then porting the micro-controller code to the on-chip cortex-m4 micro-controller - similar to the way the beaglebone/pru code works today in Klipper.

-Kevin

[JustAnother1]

It seems I'm late to the party. But I saw some misunderstandings in the discussion and maybe I can help clear things up.

Another disclaimer: I'm a software developer but not an Klipper contributor.

For a commercial company using this chip is probably cheaper than to use a PasberryPi + something else solution. The reasons for that start with being able to have a single board solution and go in pricing of chips once you buy them in the thousands.

On that point the AVR chips are ridiculously expensive compared to ARM Cortex-M chips. If you look at prices for just the chip, and that is what you would do if you manufacture the chips.

The performance has two sides. The Cortex-M4@200MHz is a beast compared to the other supported chips. So the real time part would have all the performance it needs for 1/156 micro stepping, more axis, and so on. The other side the Linux part is less than the newest Raspi. The question is if that matters. And that depends on what you do. Octoprint supports slicing, time-laps video capture of the print, video streaming during print,.. The Duet LAN is much less powerful and runs on a Cortex-M chip that has less performance than the cortex-M part of this chip. So performance wise this solution will be better than duet but not as powerful as Octoprint on Raspi. That is probably good enough for many users.

As far as I know ST provides a Linux for the Chip. There are also solder on boards. That solder on board contains the complex PC type stuff and allows for a rather simple carrier board.

Then regarding the effort: @Maglin please look at how the Arduino, RAMPs and other boards came to be. They started off as open source board, either by enthusiast or by companies(Arduino). But nowadays everybody seems to buy the cheap boards from China. For an enthusiast that never planed on making money from it that is fine and it allows more people to enjoy 3d printing. For a company that is an issue, so maybe think about buying the original Arduino board instead of the cheap Chinese so that the additional cost you pay can be used to refinance the development cost.

At least here on the dk1 and the $400 board seems to be available. This chip is rather new and the dev boards are just yet becoming available. I'm waiting for a good board to be available myself. I would love to work on the chip. The porting will be quite an effort, but there are some motivated people in the community. So it might happen. But right now what needs to happen first is to get a 3dprinting board available that uses this chip. That is also not firmware dependent, so even a Marlin fan could work an creating such a board.

An interesting and new solution could be if someone could convince a Chinese company to slap together a 3dprinting board that used the ST chip and just make it available, even without the software. Then interested software developers like myself could get such a board and start porting all kinds of stuff to it. Once Stuff like Klipper and Marlin are ported and working the sales for the board would go up.

I hope I could clear things up. Best luck for all of us. Maybe someone starts doing something and helps all of us.

[KevinOConnor]

I'm going to close this issue as it looks like the conversation has concluded. If someone is interested in porting to the given chip then that's great.

-Kevin