Cudów nie ma, jak arduino ma 2kB pamięci, to parsowanie gcode na nim można robić co najwyżej dla sportu. Podobnie z prędkością przetwarzania - może i potrafią wysyłać impulsy do 30kHz bez jitteru, ale ile segmentów na sekundę mogą przetworzyć, to już się nie chwalą...
Ja mam w tej chwili w swoim sterowniku miejsce na 1200 rozkazów, które już zawierają wstępną obróbkę (wyliczone prędkości i przyśpieszenia). GRBL ma planowanie na 18 segmentów, czyli w gruncie rzeczy bardzo mało, przy większych prędkościach szacowanie prędkości w przód może wymagać większej liczby segmentów.

No, ale widzę, że kolega też ma rozdzielone przetwarzanie między PC i µC. Poza tym ARM Cortex M3 120MHz jest o 3 klasy wyżej od AVR. Jest chyba kilkaset razy szybszy i ma pewnie 64x więcej pamięci.

Pisanie programów na AVRy jest jak rozwiązywanie sudoku. Rozwija umysł, bo uczy operować w ograniczonym środowisku, gdzie niewiele da się zrobić na chama i wszystko trzeba trickami. Z drugiej strony, przydatność programowania AVR jest podobna, jak rozwiązywania sudoku
Tak bardziej serio: pisałem interpolator krzywych sześciennych Beziera na AVR - owszem, udało się, ale ogromna ilość przetwarzania wstępnego była robiona na PC; dane wstępnie obrobione szły do AVR, który tylko i wyłącznie dodawał a i tak ledwo starczało mu na to czasu. Obsługa USARTa w wyraźny sposób wpływała na prędkość obliczeń. Obliczenia prowadziłem w wątku głównym, bo obsługa przerwania zegarowego wprowadzała za duży narzut.
O interpretacji G-kodu i pełnym wyliczaniu trajektorii wraz z rampami etc można zapomnieć - to musi zrobić duża maszyma. Jak nie PC, to raspberry pi - to zadanie wymaga zarówno sporej mocy obliczeniowej jak i pamięci operacyjnej, którymi mikrokontrolery nie dysponują.
Może kolega próbować szczęścia z STM32F4, ale nadal nie wiem po co - lepiej już zrobić jakiś mały preprocesor (postprocesor? zależy, jak na to patrzeć) na PC a urządzeniu na USB zostawić prostszą robotę.