Anyone know who I should contact to get a new processor supported in Marlin? I really have been impressed with the ATSAM4S8C in a few other platforms and it saddens me that it isn’t Marlin compatible ATM. It’s a great cheap 32bit processor option that I think we should get implemented.
Post it up here: https://github.com/MarlinFirmware/Marlin/issues/7076
https://github.com/MarlinFirmware/Marlin/issues/7076
@Panayiotis_Savva thank you sir!
@Alex_Skoruppa not really. Just looking at other options. There are lots of Marlin users out there and I feel like we need to push forward with more realistic 32 bit options. This would be a good inexpensive but versatile start.
@Griffin_Paquette as a general principle, I’d personally oppose adding more processors to Marlin if they already have good firmware options and aren’t significantly different from existing Marlin-supported processors. Every chip you add increases the support and maintenance burden, particularly when they’re not mainstream Arduino IDE chips where the build environment is maintained by somebody else.
Even lesser-used Arduino chips can cause problems if they’re not mainstream hardware with lots of serious devs… look at the Due watchdog issues, where you need a custom Arduino IDE profile to get the watchdog enabled for fire safety, because the default Due profile overrides your code’s watchdog settings at compile time and shuts it off without notice. Hardware-specific build quirks and IDE version requirements etc become a significant problem when you try to work on multiple platforms.
This is honestly one of the biggest historical issues with Marlin — trying to do too many different things. Stuff you add for one hardware edge case ends up being abandonware that causes people grief later.
Duet Maestro uses a higher pin count version of this chip. SAM4S8C instead of SAM4S8CB.
I’d rather Marlin be put to pasture because it’s way too entrenched in its 8 bit legacy to take full advantage of 32 bit hardware.
@Jeff_DeMaagd from where I’m standing, it looks like the Marlin devs are basically writing new firmware by replacing a bit of old code at a time… at the end of the day it’s going to be a Ship of Theseus situation and all that’s left is the name and antiquated acceleration algorithms. It’s not an ideal software development approach, but if that’s what it takes to drag people kicking and screaming into the 2010s…
The motion system in Marlin is getting a lot of updates now, no more antiquated acceleration algorithms.
@Oystein_Krog oh yeah? So it’s doing centripetal acceleration control like MachineKit or higher-order jerk control like G2? Or you just mean the same old “constant acceleration slowdowns at corners” scheme from GRBL that everyone (Smoothie included) has been using for the last decade?
I’m not an expert on motion control algorithms, all I know is that people are working on major updates 
I think they are changing from jerk to junction deviation (grbl style) and that s-curve acceleration is already added.
@Oystein_Krog “jerk” and junction deviation are functionally the same and both come from GRBL (different versions), just slightly different calculation methods to determine how much to slow down at corners. Neither works worth a darn on finely-faceted arcs and curves.
@Ryan_Carlyle I think you are over-simplifying it a lot, but I take your point that these are simple algorithms compared to what can be done
I would really love to see a Marlin-klipper hybrid/combination.
Unfortunately klipper (and all the alternatives you mention @Ryan_Carlyle don’t have nearly enough of the features that Marlin does).
I looked up the PRs that were recently merged, and it’s called “6th-order jerk-controlled motion planning for AVR”. Is that what you mean when you refer to “higher-order jerk control”?
There is a lot of stuff happening lately in Marlin, it’s very very active, and it now works on many 32-bit platforms, while still working extremely well on my old AVR. I’m impressed by how they are managing to support both old and new hardware platforms.
@Oystein_Krog Yes, 6th-order jerk control is a step in the right direction (following TinyG/G2 presumably), and it’s good to know that’s merged now. (Although anything over 3rd or 4th order is a waste of clock cycles outside of applications like satellite attitude control…) Still doesn’t address the fact that these firmwares don’t do anything about centripetal acceleration, and execute velocity jumps at corners. Why are we painstakingly restricting accel, jerk, snap, crackle, and pop on the entry and exit ramps to corners, then hammering the gantry with an “infinite acceleration” change in velocity at the corner? And failing to acknowledge stepper or servo following error introduces load-dependent position error way larger than what we’re calculating out for step pulse timing precision? And completely ignoring centripetal acceleration on arcs?
People are missing BIG issues in the motion planner that go all the way back to GRBL, because they’re busy quibbling over microseconds of step pulse timing within the dominant paradigm.
I’m in favor of ANY firmware improvements… just remain kind of perplexed at the effort going into catching up kludgy old Marlin to do what other firmwares were doing years ago, while supporting a billion hacky board types, rather than putting half as much effort into pushing the boundaries with one of the modern controller platforms. But reasonable people can differ on what our priorities should be here.