Porting Marlin to STM32.

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

Re: Porting Marlin to STM32.

Post by 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.

I need to check the newer one based on STM32GENERIC, but as far as we dont hack Marlin much we should be able to port it to multiple MCUs and keep it updated.

I started with the port to the libmaple core and have a few things running already. That once has normally an advantage in speed and code size over the HAL based one, but in return it's more difficult to adapt core from one MCU to another, although there are F3 and F4 versions that are very functional. Things like spi, timers, gpio, usb, usarts, work in all of them.

I'll be happy to help with that HAL too.
I used the LPC fork to start with since someone said that fork is fairly up to date and the LPC HAL is functional.

About the DFU bootloader, that would be a nice adition for the F4 boards. Most people around here use stlinks and jlinks since the bootloader we use for the F1s has not been ported to other series.
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.

What board are you using in those pictures, is that a custom one?

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, but that's down the list after steppers, thermistors, temp... are working.

EDIT:
Just had a quick look at the HAL in this repo:
https://github.com/Aus3D/Marlin/tree/32 ... /HAL_STM32

Are you using software SPI? I dont see the HAL SPI functions, neither the arduino standar ones.

chrissb
Posts: 3
Joined: Sun Mar 05, 2017 7:37 am

Re: Porting Marlin to STM32.

Post by chrissb » Mon Jul 03, 2017 8:53 am

victor_pv wrote:
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 wrote:
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 wrote:
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 wrote:
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 wrote:
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.

victor_pv
Posts: 1788
Joined: Mon Apr 27, 2015 12:12 pm

Re: Porting Marlin to STM32.

Post by victor_pv » Mon Jul 03, 2017 2:59 pm

chrissb wrote:
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 wrote:
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 wrote:
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 wrote:
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.

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

Re: Porting Marlin to STM32.

Post by danieleff » Mon Jul 03, 2017 3:11 pm

victor_pv wrote:
Mon Jul 03, 2017 2:59 pm
chrissb wrote:
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.

victor_pv
Posts: 1788
Joined: Mon Apr 27, 2015 12:12 pm

Re: Porting Marlin to STM32.

Post by victor_pv » Mon Jul 03, 2017 3:55 pm

danieleff wrote:
Mon Jul 03, 2017 3:11 pm
victor_pv wrote:
Mon Jul 03, 2017 2:59 pm
chrissb wrote:
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?

victor_pv
Posts: 1788
Joined: Mon Apr 27, 2015 12:12 pm

Re: Porting Marlin to STM32.

Post by 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.

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

Re: Porting Marlin to STM32.

Post by danieleff » Mon Jul 03, 2017 4:22 pm

victor_pv wrote:
Mon Jul 03, 2017 3:55 pm
danieleff wrote:
Mon Jul 03, 2017 3:11 pm
victor_pv wrote:
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

ag123
Posts: 824
Joined: Thu Jul 21, 2016 4:24 pm

Re: Porting Marlin to STM32.

Post by ag123 » Mon Jul 03, 2017 5:10 pm

victor_pv wrote:
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
Image

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

victor_pv
Posts: 1788
Joined: Mon Apr 27, 2015 12:12 pm

Re: Porting Marlin to STM32.

Post by victor_pv » Mon Jul 03, 2017 8:31 pm

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.

ag123
Posts: 824
Joined: Thu Jul 21, 2016 4:24 pm

Re: Porting Marlin to STM32.

Post by ag123 » Tue Jul 04, 2017 6:52 am

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

Post Reply