@Owen_Williams I like the DRV8316… there’s a working design I did here:
its in the shape of shield for Arduino MKR sized boards.
There’s also a design by Adin here:
https://community.simplefoc.com/t/samd21-drv8316-board/1086
which has an on-board SAMD21 MCU. Check his thread if you want to use the buck to power the MCU and have the system self-start 
I agree with you on this @JorgeMaker, I would not add Klipper code to the main SimpleFOC library. I think only a small proportion of users would be interested.
But for those that are interested in this, I think we could make a Klipper-SimpleFOC library which builds on top of SimpleFOC. But someone would have to want to invest the time and effort not only to do the code, but also the examples and documentation… I think it would be a big project in the end.
I very much agree with modularity and separating libraries is part of that. I do however think that a driver that can accept G-code like commands looks like it’s particularly useful. There seems to be a trend down this road with stepper motor drivers and so on. Ultimately it’s more modules, more kits, if good modularity is employed more modules never hurts, you use which ones you need and when and extra ones don’t slow anything down or whatever. We are not at the stage where we need to worry about clutter in the ecosystem. The main thing is indeed the amount of work vs the priority level. Being fairly well acquainted with CNC machines and their electronics, you can generally get your module that interprets G-code and controls the dumb robot made as the ecosystem stands. Controlling the motors directly with grbl or linuxcnc or Marlin is in the bag already and having communication interfaces as is done between the tmc2209 chips and marlin in some cases has downsides. I know it prevents the use of linear advance for instance because you can’t update the speed of the stepper motor quite fast enough to do that kind of detailed motion stuff. I think input shaping could also be harmed by such an approach. I think the best approach in that exact context, where very precise motor control is required, is a blazing fast processor and everything from gcode to step/dir or whatever on one chip.
I agree with all of you regarding Klipper. It’s awesome to be amongst such wisdom in programming.
@JorgeMaker it will be fun to see how we can use the existing step format from Klipper. I think we just have to look at is as a variable rad/resolution, which should be set according to encoder resolution. So instead of sending actual step pulses to the TMC driver or what ever. We send move commands within the context of the machine dimensions. How this performs is a great unknown. Maybe it is best suited for dual core MCUs. But then again, why not move the conversion to the mainframe and send out floats to the MCU…
Thinking some about this, @runger I agree the workload to make Klipper talk SFOC (rad’s in floats) is a huge undertaking, nonetheless something that is possible and could be a option down the line. Maybe the Klipper community is not all interested in this, and would rather just remain in the comfort of the proprietary stepper drivers. The fastest way to actually showcasing it, is definitely going with the step format and conversion to rad’s.
@Owen_Williams hope it’s ok that we wrap this theme up in here. I’m looking forward to see your progress!
@Anthony_Douglas
I agree, the potential is there. Let’s unlock it.
A side note, since breaking in the Field Stack I did manage to completely mess up my sleep, so I’ve been somewhat short tempered. It’s all good. Keep up the great work.