Porting Marlin to STM32.

What are you developing?
Posts: 1864
Joined: Mon Apr 27, 2015 12:12 pm

Re: Porting Marlin to STM32.

Post by victor_pv » Fri Jul 07, 2017 11:29 pm

I just uploaded my libmaple port to github, and linked it in the first post.

Posts: 336
Joined: Thu Sep 01, 2016 8:52 pm
Location: Hungary

Re: Porting Marlin to STM32.

Post by danieleff » Sat Jul 08, 2017 4:38 am

Why is it not a fork, but a new repo?

Posts: 1864
Joined: Mon Apr 27, 2015 12:12 pm

Re: Porting Marlin to STM32.

Post by victor_pv » Sat Jul 08, 2017 1:43 pm

danieleff wrote:
Sat Jul 08, 2017 4:38 am
Why is it not a fork, but a new repo?
Hmmm, there isn't any specific reason. Once the Marlin main devs merge their HAL layer to the Main, this will be submitted as just a new folder in their HAL subfolder. At that point it will not exist as either branch of fork, just part of the master Marlin.
In the meanwhile I just uploaded it in case any wants to check it out, so not much planning on which way I was uploading it.

Posts: 1864
Joined: Mon Apr 27, 2015 12:12 pm

Re: Porting Marlin to STM32.

Post by victor_pv » Fri Oct 27, 2017 4:37 am

Today I successfully printed a couple of test cubes, and then a Yoda-Bhuda with Marlin and the STM32F1 HAL I started writting. xC0000005 has joined development and rewrote the ADC part to work with DMA.
He printed successfully a couple of days ago with a Malyan M200 board, and I printed with custom board I made for these test.
I updated the first post to reflect the progress.
It's now in the official Marlin 2.0 bugfix branch, but I have to upload and submit the very latest changes I have been doing in my local copy, and xC0000005 may have submit some too, but now Marlin is functional in STM32F1 :D
I used an stm32f103vet. I forgot whats in the M200 board, but whatever MCU verson it has, it can fit Marlin too.

Posts: 854
Joined: Thu Jul 21, 2016 4:24 pm

Re: Porting Marlin to STM32.

Post by ag123 » Fri Oct 27, 2017 3:03 pm

+10 :)

Posts: 4
Joined: Thu Nov 02, 2017 5:43 pm

Re: Porting Marlin to STM32.

Post by mj666 » Thu Nov 02, 2017 6:16 pm

Hello, I own an Fabrikator Mini V2. This contains a very similar board like the Malyan M200. Here is the link:

https://hobbyking.com/de_de/main-board- ... -m100.html

I see the printer could get some firmware improvements and the Marlin firmware could be a good fit. During my investigations I found this thread and that someone is already working on this port. My plan was to order a spare board and start experimenting with this. I may be able to help on this project.

I'm working with an global team to develop STM32 based flight controllers since quite a while and have been deeply involved in the firmware development for this flight controllers:


I'm actively developing for BetaFlight and iNav, but was also was working on Harakiri, BaseFlight and CleanFlight in the past. I'm using Eclipse with the GNU ARM tool chain for this development. I used Arduino in the 8bit version in the past for the MultiWii with ATMega chips where I also did some work years ago.

Posts: 1864
Joined: Mon Apr 27, 2015 12:12 pm

Re: Porting Marlin to STM32.

Post by victor_pv » Thu Nov 02, 2017 10:36 pm

Any help is welcome.

I haven't done much in the code size because I was testing with another closed source board, a Chitu3d, and just finished with that a few days ago, and was able to print with Marlin.

xC00005 has been working on the Malyan, and he has successfully printed too. If that board is similar to the Malyan, all you need to do at the current time is map what pins are used for each function (step, dir and enable, for each stepper, thermistor inputs etc) and you should be able to print with it.

I believe xC00005 has last been working on the sanity check code, that checks your configuration in marlin (like 2 functions don't use the same pin, etc).
We still need to work on the LCD part.

Currently we are working off my branch of the code, that's almost up to the official 2.0 branch.
There is a lot of changes going on in the official branch for the LPC, and may take a while to get a PR merged, so I thought it would be easier to work on the STM32 in my HAL as I can merge more often, and then send PR to the official every once in a while.
also the official seems to break a bit more often due to so many changes going on, while the one in my fork is stable working now for us.
It's here:

Posts: 4
Joined: Thu Nov 02, 2017 5:43 pm

Re: Porting Marlin to STM32.

Post by mj666 » Fri Nov 03, 2017 5:35 pm

I have ordered the spare board. Looks to be its using an STM32F103C8T6. The basic design looks to be very similar to the Malyan200 board. It likely comes from the same source. Actually trying to get the Arduino build environment up and running to be able to build the code.

Posts: 10
Joined: Tue Mar 28, 2017 3:07 am

Re: Porting Marlin to STM32.

Post by parasole » Fri Dec 15, 2017 3:22 am

I posted this in another tread, sorry if to much duplication...
Nice open sourse "duino" compatible projects are available which enable closed loop control so many motion problems would be fixed. Then one idea is to have control part for 3-4 steppers in one bluepill which would communicate with another one running Marlin, while on stepper side having motor driver and position sensor in case closed loop is used...


Similar to above nano_stepper:

simpler and cheaper ustepperr, interesting side of this project that you may use cheap Polulu A4988 driver as is:

Posts: 2
Joined: Mon Jan 15, 2018 6:47 pm

Re: Porting Marlin to STM32.

Post by archimedesmp » Mon Jan 15, 2018 7:35 pm

Nice to see someone working on this. I'm currently have another STM32 project planned, but once that's done I'd like to build a 3D printer - and a blue pill/STM32F103C8T6 seems to be the best bang for buck 32bit control solution (whether with smoothieware or marlin doesn't matter that much [to me]).

Regarding current project status: I like where you're going with using the Pololu style stepper driver modules.

I'm just wondering, when using the DIR/STEP driver interface, why not put them behind SN74HCT595 (or 74AHCT595) shift register(s)? With one of these, the board should be able to drive 4 steppers from just 3 pins:
1. Feed 8 bits of data via DATA/CLOCK pins
2. pulse LATCH to "light up" the DIR/STEP ports we set in step 1
Since the shift register can operate at 100MHz that shouldn't be a bottle neck?
I think there has to be a timing delay of 19ns between CLOCK and subsequent LATCH (19ns ~ 52MHz).

Add a second shift register three pins can control 8 steppers (or better: 5 steppers, 3 hot {ends, beds}) [at half speed compared to the single register].

The ST datasheet only mentions the toggle frequency of 18 MHz for APB2 (but they don't [seem to] do DMA). To solve that, maybe they can be "talked" to via one of the two SPIs (which have DMA; just use CLK+MOSI to send 3 bytes for three registers, put LATCH on another pin and pulse it after DMA is done).

If more "slow" pins are required (fan control, microstepping, hot bed), those could also be added by just adding a bunch shift registers in a chain; e.g. 2 for microstepping control of 5 steppers (15 bits, 3 per polulu board) and a third for 8 channels hot bed/FAN/LED control,... Since that's all stuff which is probably not updated every few ms, these could go to any three pins.

Might be off there, but just my 2c - and might be better/easier than keeping two MCUs in sync :)

[Late night edit]: I totally forgot about the endstops, but you can check these with a shift register, too. Needs three pins and an ISR on one of them: one switch between each register pin and the stm32 input pin; pull all pins on the register high; if at least one switch closes, the ISR needs to test all switches for the one which was triggered; while that happens, no stepping should occur. If the switch is kept active, the endstop state has to be polled after each step cycle.

To sum up:
- fast: SPI/3 pins (18MHz, DMA)
- slow: 3 pins
- endstops: 3 pins
- 8 bit Shift registers: 2 + 3 + 1 = 6 (mouser: 0.215$ @ 100pcs as SO16 74AHCT595D)
The remaining pins can be used for LCD/SD/..., assuming those are suited for that purpose.

Of course there is no need to go "all in" on shifting stuff around, maybe it's enough to use one or two of these.

Similar alternative: MCP23S17T (10MHz SPI; SSOP-28 and smaller) or MCP23017 (1.7MHz I2C, SPDIP-28 and smaller) 16 bit I/O Expanders (<=1$ @ 100pcs).
Pins on these are I/O and can be configured to trigger one of two interrupts (neat for endstops).
See https://www.mouser.com/ds/2/268/20001952C-1129816.pdf for their common datasheet.
[end of late night edit]

Post Reply