February 2015 and the Raspberry Pi Foundation has just released a quad-core ARM Cortex-A7 version of the Raspberry Pi for the same low price of $35. It runs Debian Linux armhf (32-bit) quite properly.
I personally believe that using a combination of a Raspberry Pi quad-core running Linux and a more than proven AVR Mega for realtime tasks together would provide any RepRap with more than enough processing power and connectivity options required for the foreseeable future - all that at an unbeatable price.
- Yes. And it's almost trivial to replace such an ATmega with some 32-bit CPU, as Gen7-ARM and 3DPCB show. Then not even polar or delta printers should experience a processing power bottleneck. --Traumflug (talk) 04:53, 3 February 2015 (PST)
- Hi Markus, I was not aware of the existence of the Gen7-ARM, it seems like a really interesting controller board. I hope it is further developed and can be offered as an economical 32-bit alternative to what we have right now. But, a single ARM M0 core @ 50MHz is rather far from a quad core ARM Cortex-A7 @ 900MHz in terms of processing power. So I am still of the opinion that combining a multicore ARM SOC on a mass-produced board with an AVR 8-bit MCU-based Arduino (also mass-produced) offers - in February 2015 - the best combination of processing power, cost and feasibility. Of course things can (and do) change very quickly, let's see what the coming months bring us in terms of developments in this area. --AndrewBCN (talk) 06:14, 4 February 2015 (PST)
- Markus, I have a question for you, which is why can't we do all the 32-bit integer calculations on the quad-core RPi running Linux (where we can also do 64-bit integer and floating point math as well if needed) and just send the "pre-calculated" stepper movement commands to the 8-bit AVR or 32-bit ARM M0 running their dedicated real-time firmware? Wouldn't this make more sense than trying to have a single processor doing all the work? --AndrewBCN (talk) 21:23, 4 February 2015 (PST)
- It boils down to speed of communications. The closer to step pulse generation you get, the higher realtime demands are, the faster communications has to be. With this in mind, you can do stuff like path splitting or transformations cartesian -> delta on the host, but the movement itself has to happen on the CPU firing the step pulses. There you have the Bresemham algorithm, acceleration calculation and, for advanced algorithms, following curved movements. Note: moving a straight line with the head of a delta or polar robot means a curved movement for the stepper motors. In theory you have to change direction after every step. --Traumflug (talk) 03:36, 5 February 2015 (PST)