Anyone tried to make a 3D Printer controller?

Thanks for the explanation. I was aware of your port and that of Chriss Bar.
I definitely want to give your Marlin-STM32-libmaple ( https://github.com/victorpv/Marlin-STM32-libmaple ) a try on the C8.
So it’s nice to hear, you didn’t fall into problems till now and “fake printing works” – ok, may be, I am earlier, to connect steppers.
Right, I/O-Pins is an issue. But, if you remember NanoHeart (http://reprap.org/wiki/NanoHeart ) – for most simple 3D-Printers, it’s enough.
I/O-Pins are different quality: Sure I2C, should be open to extend, interconnetion(USB) a must, Step/Direction-for steppers are most important, AD for Sensors (thermistors) are important.
Nanoheart enables all XYZ-Motordrivers in common. End-Stops are simple stuff. (Somebody already mentioned here, can be used as R-Network on an AD-Pin).
Sensor-Readings may be muxed with Enable-IO and so on, if you get in need for another stepper-motor. SDcard SPI has CS – so potentially shareble. Local Operating & display has many options and they can be implemented with a bus or completely remote (Smartphone … ).
I myself prefer, reducing wiring of sensors (or noncritical On/Off-Signaling) by using simple 8pin-AVRs distributed in the cable tree. (cable costs and organisation is an issue).
Conclusion: Its nice to have a hundred IO-Pins at the uC – so, you don’t have to think about and count the pins. For a 3D-Print-Controller from point of IO , I think, it’s also feasable with the C8. (Your List counts 35 + 2 for I2C – that’s all of the C8 + LED to share). May be, if you need extended features, you have to think about Sharing IO-Pins or simple Multiplexing. IO may be also sophisticated distributed (Simple Bus and peripheral uC-Nodes) with some other useful effects, if Firmware would implement hooks for this. If it comes to more features, from my point of view, it’s also a nice idea to have a sister-Pi ( Rasp.Pi Zero or Orange Pi Zero ) on the Printer.

But first, I am interested, to get a C8-FW running reliable.
One point on Teacup: It’s said, much higher stepping rates are possible.

[xebbmw – Thu Aug 31, 2017 4:02 pm] –

[alce – Fri Aug 25, 2017 8:20 pm] –
Ok, short update on my stm32f446re plan.
I got the ramps 1.4 board and it turned out the arduino connector on nucleo board does not populate all the necessary pins so I ended up having to add about 20 dupont cables.
The wiring I did turned out pretty neat so not much of a deal breaker for me. I got all motors working, 3 endstops, fet. I ended up grouping all the motor en pins together just to make my life little bit easier.
I switched SD card to 1 bit SDIO mode which boosted write speed to ~1mb/s from 200kb/s SPI. Smoothieware uses some uip lib to do tcp/ip in software and since W5500 does it in hw it occurred to me
that it would be faster for me just to boot the whole network module and do a very simple telnet and sftp myself. Which I did and it takes about 80 seconds to transfer 4MB gcode file which I suppose is not bad but I think switching W5500 to SPI DMA should at least triple transfer speed.
I dont think I’ll bother with any kind of web ui since it seems like a quite a bit of work. The way I would probably go about it though would be to export gcode interface to javascript(something like ajax) and then do all the interactive stuff in js.
BTW, if marlin folks need a basis for network code you could use this one. It is about 1K of code for both sftp and telnet using the wiznet libs. I think the telnet could also be used as an display replacement. Think github.com/hanzi/telnetris

Now unfortunately my nucleo board started acting weird(rebooting when transferring files via sftp) yesterday and today it stopped working altogether so I did not get to print tests quite yet. Suspecting ESD damage…
Fortunately arrow.com sells NUCLEO-F446RE for about 15 usd w/ free DHL shipping so I should get to it next week.

Did you publish somewhere your changes? It becomes interesting …
On Smoothieware forum it seems the developers are working more on new Smothieware 2 (at least this is my conclusion from http://forum.smoothieware.org/forum/t-2 … 32-support)

I have not published anything yet. I find this ramps board a bit of a nuisance to fiddle with because the pins are not labeled and have to go through schematics to track down the pins. I am leaning towards wanting to replace ramps 1.4 with a 4 channel fet driver(off ebay), motor driver pcbs and a little bit of electronics for the temperature sensors. I think this kind of setup would be more suitable for the esp32 module later on. Also the W5500 ethernet module seems to have some compatibility issues with some routers so looks like I have to swap it to ENC28J60.

[alce – Mon Sep 11, 2017 11:19 pm] –
I have not published anything yet. I find this ramps board a bit of a nuisance to fiddle with because the pins are not labeled and have to go through schematics to track down the pins. I am leaning towards wanting to replace ramps 1.4 with a 4 channel fet driver(off ebay), motor driver pcbs and a little bit of electronics for the temperature sensors. I think this kind of setup would be more suitable for the esp32 module later on. Also the W5500 ethernet module seems to have some compatibility issues with some routers so looks like I have to swap it to ENC28J60.

When teacup firmware was ported to Nucleo-F401RE the author used an Arduino CNC shield instead of Ramp 1.4, it is not expensive on ebay. It fits very well in the Nucleo board just need to configure the pins properly. Maybe you could use the same for your tests.

Okay, I managed to get the wiring somewhat right for a test print. Unfortunately uart crashes soon after the fast moves start. I do think it is probably caused by the fact that some of the pins are shared by the nucleo debug interface that provides uart to begin with. I have not found exact docs on how exactly did the wire the thing and I would not be surprised if the info is fine printed page 241 of some manual. It is a bit difficult for me to proceed without eth and cnc shield so I guess more waiting it is then.

Anyway if someone wants to give it a shot fw is at https://filebin.ca/3ahQAie012Lv/main.bin . Put it in msd of stm32f446re nucleo . There is a built in configuration in the firmware which is set to baud rate of 115200. The temp sensor is hard wired to PC1 and all temp sensors you define in config will read from this pin. I poked the code a bit to support endstops tied to one pin trying to home with delta, corexy etc. probably is not going work unless you disable itrim_homing in config.

sd card(in sdio mode):
mosi pd_2
sck pc12
miso pc8

w5500 ethernet:
SPI2_MOSI PB_15
SPI2_MISO PB_14
SPI2_SCK PB_13
SPI2_CS PC_6
ETH_RST PC_5

I may have misunderstood you, but I think you are looking for the Nucleo 446 schematic to see how the stlink onboard and the 446 are wired?
That’s available here:
http://www.st.com/en/evaluation-tools/n … 446re.html

Search for the word schematic and it’s there. All the nucleo boards are wired very similarly as far as I know.

i’m halfway wondering if marlin or more correctly both marlin and ‘gcode senders’ if there are any desktop ‘g-code sender’ that routes g-codes to multiple 3d printer controllers

i found at least this
http://winder.github.io/ugs_website/

but i’m not too sure if the more popular variants e.g.
http://octoprint.org/
https://www.repetier.com/
after all does that

if it does we can possibly have multiple BP/MM doing different things, they can after all be hooked up on a same usb hub via usb-serial.
e.g. we could have one BP/MM dealing with the xy motors and maybe endstops, another deal with z motors, z endstop and extruders
then yet another deal with heating, temperature monitoring and maybe handle an ILI9341 display

https://www.simplify3d.com/support/arti … -tutorial/
an issue is like if there are 3 gcodes e.g.
G1 X0 Y0 F2400 ; move to the X=0 Y=0 position on the bed at a speed of 2400 mm/min
G1 Z10 F1200 ; move the Z-axis to Z=10mm at a slower speed of 1200 mm/min
G1 X30 E10 F1800 ; push 10mm of filament into the nozzle while moving to the X=30 position at the same time
some protocol is needed to keep the 3 controllers BP/MM working in sync

I get a feeling all that complication would not be worth it when an RCT or a VCT MCU have many more pins and cost almost the same.

I am in the process of building a 3d printer controller board around an STM32F1 or F4 daughterboard (Vxx MCU, replaceable).
I am basing my design off the many other existing open designs, such as RAMPS, RAMPS-FD, Smoothieboard, etc…

6 steppers, pololu format pluggable (but allows up to 8 with little modification, pins are already accounted for it).
4 thermistors (more optional)
4 high power FETs (bed, extruders…)
2 low power FETs (fans)
SDIO + SPI SDcards support.
LCD + rotary encoder +button for input (SPI2 port and USART ports available in the same pins, so more advanced displays and inputs can be used with the same pins in different function mode)
EEPROM onboard for settings + I2C connector for anything else in I2C.
USART1 connector
Several pins left for expansion, to be used for IO or analog inputs, including PWM functionality, an SPI port, and USARTs
SWD pins available for debugging (not using them for any other function)

All that is possible with the 100pin MCUs (Vxx) carefully planning what pin is used for what function, if jumping to the Zxx 144 pins MCUs, it would be possible to do all that, plus leave a lot of pins and ports for future options.

An Rxx MCU would have enough for a basic printer if the ENABLE pin is shared by all steppers, otherwise there would have to be compromises here and there (forget the LCD, or forget the SDCard), but then the point is, why build a basic printer board? there is already a ton of them available for cheap. Could be ok just for testing code and individual functions, but I’ll rather use my time in getting as much as possible out of the STM32 MCUs.

There is a Marlin HAL for LPC1768 mostly working (although with some issues, some people report the boards hanging midway thru the print, I have had issues with some sdcards…) that I have been helping with a bit as I can.

I think given the nice cores we already have, that an STM32 printer board would work better, with less issues, and allow features to be added more easily. I have my libmaple HAL already working with the core functions, need to add the eeprom support, and test LCD display, sdcard, but all those things are already working with our cores, so should not be an issue at all.

And I planned all STEP/DIR pins in the same GPIO port, so if at some point it Marlin can be modified enough, write those with DMA from a buffer, a single DMA write could set and clear all STEP/DIR pins at once, rather than the individual set/clear that’s done in Marlin at the moment. But that’s looking at the future, since currently Marlin does the GPIO wirtes in the same ISR where it calculates when they should be done. All that could be decoupled to a function that writes to a DMA buffer, programs the DMA and a timer trigger to the right frequency, and fires the timer. While that’s sequence is outputting with DMA, it can be calculating the next moves in a second buffer and fire it as soon as the previous DMA is over. So separating the output part (managed by DMA+Timer) from the steps calculation part, that just prepares the buffer.

unlike the more elaborate stepper motor controllers from ST, many of the A4988 RAMPS stepper motor controllers are rather basic
https://www.pololu.com/file/download/a4 … e_id=0J450
and it would seem that it wouldn’t be possible to share the step and dir pins as there isn’t a chip select pin on those a4988 controllers.
as to sharing /enable my thoughts are that it may be possible but that it would depend on how marlin is programmed. if it expects /enable to be independently controlled, there may be a catch in that marlin is trying to control a single motor and it pulls up /enable which causes all the motors to be disabled simultaneously instead
this would mean having 2 independent pins for each motor at least, in terms of microstepping resolution my guess would be that it can be set at a constant 16 microsteps, so that would mean we’d need at least 2 pins step and dir for each motor, and if /enable can be shared, that would save a couple of pins.

while using dma is attractive, it probably isn’t really necessary as the step signals would probably be in the hz ranges as we are moving motors which can’t literally respond faster than that. i think the motor controls isn’t literally ‘blocking’ for that matter, in a sense that the gpio pins for step and dir is pretty much ‘fire and forget’. lets just say that we pulse step for 1 ms, between one microstep to the next we may need to provide 10s of ms at least for the motor to complete the move, so in between steps the mcu can already perform lots more other processing including parsing the next command , doing the calcs, optimizing the next move etc and there may still be plenty of time left till the next step needs to be taken.

i.e. with ramps type of boards, we’d need to use a mcu with adequate number of pins to run it which things like vet would probably adequately meet that

strictly speaking the other way that we can do it is that instead of ramps we can use ST’s rather pricy stepper motor controllers / driver L6470
http://www.st.com/content/st_com/en/pro … l6470.html
http://www.st.com/content/ccc/resource/ … 255075.pdf
https://www.ebay.com/sch/i.html?_from=R … 70&_sop=15

this stepper controller is actually much better than do the A4988 with 128 microsteps, it may literally make rather ‘silent’ 3d printers
the L6470 uses SPI for the interfaces which in effect reduced that to 3 shared pins (MISO, MOSI, CLK) and one independent CS pin for 3 xyz motors + 1 extruder that reduces the total pin count to a mere 7 pins running the motors. however, there are still the end stops and temperature control and thermistor) there may be 2 sets the hot end 1 heater + 1 thermistor and the heated bed 1 heater + 1 thermistor
unfortunately the L6470 is pricy

an alternate is to get st’s own (rather pricy) 3d printer driver board which sports a stm32f401 along with L6474 motor drivers (16 microsteps only though)
http://www.st.com/content/st_com/en/pro … 001v1.html

The steps are normally in the range of 10s of Khz in the AVR, depending on what speed you are moving and how many microsteps per full step, but in the AVRs, people is hitting the limit, at which point the moves become jerky when the CPU can’t keep up with the required number of steps. But that’s at 8 or 16Mhz. So even though at the moment I don’t think just moving motors would hog the CPU, when you add to that reading from an SDCard, or reading/writting to USB, plus a diplay, plus bed leveling calculations (those are cpu intensive), then CPU usage goes higher an higher.
At the moment Marlin has trouble keeping up with certain speeds when bed levelling is enabled. I am sure as the 32bit platforms become the norm, more features, more precission, etc will be added, until again reaches a point where the CPU alone can’t keep up.
So that’s why I’m planning ahead and making sure hw peripherals and DMA can be used in the future.

Just to give you an idea where Marlin is right now, some displays use software SPI… just because the AVR have a single SPI port, and there is some LCD displays that can’t share a port (no matter how CS is managed).

In the Re-ARM board, which uses an LPC1768 with 2 SPI ports, one is dedicated to an onboard sdcard, which is not used for printing, then the second port is used for the SDCard in most LCD panels. And then the LCD displays that use SPI, have to use software SPI… That just so an SPI port is used for board itself to save EEPROM values.

I’m trying to plan ahead for all those limitations, or at least the ones I can avoid. I reserved 1 SPI for the SDCard, 1 SPI for the LCD, and 1 SPI is still free, so if in the future I device to use steppers with SPI control, I have that hardware port free for that.
Same with USARTs, 1 broken out, another one shared with the LCD pins, so if instead of using a normal LCD panel, you use a Nextion display (uses serial), you can connect it to a hardware serial port since the pins were reserved for LCD.

About STEP and DIR, I think the same, those can’t be shared. About ENABLE, seems like Marlin can take it being the same for all steppers, but I also think that wouldn’t be ideal.

That’s why even though I am testing code in a RCT6 board, I’m designing my own for an VET MCU, so I have enough pins for everything.

The step control part is an ISR, when it’s doing it’s job, it blocks everything else other than interrupts with a higher priority, so if the stepper code can’t keep up with the pace, the printer just becomes sluggish.

i’m starting to think in terms if it may be worth it to have a ‘highly optimised’ marlin for stm32 instead, stm32 has lots of h/w timers, if we let the timers (generate the square wave train) run the motors, the isr may be able to do ‘fire and forget’ but the design may be drastically different.
e.g. set the timer set the counts 1 timer for each motor and go, we’d only need to monitor if the timer is done with the counts
the main thing that’d be hard to do with timers is if we want to precisely control acceleration, constant speed moves, deceleration. Doing that with timers would seem pretty difficult as the period varies during acceleration and deceleration

[victor_pv – Sun Sep 24, 2017 11:45 pm] –
The steps are normally in the range of 10s of Khz in the AVR, depending on what speed you are moving and how many microsteps per full step, but in the AVRs, people is hitting the limit, at which point the moves become jerky when the CPU can’t keep up with the required number of steps. But that’s at 8 or 16Mhz. So even though at the moment I don’t think just moving motors would hog the CPU, when you add to that reading from an SDCard, or reading/writting to USB, plus a diplay, plus bed leveling calculations (those are cpu intensive), then CPU usage goes higher an higher.
At the moment Marlin has trouble keeping up with certain speeds when bed levelling is enabled. I am sure as the 32bit platforms become the norm, more features, more precission, etc will be added, until again reaches a point where the CPU alone can’t keep up.
So that’s why I’m planning ahead and making sure hw peripherals and DMA can be used in the future.

In case you are worried about performance later, would not be a good solution to use RTOS and efficiently switch between tasks/threads?
The following example http://jhnet.co.uk/projects/makebed describes an implementation of RTOS however for LPC1768 micro controller.

The latest version of Smoothieware 2 runs also on RTOS and it seems that DuetWifi does it also.

I have built a delta printer and now I am looking to replace the controller board to a more more powerful one (as a project, not really buying an existing solution). I also thought that an STM32F407VET board would be the best candidate for a new firmware. I have a STM32DiscoveryF4 based on STM32F407 board, this might serve for testing purpose.

Building a firmware for STM32 micro controllers based on a shield where existing board (like STM32F407VET board) and Polulu stepper drivers can be used, would be a very nice solution.

Using an RTOS would help with scheduling threads, but not in making the CPU do more tasks at the same time once cycles are not spent waiting.
On the AVR implementation the CPU can not keep up with the pace if the stepper speed is too fast and there are things like bed leveling enabled. By the way in Marlin the stepper code does not wait for anything, instead uses a timer to generate interrupts as often as needed.
There is just not enough cycles to do it all at some speeds.

If the STM32 MCUs, hitting that limit may take a while, but at that point being able to use DMA would offload the GPIO access to the DMA controller, so the CPU would be totally free do something else while the DMA controller takes care of the steppers for a number of steps (could be hundreds or thousands depending on the size of the dma buffer).
Using DMA and an RTOS are not exclusive of each other, you can use DMA to offload peripheral access, and still use an RTOS to manage task scheduling and what’s done in the CPU, while the DMA is on its own doing its job.

About a printer board for the Nucleo, I don’t know if anyone has designed one already, but could possibly be a good idea for development. I am designing my own board in a way that the CPU is in a daughter board. I may have a look about using a nucleo as the daughter board.

This may sound a very negative comment, but arent there a strange clause in the usage license on the Nucleo boards that say they can only be used for “evaluation”, i.e not for a real use, like controlling a 3D printer.

I may PM Frederic about this, as its technically a real limitation on the Nucelo boards.

But I agree, when going to the effort of designing a daughter board, you need to do so for a CPU platform which will not suddenly go out of production, or get modified by the manufacturer in ways that would effect the daughter board.

I would suggest the Seeed Arch Max (F4) board as a host, but Seeed could stop production of it at any time.

my guess is if u’re using it yourself it probably wouldn’t matter too much if after all you are running a 3d printer with a nucleo or discovery board
but that may be a catch for those selling the board as a 3d printing solution
doubt any vendor would give a promise of ‘perpetual’ production. Hence, i’d guess if the boards are after all affordable, one could buy a couple as spares

recently among them are one of the favourite here the stm32f407vet black are looking rather attractively priced on ebay
https://www.ebay.com/sch/i.html?_nkw=stm32f407&_sacat=0

actually i’m half way hoping stm would sell their L6470 stepper motor controllers for less, so that perhaps there’d be ‘cheaper’ L6470 breakout boards
https://www.ebay.com/sch/i.html?_sacat= … 70&_sop=15
as the L6470 runs on SPI
http://www.st.com/content/st_com/en/pro … l6470.html
it would just take a mere 8 pins to run 5 motors
then we can probably run a 3d printer with 3 motors (X, Y, Z) and 2 extruders (i.e. 2 colors filaments simultaneously) on just a blue pill or maple mini

[ag123 – Wed Sep 27, 2017 1:09 pm] –
recently among them are one of the favourite here the stm32f407vet black are looking rather attractively priced on ebay
https://www.ebay.com/sch/i.html?_nkw=stm32f407&_sacat=0

I agree with you on black stm32f407vet. It is cheaper than Nucleo board and a perfect match as daughter board in 3D printer controller board. A shield like the ones for Arduino Due is all that is needed.

Roger asked me some information about the use of ST Nucleo board, I’ve asked internally and this is the answer:
The license for ST boards does not authorize their use in end-products to ensure ST does not get exposed to any liability.
ST boards can be used in home projects, considered as prototypes.
ST tolerates that people use ST boards in end-products, however ST recommends that users clone ST boards if they want to include them in their end-products.

[xebbmw – Wed Sep 27, 2017 1:24 pm] –

[ag123 – Wed Sep 27, 2017 1:09 pm] –
recently among them are one of the favourite here the stm32f407vet black are looking rather attractively priced on ebay
https://www.ebay.com/sch/i.html?_nkw=stm32f407&_sacat=0

I agree with you on black stm32f407vet. It is cheaper than Nucleo board and a perfect match as daughter board in 3D printer controller board. A shield like the ones for Arduino Due is all that is needed.

well actually i bought this RAMPS
http://www.ebay.com/itm/3D-Printer-Cont … 0699832639
http://www.ebay.com/itm/RAMPS-1-4-Contr … 1691531028
and even this RAMPS-FD
http://www.ebay.com/itm/RAMPS-FD-32bit- … 2017526524
http://www.ebay.com/itm/GE-Pololu-Shiel … 2312531140

the idea is that you could basically connect them with dupont wires
https://www.ebay.com/sch/i.html?_nkw=du … e&_sacat=0
hence a shield isn’t really necessary

RAMPS FD being designed for Arduino Due which is basically a 3.3v arm based board would likely be easier interfacing with stm32 boards
but RAMPS FD is quite a bit pricier than RAMPS

using the generic RAMPS or RAMPS FD boards frees one up to mix and match the boards, one could basically get any of the various f4 vet, zet (or f1) boards out there on ebay, aliexpress, olimex and even ST nucleo, discovery boards, then map the pins between those boards to RAMPS, RAMPS-FD using the dupont cables

and to save time, one of the easier way is to buy one of the lower costs 3d printer kits some of which goes for about usd 200 (or less) and you could replace the controller

[ag123 – Wed Sep 27, 2017 1:09 pm] –
actually i’m half way hoping stm would sell their L6470 stepper motor controllers for less, so that perhaps there’d be ‘cheaper’ L6470 breakout boards
https://www.ebay.com/sch/i.html?_sacat= … 70&_sop=15
as the L6470 runs on SPI
http://www.st.com/content/st_com/en/pro … l6470.html
it would just take a mere 8 pins to run 5 motors
then we can probably run a 3d printer with 3 motors (X, Y, Z) and 2 extruders (i.e. 2 colors filaments simultaneously) on just a blue pill or maple mini

Why not on TMC2130 stepper driver that runs also on SPI? There is already a fork of Marlin that was adapted for TMC2130 https://github.com/teemuatlut/Marlin. I guess would not be needed to have a STM32F4 running the board, but only an STM32F1 aka bluepill. The board would need less pins than it was explained in the post below:

[victor_pv – Sun Sep 10, 2017 4:32 am] –
There is already 2 Marlin HALs for STM32, one that I am working on, based on libmaple, and nother one from Chriss Bar based on the GENERIC core.
Mine, depending what options you pick, fits in about 90KB of flash, so can run on a CB (or a C8 with 128KB). The biggest issue with those MCUs is that they don’t have enough pins for everything, so you have to pick what you leave out.
So I’m testing mine in an RCT6 board, with 256KB of flash and 48 of RAM, and so far fake printing works fine (no steppers connected). I have tested the same print takes the same time on my HAL on a STM32F1, as in the LPC1768 HAL that runs in the Re-arm or smothieware boards, so the stepper code is running at the right pace. I still ned to plug it to a printer and run an actual test, but I am still working on other parts of the HAL.

Normally you need at least this many pins:
Min 4 steppers, 3 pins each (DIR, STEP, EN): 12 pins
Min 2 thermistors: 2 pins
Min 2 PWM outputs for heated bed and extruder
End stops: 3 pins
USB 2 pins
If you use sdcard 4 pins
If you use an LCD, 4-6 pins, depending which.
If you use a rotary encoder for navigatins menus, 3 pins.
Beeper 1 pin

[xebbmw – Wed Sep 27, 2017 1:55 pm] –
Why not on TMC2130 stepper driver that runs also on SPI? There is already a fork of Marlin that was adapted for TMC2130 https://github.com/teemuatlut/Marlin. I guess would not be needed to have a STM32F4 running the board, but only an STM32F1 aka bluepill. The board would need less pins than it was explained in the post below:

Thanks , didn’t realise TMC2130 is SPI too
https://www.ebay.com/sch/i.html?_sacat= … 30&_sop=15
it is also rather interesting that TMC2130 and ST’s L6470 breakouts are priced around the same range on ebay both SPI motor controllers
https://www.ebay.com/sch/i.html?_nkw=L6470+&_sacat=0

the other thing would be that TMC2130 seemed to be designed towards a 5v system
https://www.trinamic.com/fileadmin/asse … asheet.pdf
while L6470 it seemed would be easier to interface with 3.3v logic as it seemed to have been designed for it
http://www.st.com/en/motor-drivers/l6470.html

oh and someone has actually tried it
https://github.com/hendorog/Marlin_L6470

and found a big list of motor drivers here
http://reprap.org/wiki/Stepper_motor_driver

[ag123 – Wed Sep 27, 2017 1:57 pm] –
the other thing would be that TMC2130 seemed to be designed towards a 5v system
https://www.trinamic.com/fileadmin/asse … asheet.pdf
while L6470 it seemed would be easier to interface with 3.3v logic as it seemed to have been designed for it
http://www.st.com/en/motor-drivers/l6470.html

oh and someone has actually tried it
https://github.com/hendorog/Marlin_L6470

and found a big list of motor drivers here
http://reprap.org/wiki/Stepper_motor_driver

I do not checked exactly the datasheet for TMC2130, I now see that power supply should be 5V. But I do not see this a problem, on the shield you just build a 5V power supply that you provide to TMC2130 (5V is needed to drive an LCD). Anyway level 1 logic is 3.3V so I do not think would be a problem to connect the stepper drivers SPI entries to STM32 micro controller.

I read somewhere that L6470 chip driver does not have signals as STEP and DIR which are used currently by Marlin so I think driving them would require some logic change inside the firmware. Could be that I am wrong.

I am in the process of designing a shield for Arduino Due based on https://github.com/dvjcodec/Due3dom-Mini. It will have 5 stepper drivers, 3 fans, 2 Mosfets for hotend and 1 Mosfet for heat bed.

@victor_pv: do you think it would be possible to have a bluepill board driving TMC2130 SPI stepper drivers? Is it possible from the hardware point of view?