ambrop72
commented
8 years ago Hi, Thank you for interest in my software.
I have to admit that I'm not that fond of separating functions into a secondary processor. On the one hand, one typically needs this only to achieve high performance not many people may need, and on the other hand when done, it restricts the future design of the software, and may be highly coupled to specific hardware. So please understand that I prefer to work on features where you stay in a single processor.
I agree that my firmware may be more suitable to implement this due to the modularity and abstractions. But those abstractions were designed with one processor in mind. So while it may look like you could replace the AxisDriver component (responsible for step timing) with something that communicates with another processor, this is not so easy because AxisDriver relies on something else (MotionPlanner) to provide a buffer of commands in memory, and it only asks for the "next command" when one is finished.
It may be easier to use a coprocessor with shared memory. The LPC processor that Smoothieware v2 uses has this, with a primary M4 code and secondary M0 core, which one may use for stepping. Anyway I definitely think using an AVR is a bad idea, due to its slowness.
Regards, Ambroz
jsb1
Hi Ambroz,
congratulation to that code!. It shows me that C++ is usable again and really good on controllers (I dropped that language before it hat good templates).
My Idea is to run a firmware an two processors: a simple and cheap one does the real-time part (mostly do steps, measure temperatures, switch heaters). The other one does complex calculations like coordinate transforms for delta with bed level corrections, etc. A powerful processor could even do 3d-splines to correct some bad hardware geometry. It should also run the PIDs for temperature control (the is no really hard timing requirement). A little bit tricky will be endstops - should be real time or?
The low-level processor can be a cheap avr board like ramps+atmega328. The high-level processor could be a rasberry, an arduino-tablet or even an old android-phone. Cool would be an esp8266. It has al lot of computing power and (program-)memory compared to avr and cost nearly nothing...
aprinter seems to be a good starting point due to it's modularity. Were would You put a binary interface? I would do serial communication over uarts in first step.