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.