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
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
JustAnotherOneQuote
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
JustAnotherOneQuote
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.