Marlin: replicape + beagleboard support

[gladio145]

It would be nice if the replicape can use the Marlin firmware rather than exclusivity Redeem firmware

[bobc]

Beagleboard runs a Linux environment, which is completely different to the microcontroller environment of Arduino and similar boards. To implement Marlin as a user-space application on Beagleboard is more or less a rewrite, certainly large chunks of code would need to be rewritten. I don't see it as a very practical proposition.

In order to avoid the X-Y problem, what are the benefits and features of Beagleboard/Replicape that are desirable?

[gladio145]

I understand the certain change in code, deep inside someone in this section would say that. However if so considered despite the struggles, Marlin will benefit from a very high computational powered board (more reliable and smooth operation) with further possibilities to add i.e. a sleeker screen UI with say Kamikaze, octoprint host, etc..

Again, I'm aware of the challenges, but wouldn't have opened the suggestion if it wasn't a cool idea (at least what I think)

[p3p]

@bobc The beagleboard is a really nice bit of hardware and it's a brilliant idea coupling a CPU and MCU so close together allowing it to have fast realtime IO access running on the PRU with the main CPU handling all the asynchronous interfacing.

@buttigieg94 saying that bobc is still right in saying it would not be a simple process to get the marlin running on a beagleboard + PRU, we would have to split out just the realtime features onto an MCU that is not currently supported and then implement an entirely new Interface layer that could run on linux. It would take a lot of time and effort and be impossible to have in the main code base while maintaining backwards compatibility with current platforms. So I'm afraid this is very unlikely to be implemented.

[gladio145]

@p3p I'd rather be straight forward and truthful say that its not a simple task (even tough deep inside I want the developers to ship the idea) rather than sugar coat things and make them think its a bad idea. I respectfully laid out my idea to support my proposal now its up to them.

@bobc By all means did I implement or meant (at least unintentionally) the idea to be implemented in a short term goal, but rather in a work in progress... sort of. Then again its up to you guys the developers

[bobc]

Sure, the Beagleboard is nice hardware, but it is just one way of achieving real time speed, and the architecture is proprietary to TI. Even with PRUs, there is still the problem of getting access to hardware from user-space application.

If it is just a question of exploiting faster hardware, what is wrong with Redeem?

[gladio145]

@bobc
Being a user of Marlin from the very beginning, the Marlin firmware has evolved dramatically because of you guys the developers. Comparing Marlin with Redeem, you guys have more developers evolving the firmware even when its already great. Doing so would ensure current user that the Marlin developer will come up with new idea and more importantly even when the hardware is also evolving.

Redeem has nothing wrong with it, and what some of my friends using it on their deltas say, I haven't heard them complaining too much. So in short you guys have the man power to evolve the firmware with daring new ideas, whereas other firmware developers don't have that luxury.

[bobc]

Sorry, but I really think this is a dead end. We have to accept that Marlin is not going to run on every platform.

If you have a specific feature you want to see in Marlin, then please raise it, but if you are just trying to recruit developers for new projects this is not the place.