Hi,
TLTR: I've some doubts about number of pins available, pwm performance, and how to get a gcc-based toolchain.
I have 4 MKS Gen L boards (atmega2560) to drive the 19 steppers of my multitool 3d printer; 1 board = 1 YZ-arm, 4 arms in total, sharing a single X axis. The upgrade goal is being able to use all the arms as a whole single bot and, possibly, to raise the stepping speed to more than 1/16 microstepping.
The MKSGenL+Teensy cost is about the same of buying new specialized boards based on some STM32F4 mcu. But I prefer to have general purpose boards as much as possible. So far so good.
The current issue is that I can't "glue" the boards together and keep the speed decent. Basically the avr cpu+mem+comms triangle is very small; too small. A very simple serial protocol doesn't overload the cpu but requires too much bandwidth (ie: more than 500Kbaud/s available on the tty-USB port), increasing the serial protocol complexity overloads the cpu making the jitter going out of control; and memory isn't really enough to buffer long stepping periods.
So I'd like to upgrade my setup by plugging a Teensy 4.1 on top of each MKS Gen L, then offloading the stepper control from the AVRs to the Teensy and leave all the "ancillary" functions (ie: heaters, sensors, powering, ...) on the AVRs. The idea is to use the MKS Gen L as carrier boards with all the mosfets and connectors already in place and take advantage of atmega2560 pins; after a quick check the Teensy should fit nicely on top of the MKS Gen L using a simple pcb adapter.
After connection I'd have USB and individual stepper pins, connected from MKS Gen L to Teensy USB-host; then the USB-device port of Teensy going to the host computer. In this way the fast realtime control (1us periods) is on Teensy, the slow realtime control (1ms periods) is on AVRs. There's a logic level mismatch to be adjusted (5v <-> 3.3v) but everything could be trivial to connect. The only thing I'm having issues with is to figure out how many pins are truly available without overlapping with the onboard peripherials (USB, SD, ethernet, external psram).
The second doubt is about the real pwm performance. Considering I need to receive data from the AVR twice per millisecond, collate with local data, and eventually forward to host, will I be able to bitbang at 250KHz on 5+ pins with exact timing? On paper the cpu is blazing fast but ... go figure what happens in real world...
The last thing I'd appreciate some inputs about is how to get a gcc toolchain. I currently have all my toolchains tidy and comfy; I use Gentoo's crossdev and I keep the toolchains in shape mostly with crossdev only (x86, arm for RPi and Odroid, AVR; then I manually plugged the ESP32 toolchain in the proper spot). I'd like to have a similar setup for Teensy as well, but I couldn't figure out how to get that. The only howto I've found uses an stm32 docker image to build the NXP SDK... a bit convoluted... is there a way to just build a gcc-libc-binutils-make toolchain from sources?
Any advice appreciated.
Best Regards
TLTR: I've some doubts about number of pins available, pwm performance, and how to get a gcc-based toolchain.
I have 4 MKS Gen L boards (atmega2560) to drive the 19 steppers of my multitool 3d printer; 1 board = 1 YZ-arm, 4 arms in total, sharing a single X axis. The upgrade goal is being able to use all the arms as a whole single bot and, possibly, to raise the stepping speed to more than 1/16 microstepping.
The MKSGenL+Teensy cost is about the same of buying new specialized boards based on some STM32F4 mcu. But I prefer to have general purpose boards as much as possible. So far so good.
The current issue is that I can't "glue" the boards together and keep the speed decent. Basically the avr cpu+mem+comms triangle is very small; too small. A very simple serial protocol doesn't overload the cpu but requires too much bandwidth (ie: more than 500Kbaud/s available on the tty-USB port), increasing the serial protocol complexity overloads the cpu making the jitter going out of control; and memory isn't really enough to buffer long stepping periods.
So I'd like to upgrade my setup by plugging a Teensy 4.1 on top of each MKS Gen L, then offloading the stepper control from the AVRs to the Teensy and leave all the "ancillary" functions (ie: heaters, sensors, powering, ...) on the AVRs. The idea is to use the MKS Gen L as carrier boards with all the mosfets and connectors already in place and take advantage of atmega2560 pins; after a quick check the Teensy should fit nicely on top of the MKS Gen L using a simple pcb adapter.
After connection I'd have USB and individual stepper pins, connected from MKS Gen L to Teensy USB-host; then the USB-device port of Teensy going to the host computer. In this way the fast realtime control (1us periods) is on Teensy, the slow realtime control (1ms periods) is on AVRs. There's a logic level mismatch to be adjusted (5v <-> 3.3v) but everything could be trivial to connect. The only thing I'm having issues with is to figure out how many pins are truly available without overlapping with the onboard peripherials (USB, SD, ethernet, external psram).
The second doubt is about the real pwm performance. Considering I need to receive data from the AVR twice per millisecond, collate with local data, and eventually forward to host, will I be able to bitbang at 250KHz on 5+ pins with exact timing? On paper the cpu is blazing fast but ... go figure what happens in real world...
The last thing I'd appreciate some inputs about is how to get a gcc toolchain. I currently have all my toolchains tidy and comfy; I use Gentoo's crossdev and I keep the toolchains in shape mostly with crossdev only (x86, arm for RPi and Odroid, AVR; then I manually plugged the ESP32 toolchain in the proper spot). I'd like to have a similar setup for Teensy as well, but I couldn't figure out how to get that. The only howto I've found uses an stm32 docker image to build the NXP SDK... a bit convoluted... is there a way to just build a gcc-libc-binutils-make toolchain from sources?
Any advice appreciated.
Best Regards