SmoothieWare Compatible Mainboards

Quote
JustAnotherOne
So having something that runs on 8 and 32 bit is unrealistic. It might be possible, but it then can not be high performance on both chips.

Uhm. You don't really mean this, do you? The whole world is full of software which runs on various bit-widths from the same source code. Changing that is just a matter of a compiler flag. For MCUs also a matter of adjusting to timer names, interrupt names and such stuff, but that's it.

Quote
JustAnotherOne
Especially as I haven't seen Teacup run on anything 32bit.

Here you go: [reprap.org]

Quote
dc42
Likewise, printers running Duet electronics sound smoother since I changed the firmware from using the Bresenham algorithm to calculating the step times precisely (to about the nearest microsecond) - for example, see [forums.reprap.org]. The limiting factor in achieving this is the time taken to calculate the square root of a 64-bit number, which needs to be done for every step during the acceleration and deceleration phases.

Sounds even smoother than "smoother". Teacup demonstrates how acceleration calculations need no 64-bit square roots and also doesn't need to calculate that between every step. Doing this calculation 500 times a second is entirely sufficient to comply with physics. This gives you something like 10'000 clock cycles per calculation, plenty of time.

Maybe it's time to combine these two.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote
Traumflug

Quote
JustAnotherOne
So having something that runs on 8 and 32 bit is unrealistic. It might be possible, but it then can not be high performance on both chips.

Uhm. You don't really mean this, do you? The whole world is full of software which runs on various bit-widths from the same source code. Changing that is just a matter of a compiler flag. For MCUs also a matter of adjusting to timer names, interrupt names and such stuff, but that's it.

Oh yes I do. And you should not listen too much to the marketing guys. The world is not full with multi bit width applications. As I said multi bit width support is possible but nobody really want that due to the restrictions that come with it.

I thought you cared for best performance. At least the compromises made by Marlin to get the best out of AVR is what you critisize on Marlin.

On 8 Bit you can do a very efficient ring buffer by making it 256 Bytes in size. This way you can always do a ++ on the read and write pointers. The same on 32 bits would ask for a 4GB Buffer.

On an 32 bit processor each variable is 32 bits. So handling 8 bit variables is actually harder than to do the same in a 32 bit wide variable.

The AVR has problems when doing multiplication on 16 bit variables. The 32 bits also come with hardware floating point,...

Should I go on or do you see the difference?

Quote
Traumflug

Quote
JustAnotherOne
Especially as I haven't seen Teacup run on anything 32bit.

Here you go: [reprap.org]

May I cite what that page is saying:

"This page describes something which is no longer the most recent version. For the replacement version see: Gen7 Board-AVR 1.5"

Do I have to say more? But I can understand your decision if going on ARM was just changing the compiler switch and doing a search and replace on the timer names,..

Quote
Traumflug

Quote
dc42
Likewise, printers running Duet electronics sound smoother since I changed the firmware from using the Bresenham algorithm to calculating the step times precisely (to about the nearest microsecond) - for example, see [forums.reprap.org]. The limiting factor in achieving this is the time taken to calculate the square root of a 64-bit number, which needs to be done for every step during the acceleration and deceleration phases.

Sounds even smoother than "smoother". Teacup demonstrates how acceleration calculations need no 64-bit square roots and also doesn't need to calculate that between every step. Doing this calculation 500 times a second is entirely sufficient to comply with physics. This gives you something like 10'000 clock cycles per calculation, plenty of time.

You assume here some magic Frequency of 5 MHz. Why?
So this Teacup Algorithm is "entirely sufficient to comply with physics" where the Marlin compromise of doing up to 4 steps in a single ISR invocation is not OK for you. (I also hate that) But I can assure you that Marlin complies with the laws of Physics ;-)

The real question here is if we have Cheap 32 CPUs with over 100 MHz and hardware floating point do we really need to make any kind of compromise?

Quote
Traumflug
Maybe it's time to combine these two.

I don't understand what you want to combine here. But having a discussion about the best algorithms for Step generation, acceleration, jerk,.. would be very interesting. Lets Do that instead of fighting over 8bit vs 32 bits.

Quote
JustAnotherOne
On 8 Bit you can do a very efficient ring buffer by making it 256 Bytes in size. This way you can always do a ++ on the read and write pointers. The same on 32 bits would ask for a 4GB Buffer.

I see no reason why I couldn't do a ++ on a 32 bit pointer on a 8-bit CPU. Results in (I think) 8 assembly instructions, but the compiler takes care of that. It might require to lock interrupts if you read this buffer from elsewhere, of course.

Quote
JustAnotherOne
The AVR has problems when doing multiplication on 16 bit variables. The 32 bits also come with hardware floating point,...

Yes, 32-bit CPUs are faster, no doubt on that. Not only because of the faster clock, also because the above ++ results in just one CPU instruction there.

Quote
JustAnotherOne

Quote
Traumflug
Here you go: [reprap.org]

May I cite what that page is saying:

"This page describes something which is no longer the most recent version. For the replacement version see: Gen7 Board-AVR 1.5"

Do I have to say more?

Obviously you see a different page. Here this page reads "Page creation in progress. Status: first circuitry design & board done." Perhaps the direct YouTube link helps: [www.youtube.com]

Quote
JustAnotherOne
But I can understand your decision if going on ARM was just changing the compiler switch and doing a search and replace on the timer names,..

That's what these 3 ARM ports of Teacup pretty much do. They share some 95% of the code with ATmegas.

Quote
JustAnotherOne

Quote
Traumflug

Quote
dc42
Likewise, printers running Duet electronics sound smoother since I changed the firmware from using the Bresenham algorithm to calculating the step times precisely (to about the nearest microsecond) - for example, see [forums.reprap.org]. The limiting factor in achieving this is the time taken to calculate the square root of a 64-bit number, which needs to be done for every step during the acceleration and deceleration phases.

Sounds even smoother than "smoother". Teacup demonstrates how acceleration calculations need no 64-bit square roots and also doesn't need to calculate that between every step. Doing this calculation 500 times a second is entirely sufficient to comply with physics. This gives you something like 10'000 clock cycles per calculation, plenty of time.

You assume here some magic Frequency of 5 MHz. Why?

Because I try to think conservatively. And didn't want to start a discussion wether 40'000 clock cycles are actually achievable with heaters, G-code parsing and all this stuff happening in parallel. :-)

Quote
JustAnotherOne

Quote
Traumflug
Maybe it's time to combine these two.

I don't understand what you want to combine here. But having a discussion about the best algorithms for Step generation, acceleration, jerk,.. would be very interesting. Lets Do that instead of fighting over 8bit vs 32 bits.

Combining, like joining @dc42's Bresenham-less code with Teacup's 500-calculations-a-second-only code.

And yes, I fully agree that discussing algorithms suits development much better.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Here´s another SmoothieWare Compatible Mainboard Candidate from China looks pretty good :-) 68 $

MKS board SBASE [www.aliexpress.com]

:popcorn:

Does teacup run on a Due with RAMPS shield?

I've got one sitting, doing nothing...

While there seems to be a p***ing match going on in this thread, it is a fairly polite p***ing match and I am learning quite a bit about Smoothieware and Duet firmware capabilities. I'd like to see a Duet vs. Smoothie comparison, similar to what we know about Marlin vs. Repetier.

8-bit boards are pretty good, but I watch mine stutter when they get a bit busy and there is no doubt that the new higher speed 32-bit boards have much more room to grow. I have another thread open with questions on which way to go, so I won't repeat myself here. I will just keep watching for more interesting information to come out. (Duet guys, do you want to pitch in more info?

thanks,
DLC

Quote
dlc60
(Duet guys, do you want to pitch in more info?

This thread is specifically about Smoothieware-compatible boards, so it would be thread hijacking/OT for me to pitch in here. I suggest you use this thread [reprap.org] instead.

Edited 1 time(s). Last edit at 06/07/2018 11:58AM by dc42.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].