Porting Marlin to STM32.

[victor_pv – Mon Jul 03, 2017 6:11 am] –
Hey Chriss, I’m the same one that posted in github about porting to STM32 and you shared your repo. I opened this thread here to keep track of my progress.

Ah, I thought so but wasn’t sure! I’m glad to see the progress you’ve been making, I think it’s good that people are working on this – I’m looking forward to printers running on an STM32 becoming more commonplace.

[victor_pv – Mon Jul 03, 2017 6:11 am] –
I don’t know if that’s all your code or borrowed, but if it’s yours it would be great if you give it a free license and can be used by everyone, and possibly make it compatible with as many MCUs as possible, and add compatibility with the F1 bootloader so a single set of tools work for uploading, but that’s a whole other subject.

The bootloader I put together is 90% from one of ST’s example projects on how to implement a DFU interface, with the other 10% of stuff just being basic housekeeping code I wrote. I’m not sure what ST’s license is like, but as far as I’m concerned anyone is free to do whatever they want with it. I’d love to see it become a more generic bootloader for STM32 chips that currently aren’t covered by the old Maple bootloader. The main thing it’s missing at the moment is the board needs to be manually reset for the DFU-upload to take place, I had some intent to add an automatic-reset into the USB-CDC stuff in the STM32Generic core, but haven’t played with that yet.

[victor_pv – Mon Jul 03, 2017 6:11 am] –
What board are you using in those pictures, is that a custom one?

Yeah, it’s a custom board. I’ve been developing an STM32 printer control board since late last year (in stops and starts), and I’m using the current prototypes to test my Marlin work. I plan to offer them for sale at some point, once we have STM32 stuff nicely integrated with mainline Marlin.

I keep going back-and-forth on what should and shouldn’t be included in the board design, so at the moment I’d say while it’s well tested it’s still an early prototype in that everything is still subject to change. Back when I first did the current batch of prototype boards I made the below pinout image, for my own reference and for some practice – this gives some details on the board I’m using:

Image

[victor_pv – Mon Jul 03, 2017 6:11 am] –
About the LCD, I was planning to not even test text screens, and go directly for nice color TFT since we have plenty of display drivers working with the F1, and take advantage of the cpu resources…

I agree, it would be good to see proper TFT displays in use now that we have the processing power. Generally, one of my goals is to have the best possible ‘backwards-compatibility’ with the existing hardware people are used to, so I really want to get common character and graphic displays that people already have working. One common complaint people have with 8-bit boards is that they can’t run a delta and a graphic (as in, monochrome LCD) display at the same time with good performance – I think it would be a good practical demo to show such a setup is now easily handled.

On the topic of TFT graphical interfaces, I’m in two minds as to the best way forward there. We do have the power onboard to handle that side of things with these 32-bit chips, but I kind of like the approach taken with the PanelDue where the display and interface is handled by a separate microcontroller, that then communicates with the control board via UART and standard G-Code.

An advantage there is that the UART + power connection can be any distance people might want on a printer, whereas an SPI or parallel interface to a TFT from the control board would have to be fairly short – so people would have to mount their display wherever the control board is.

Another advantage is that it means there’s no extra code in the printer firmware to handle the display, just G-Code parsing – so eventually you could have a display compatible with a range of control boards and firmwares.

Lastly, you can probably squeeze better performance out of a microcontroller dedicated to display/interface activities – I’d rather have an 80MHz MPU dedicated to the display than try juggling responsive display and real-time step generation on a 180MHz. Of course it’s definitely possible, I’m just speaking as to what I think would be easier – and with microcontrollers as cheap as they are, often it’s easier to share the work around.

That said, as you’ve pointed out with existing libraries and examples it would be relatively easy to get a graphical display up and running, and there are a lot of advantages to that approach too.

[victor_pv – Mon Jul 03, 2017 6:11 am] –
Are you using software SPI? I dont see the HAL SPI functions, neither the arduino standar ones.

Some of the code in the HAL_STM32 folder is unmodified from the Due HAL (where it was copied from), and I think that includes the SPI stuff. AFAIK those files include methods for a bit-banged SPI and the Due’s hardware SPI. That’s currently unused, the STM32Generic core is handling the SPI side of things on the F4 – so far I’m only using hardware SPI to talk to the stepper drivers, but that seems to be working well. I could probably delete those SPI files from the HAL folder, but I haven’t done so yet.

That’s part of why I like using the Arduino core approach, it removes the need to setup SPI, I2C, UART etc within the Marlin HAL. Though I’ve only tested with the one STM32Generic ‘board’ so far, that being for the F446VE, it’s very likely that the Marlin HAL would work with other ‘boards’ with minimal changes – so it may be possible eventually to get any STM32 supported by the STM32Generic core running Marlin.

[chrissb – Mon Jul 03, 2017 8:53 am] –
The bootloader I put together is 90% from one of ST’s example projects on how to implement a DFU interface, with the other 10% of stuff just being basic housekeeping code I wrote. I’m not sure what ST’s license is like, but as far as I’m concerned anyone is free to do whatever they want with it. I’d love to see it become a more generic bootloader for STM32 chips that currently aren’t covered by the old Maple bootloader. The main thing it’s missing at the moment is the board needs to be manually reset for the DFU-upload to take place, I had some intent to add an automatic-reset into the USB-CDC stuff in the STM32Generic core, but haven’t played with that yet.

I think we should copy the method that libmaple uses to reset the board. That would provide some compatibility at least for doing the reset, even if a different DFU uploader needs to be used.
We also provide for USB re-enumeration without using a extra pin and circuit, so it works in generic boards that do not have the circuit.

[chrissb – Mon Jul 03, 2017 8:53 am] –
Yeah, it’s a custom board. I’ve been developing an STM32 printer control board since late last year (in stops and starts), and I’m using the current prototypes to test my Marlin work. I plan to offer them for sale at some point, once we have STM32 stuff nicely integrated with mainline Marlin.

I keep going back-and-forth on what should and shouldn’t be included in the board design, so at the moment I’d say while it’s well tested it’s still an early prototype in that everything is still subject to change. Back when I first did the current batch of prototype boards I made the below pinout image, for my own reference and for some practice – this gives some details on the board I’m using:

Image

Nice, looks like a very clean design. I would only mention that since the steppers are onboard, you may want to add a sixth one on board, althougth no I see you already planned the expansion on E1.
You may also want to move the reset button somewhere more to the edge of the board, although that’s hopefully not needed often.

[chrissb – Mon Jul 03, 2017 8:53 am] –
I agree, it would be good to see proper TFT displays in use now that we have the processing power. Generally, one of my goals is to have the best possible ‘backwards-compatibility’ with the existing hardware people are used to, so I really want to get common character and graphic displays that people already have working. One common complaint people have with 8-bit boards is that they can’t run a delta and a graphic (as in, monochrome LCD) display at the same time with good performance – I think it would be a good practical demo to show such a setup is now easily handled.

On the topic of TFT graphical interfaces, I’m in two minds as to the best way forward there. We do have the power onboard to handle that side of things with these 32-bit chips, but I kind of like the approach taken with the PanelDue where the display and interface is handled by a separate microcontroller, that then communicates with the control board via UART and standard G-Code.

An advantage there is that the UART + power connection can be any distance people might want on a printer, whereas an SPI or parallel interface to a TFT from the control board would have to be fairly short – so people would have to mount their display wherever the control board is.

Another advantage is that it means there’s no extra code in the printer firmware to handle the display, just G-Code parsing – so eventually you could have a display compatible with a range of control boards and firmwares.

Lastly, you can probably squeeze better performance out of a microcontroller dedicated to display/interface activities – I’d rather have an 80MHz MPU dedicated to the display than try juggling responsive display and real-time step generation on a 180MHz. Of course it’s definitely possible, I’m just speaking as to what I think would be easier – and with microcontrollers as cheap as they are, often it’s easier to share the work around.

That said, as you’ve pointed out with existing libraries and examples it would be relatively easy to get a graphical display up and running, and there are a lot of advantages to that approach too.

I think you are right on that, but as far as USART displays using gcode I think the support already there should work out of the box. I need to see how is that configured, I hope Marlin allows to use one serial for host communication and another one for the display.
Did you have to modify the u8glib or the LCD lib to support that display? what about level shifters?

[chrissb – Mon Jul 03, 2017 8:53 am] –
Some of the code in the HAL_STM32 folder is unmodified from the Due HAL (where it was copied from), and I think that includes the SPI stuff. AFAIK those files include methods for a bit-banged SPI and the Due’s hardware SPI. That’s currently unused, the STM32Generic core is handling the SPI side of things on the F4 – so far I’m only using hardware SPI to talk to the stepper drivers, but that seems to be working well. I could probably delete those SPI files from the HAL folder, but I haven’t done so yet.

I have that part rewritten to use our core, and should be compatible with the STM32Generic one too, so once I upload my code just borrow that SPI file. That file is used for the sdcard transfer.

Which SPI port are you using for the steppers?
I wrote that file to use SPI (so spi1) since that’s what Arduino does, but could be modified to use another port if that’s the one you use for the steppers.

I am really surprised to not have seen any open source board using STM32s. They are cheap for the amount of features they have. Even with STM effort on Marlin4ST, the only boards using it commercially that I have found are closed source.

[victor_pv – Mon Jul 03, 2017 2:59 pm] –

[chrissb – Mon Jul 03, 2017 8:53 am] –
The bootloader I put together is 90% from one of ST’s example projects on how to implement a DFU interface, with the other 10% of stuff just being basic housekeeping code I wrote. I’m not sure what ST’s license is like, but as far as I’m concerned anyone is free to do whatever they want with it. I’d love to see it become a more generic bootloader for STM32 chips that currently aren’t covered by the old Maple bootloader. The main thing it’s missing at the moment is the board needs to be manually reset for the DFU-upload to take place, I had some intent to add an automatic-reset into the USB-CDC stuff in the STM32Generic core, but haven’t played with that yet.

I think we should copy the method that libmaple uses to reset the board. That would provide some compatibility at least for doing the reset, even if a different DFU uploader needs to be used.

There is CDC reset, same as libmaple.

[danieleff – Mon Jul 03, 2017 3:11 pm] –

[victor_pv – Mon Jul 03, 2017 2:59 pm] –

[chrissb – Mon Jul 03, 2017 8:53 am] –
The bootloader I put together is 90% from one of ST’s example projects on how to implement a DFU interface, with the other 10% of stuff just being basic housekeeping code I wrote. I’m not sure what ST’s license is like, but as far as I’m concerned anyone is free to do whatever they want with it. I’d love to see it become a more generic bootloader for STM32 chips that currently aren’t covered by the old Maple bootloader. The main thing it’s missing at the moment is the board needs to be manually reset for the DFU-upload to take place, I had some intent to add an automatic-reset into the USB-CDC stuff in the STM32Generic core, but haven’t played with that yet.

I think we should copy the method that libmaple uses to reset the board. That would provide some compatibility at least for doing the reset, even if a different DFU uploader needs to be used.

There is CDC reset, same as libmaple.

Is there a board reset triggered if 1EAF is received as in libmaple? I believe that’s the part Chriss is talking about having to be manually reset.
If not, could we add that to the core?

@Chriss

I was having a look at the steppers and the board config file. I see the steppers support an SPI interface, and they can even be daisy chained one to another, so they shift out data to the next stepper as long as CS is kept low, but can also be managed independently with their own CS line each.
I understand you are using SPI only for configuration but not to set steps and dir is that right?
I need to double check, but I believe Marlin4ST uses the SPI port for everything, which saves a ton of pins, and allows for fast SPI transmissions.

Anyway, something to look at down the road, but I wanted to comment on that in case you are already using it in your board and I didn’t see.

[victor_pv – Mon Jul 03, 2017 3:55 pm] –

[danieleff – Mon Jul 03, 2017 3:11 pm] –

[victor_pv – Mon Jul 03, 2017 2:59 pm] –

I think we should copy the method that libmaple uses to reset the board. That would provide some compatibility at least for doing the reset, even if a different DFU uploader needs to be used.

There is CDC reset, same as libmaple.

Is there a board reset triggered if 1EAF is received as in libmaple? I believe that’s the part Chriss is talking about having to be manually reset.
If not, could we add that to the core?

Yes, reset on 1EAF

[victor_pv – Mon Jul 03, 2017 4:11 pm] –
@Chriss

I was having a look at the steppers and the board config file. I see the steppers support an SPI interface, and they can even be daisy chained one to another, so they shift out data to the next stepper as long as CS is kept low, but can also be managed independently with their own CS line each.
I understand you are using SPI only for configuration but not to set steps and dir is that right?
I need to double check, but I believe Marlin4ST uses the SPI port for everything, which saves a ton of pins, and allows for fast SPI transmissions.

Anyway, something to look at down the road, but I wanted to comment on that in case you are already using it in your board and I didn’t see.

i did a little read up on polou’s A4988 modules which are the RAMPS modules
https://www.pololu.com/product/1182
http://www.allegromicro.com/~/media/Fil … sheet.ashx

it apparently doesn’t have a SPI style /CS pin, the only control pin /ENABLE is to turn off/on the mosfets (active low)
that would seem to say that an ‘SPI’ style connect may not really be feasible. either way the main pins are basically STEP and DIR
it would be good to have /ENABLE there as well, but i’m guessing that we can group all the /ENABLE into a single stm32 gpio control pin.
i.e. all or none, all FETs on or all FETs off across multiple motors, that could help save a couple of pins but not really a lot of it

p.s. read a little more on the web, it seemed it isn’t a good practice to keep the FETS enabled, it simply heat up the motor & the driver chip esp when currents is large when the motor is not moving. in that case keeping the enable lines separate is possibly a good thing as the motors do not always move together

There are some new drivers that support SPI communications. Some only for configuration, and some for everything.

I’m not sure how much control there is in the TMC ones, but the STM L6470, the one STM used in the EVAL board, allows full control with SPI. You can even send a command to tell the driver to what position you want to move the motor, and the stepper will take care of the acceleration, move, and deceleration.
Seems like a pretty good feature compared to having to send a number of pulses and having to keep the count in the MCU.
Have a look at the datasheet http://www.st.com/content/ccc/resource/ … 255075.pdf
Anyway I was checking STM code in Marlin4st, and not even them use the SPI port for that in that driver they only use it to configure the driver, but then send pulses and direction in 2 pins as the other drivers.
One thing that they do differently than normal Marlin code is that they use hardware timers in PWM mode to send the pulses. I’m not sure how much cpu time that saves given that they service an interrupt for every pulse.
Marlin instead uses a single timer loop to manage all the steppers, by toggling the step pin up and down directly. the timer doesn’t toggle any pin, but is just used to call that function periodically.

About the enable pin, I think many boards just keep them all enabled all the time. Any board using a 64pin MCU should have enough, the Maple mini is definitely constrained in the number of pins, although as far as the code fits, it can be enough for a basic printer.

the L6470 is a much better stepper driver than the Pololu Ramps style drivers
1/128 microstepping and SPI interface
it would really make the 3d printing run extremely smooth

a4988 and drv8825 has only 16 and 32 microsteps respectively
http://reprap.org/wiki/A4988_vs_DRV8825 … ver_Boards

but i’d guess it is also part of the reason why ST’s reference 3d printer board comes at a premium in costs at least

actually it didn’t matter too much as the different boards e.g. RAMPS have its own board includes. this would allow those who has the better stepper drivers to use a board.h file and stepper driver codes that use less pins. and those who use RAMPS would need to use a board with lots of gpio pins, but they go with different board.h files and stepper drivers codes

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

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

[danieleff – 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.

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
I used an stm32f103vet. I forgot whats in the M200 board, but whatever MCU verson it has, it can fit Marlin too.

+10

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:

https://www.alienflightng.com/

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.

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:
https://github.com/victorpv/Marlin/tree/bugfix-2.0.x

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.

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…

mechaduino:
http://tropical-labs.com/index.php/mechaduino
https://github.com/jcchurch13/Mechaduino-Hardware
https://github.com/jcchurch13/Mechaduino-Firmware

Similar to above nano_stepper:
http://misfittech.net
https://github.com/Misfittech/nano_stepper

simpler and cheaper ustepperr, interesting side of this project that you may use cheap Polulu A4988 driver as is:
http://www.ustepper.com/index/what-is-ustepper/
https://github.com/uStepper/uStepper

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]

Hi everybody
i’m trying to compile the code on a Open103Z (STM32F103ZET) very close of 103RET but i’ve an issue during compilation :

sketch\src\HAL\HAL_STM32F1\persistent_store_impl.cpp: In function 'bool HAL::PersistentStore::access_start()':

sketch\src\HAL\HAL_STM32F1\persistent_store_impl.cpp:56:20: error: 'class CardReader' has no member named 'read'

bytes_read = card.read (HAL_STM32F1_eeprom_content, HAL_STM32F1_EEPROM_SIZE);

^

sketch\src\HAL\HAL_STM32F1\persistent_store_impl.cpp: In function 'bool HAL::PersistentStore::access_finish()':

sketch\src\HAL\HAL_STM32F1\persistent_store_impl.cpp:70:23: error: 'class CardReader' has no member named 'write'

bytes_written = card.write (HAL_STM32F1_eeprom_content, HAL_STM32F1_EEPROM_SIZE);

^

exit status 1
Erreur de compilation pour la carte Generic STM32F103Z series