32bit branch

[p3p]

I've used the 32bit HAL branch by @bobc to partially port Marlin to an ST-Nucleo F746ZG just enough features to use it with my machine (ramps 1.4 features + graphical display) and am curious whether there are plans to merge that branch into the main 32bit dev branch and keep it inline with rcbugfix, it would be nice to have an official branch that can be contributed to.

I realise that the 32bit branch is aimed at 32bit Arduino and I'm probably the only person running Marlin on an ARM Cortex M7, but the HAL made it so easy to port (even with the arduino wrapper) I think its worth moving forward with. (I should add my port is not something I would ever want merged, it was just a proof of concept for myself)

[Roxy-3D]

We don't know exactly how this is going to evolve. But the direction we are trying to go is both the 8-Bit AVR version and the 32-Bit ARM version will use the same code base. We won't be able to 100% accomplish this. But we are hoping to keep the only difference between the two versions at the HAL (Hardware Abstraction Layer).

Ideally... Any work you do and contribute will be focused on abstracting the hardware differences from the higher level layers of the main code base.

but the HAL made it so easy to port (even with the arduino wrapper) I think its worth moving forward with.

Yes... That was the agreed upon strategy. And with a little luck, we may ultimately be able to add more processor families to the mix. But for right now, our goal is to get up and running on an ARM processor. Any contributions you can make to the HAL will be considered!!!

[p3p]

The actual changes to https://github.com/bobc/Marlin/tree/32-Bit-RCBugFix were minimal (and hacky and often temporary) even in its unfinished state, and that was compiling outside the Arduino environment having to emulate some of its libs, the vast majority was contained in the processor specific folder structure supplied as you mentioned.

I'm mostly interested in having an official HAL branch that I could be confident wouldn't be forgotten about, At the moment I'm just happy having my printer running so well even without any optimisations.

[JustAnother1]

@Roxy-3D If I get you right what you are saying would mean that we can see the "32-Bit-RCBugFix" being merged into the "RCBugFix" tree and finally in the next release. Is that the plan?

If so then when will we see it. I assume many people are holding their breath and wait for it to start playing with it. But then it seems as if @bobc stopped working on it last year. Is there anything that I or others can do to speed the process up? What kind of help is needed?

If the plan is to not have a separate 32bit branch, then merging these first changes back into the next release, even if there are "dead code" in there would IMHO be a good way to make it clear to everyone that this time 32bit will really happen in Marlin.

[Roxy-3D]

In a perfect world... We would have a HAL to support any processor family Marlin supported. We would simply enable which ever HAL is needed and compile the entire code base with the appropriate compiler and flags.

If something needs to be changed in the Marlin code base to run on a given processor family, it probably deserves closer scrutiny. If it is something that needs to be changed because it reaches down and touches the hardware, it is pretty clear (to me) that type of thing the code is trying to do needs to be moved down into the HAL and if so, now the higher levels of the Marlin code can be the same.

I know we aren't going to be able to accomplish this entirely. But if we can mostly move in that direction, we will be able to keep the code base from fragmenting.

I understand what you are saying about merging things back into the next release. But I'm kind of seeing it differently. If we can get a 32-Bit HAL in place and the existing code limping along, it won't be hard to refresh that code set with what ever is the 'Current' release level. And probably, it would be a single focus point release that took the 'Current' release level and put multiple HAL's underneath it.

BobC posted that he was super busy. I'm hoping he gets some free time! But it is encouraging that @p3p was able to take Bob's work and get something limping along! That sort of implies we are close to seeing some light come out of the tunnel!

[JustAnother1]

@Roxy-3D You might understood me wrong. What I was meaning was that if the strategy is to only have one version with HALS for all supported CPUs, so also a AVR HAL then and only then I suggested to merge as soon as possible.

If I understood your last comment right, then what you plan is to have a 32bit branch in parallel with the "main" AVR only branch. If that is the plan then I would suggest that this parallel branch should be labeled as the official 32bit Marlin branch.

My impression is that right now the situation is confusing. People have invested effort to port marlin to non AVR targets. There are some branches with the code. Then @bobc started a pull request that right now seems to be the starting point of what should become the 32bit marlin. And then people like @p3p again invest into this codebase. And now we have the problem of where to put these contributions. Is that what you are saying?

I respect that @bobc is busy at the moment. And we should thank him for the work he has put in. But maybe we should not solely rely on him. Having an official branch that can merge not only bobs but also p3ps work would probably help. And bob is probably not sad if we did some of the work he planned to do for him.

So we are not in disagreement here. I'm perfectly fine with whatever branching model marlin thinks works best. And I don't have a say in this, as I sit at the sidelines waiting for a chance to contribute.

[Blue-Marlin]

As far as i know the plan is to finish Marlin 1.1 with some bug fixes and not throwing in new features. After that new features are applied for the next release. Where bugfixes are for example:

• Ensure the temp-interrupt is not called before it has finished or, al least, refuses to reenter.
• bilinear ABL is done with extrapolating the last probed point to the outer area.
• M600 is working.
• ...

New features, currently under development, are:

• UBL
• 32bit support
• tool changes
• further general CNC support
• ...

Opinions may vary.

Despite of this, it makes sense to be with the feature branches as clo(s)e to RCBugFix as possible. Otherwise a later merge is difficult (,as you will see with UBL).

Hopefully the 32bit port can make use from the more interrupts and timers of the 32bitters even if not in the HAL. Marlin is currently a huge workaround around the limitations of the ATMEL Megas. More hardware SPI ports, DMA ADC readings, hardware floating point operations, ... allow other concepts - what can not be only hiden behind a HAL. An other dream for the over next release is to cut out the support for the 64K processors. That would allow us to support multiple languages at the same time. What would be precious for hardware vendors trying, not only supporting one country. In general it would relax the requirement of saving memory for everything. (For the currently planed release we need to some how limit the points ABL probes. Otherwise we will permanently get complains about 'strange' errors.)

[Blue-Marlin]

@Roxy-3D @thinkyhead Please at least merge the @bobc PR into the '32-Bit-RcBugFix' branch to make it official an encourage him. An empty branch does not help anyone.

[Roxy-3D]

Please at least merge the @bobc PR into the '32-Bit-RcBugFix' branch to make it official an encourage him. An empty branch does not help anyone.

I merged his previous work too soon and caused problems. I've tried to make bobc an administrator of that branch so he can easily do what ever he thinks is necessary. BobC is the one that said "Do Not Merge!" on that branch.

So... Until I hear differently from BobC... It should not be merged. BobC knows I'll merge the branch as soon as he says he wants that to happen.

Moving Marlin to 32-Bits is very important to me.

[teemuatlut]

Those of us who would like to contribute a new platform into the HAL, how should we proceed with it? After BobC's fork gets merged into the official repo, would then be good time to make a pull request?

[Roxy-3D]

@teemuatlut I did not want to disrupt Bob's work by doing a merge when he requested that did not happen... But if you have significant improvements to Bob's work, can we see them? That might warrant a merge.

[p3p]

I understand @bobc not wanting his work merged prematurely, and there are a lot of things left to be properly abstracted, (including everything to do with Arduino) its just a bit frustrating that there is a viable branch to work on but its already getting left behind, forgotten about, at the bottom of the second page of pull requests.

[Roxy-3D]

@p3p @teemuatlut Please give us a Pull Request to look at. With that, we can figure out the right way to push this forward.

[teemuatlut]

Teensy HAL fork. This is based on the fork by BobC and its' intention was to be compatible with the HAL so that it can easily be merged when the time comes.

RCBugFix teensy fork. This is my original fork from RCBugFix that aims to add support for Teensy3.5 and Teensy3.6 and my intention is to keep it up to date with upstream until you guys decide to make the HAL official. There are people developing the required hardware and this would mostly benefit them.

Both are able to auto merge and both are passing all the travis tests.

edit: Added link to travis page.

[Roxy-3D]

@teemuatlut THANK YOU!

[p3p]

I changed little in bobc's branch, just added the expected function definitions for my platform (https://github.com/p3p/Marlin/tree/32-Bit-RCBugFix-F746ZG), so I think a pull request would just confuse matters further. Also with it being STM32 based I used a separate build system.

[thinkyhead]

If @bobc is very busy, we may simply be able to continue forward with the other expertise at our disposal. Clearly we have some savvy enough programmers here.

[psavva]

And don't forget a savvy tester, who is a programmer as well, just not in C, yet... :(

I have the RE-ARM which I could help with testing on a Cartesian printer.

I'm also prepared to buy another couple of 32 bit boards as things move along.

Is there anywhere I can get some sort of pluggable board for the teensy to wire up the printer. I could get a teensy as well, since its limping for now :). Well done @teemuatlut

[teemuatlut]

@psavva Sadly no, not yet. There are however some people who are developing boards for this purpose and it'll be encouraging for them if there is interest towards this. Personally I just ordered a simple mega prototype shield for a dirt cheap method of routing the pins.

[psavva]

Any update how we move forward with the 32bit Development?

[p3p]

We have bobc's HAL in 32-Bit-RcBugFix now, and I've put a pull request in that brings it upto date with RcBugFix, so the main focus after that should be isolating the rest of the hardware dependant parts, and bringing them into the HAL layer, making sure the avr platform performs identically to the normal branch, then finish off Due support. We also need to pull out everything Arduino and move it to a framework header in the HAL. Then it should be plain sailing to implement other platforms.

Of course I fall at the first hurdle there, as I don't have a Due or RADDS boards to test on atm, and have skipped ahead to implementing the STM32F7 platform because that's what I built my 3D Printer controller out of, but at least we are moving forward ;).

[Roxy-3D]

Of course I fall at the first hurdle there, as I don't have a Due or RADDS boards to test on atm, and have skipped ahead to implementing the STM32F7 platform because that's what I built my 3D Printer controller out of, but at least we are moving forward ;).

Yes! But just getting ANY 32-bit platform up and running helps a huge amount. Once any 32-bit processor is liming along, making changes to get the next one going is much easier because you are not trying to eat the whole elephant in one sitting. You 'just' fight the next problem keeping things from coming up further.

[JustAnother1]

@p3p I did some work on stm32F4 HAL. Once building 32bit Marlin using (c)make is working I hope to contribute myself.

If I can help you in the meantime then please let me know.

[p3p]

@JustAnother1 I'm keeping the stm32 stuff separate (It's a mess but I'm updating the HAL as I find things) as it does require an eclipse stm workspace project atm, but in theory, you could pull it down and open the ioc file in stm32cube setup your microcontroller and pins(the next thing to work on for the platform) and it would work fine, I'm currently printing with that branch. (with that specific config ;))

[JustAnother1]

A mess that works can't be that bad. You seem to be rather close to the ST HAL.

I did something completely different. But that is my mess but i like it ;-)

I use Eclipse but my HAL does not depend on Eclipse. All that is needed is make and gcc. a make help gives you the details.

[thinkyhead]

Doing a rebase of 32-bit code onto the latest code-base. It needs some testing before it can be merged. At #5877

[p3p]

As you have addressed my original issue (moving forward with 32 bit) I'l close this now.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.