Just wondering why is Marlin 2.0 FW moving so slow to alpha and release?

Just wondering why is Marlin 2.0 FW moving so slow to alpha and release?
Is the need for 32 bit controllers limited?
Are there major issues porting over the 8 bit code?

I have been chomping at the bit since 2017 to upgrade all my printers to 32 bit and just waiting for the 2.0 FW and the best controller that will work the best. Is there a controller today that will will work with no issues today with Marlin 2.0? The new MKS SBASE looks good on paper providing a single board 32 bit design, replaceable stepsticks and the same processor as the re arm

Just find a board that's listed with a green heart in the first post of https://github.com/MarlinFirmware/Marlin/issues/7076 and have at it. The current state of the bugfix-2.0.x branch is very usable, both with 8 and 32 bit boards. I've been using it on my RAMPS/Mega2560 combination with no issues at all.

One of the main objectives of the move from Marlin 1.x.x to 2.x.x is to do some major restructuring of the entire code base.

Such a restructuring is a major undertaking, and can basically be done in one of two ways:
- you can re-start from scratch, and re-program everything.
- you can implement a new structure, by slowly and meticulously move one procedure/module at a time over to the new programming structure/method, and then, at every step of the way, test that you have maintained the very same functionality, on every combination of hardware.

As new, modified or improved functionality is however continually also being added to the old code base, and thus also needs to continually also be implemented in the new structure, it becomes an even more lengthy process to reach a point of complete restructuring of the new code base.

And if that was not enough, a secondary goal (or perhaps it was actually the primary goal, causing the need to restructure in the first place), a shift from one 8-bit processor to multiple types of 32-bit processors are also being implemented.


All in all, not a small undertaking. And thus, it will take the time that it will take!


So what you probably should do, is get familiar with what hardware platforms, and what core functions are known to be quite stable, in version 2.0.0, and then use that platform for your 32-bit move.

And I would focus on open source platforms. Otherwise it will be very difficult for the community to try give you any answers to any potential problems you might run into, as you try to keep your new 32-bit platforms updated.


Can you not get the same functionality, using open source hardware, as you can, using the "MKS 're-ARM' Base" all-in-one board?
Are extra functionality built into the MKS Base boards?

This is a major undertaking, so it'll take a while.
I've used Re-ARM with 2.0 and had very few issues, Chris' Basement has some really good videos on setting it up.
Re-ARM is a direct plugin if you're using ramps, otherwise Bigtree has some 32 bit boards around the $25 mark.
Issues I encountered were, need to modify the display cable as per instructions found on Google, had to reduce max Z speed to 3 or Z would stall on lift - no idea why.
You need to move to PlatformIO for compiling and upload, I would recommend using Visual Studio Code with PlatformIO, it has been suggested that Atom is moving away from PlatformIO so you will have to eventually change anyway.
The big benefits are speed and no stalling on circular movements.
I wouldn't go back to 8 bit now as 2.0 bugfix seems stable enough.

Edited 1 time(s). Last edit at 09/26/2019 07:04PM by davepaxz.