Doing some electronics testing now…have the Arduino Due, RAMPS-FD v2.2 (the one I built a while back), a 128×64 LCD module (the usual ReprapDiscount design), and a Raspberry Pi 3 B+ all hooked together, with OctoPrint running on 64-bit Gentoo on the Raspberry Pi.
- At some point, something changed in Marlin such that it now doesn’t want to write to the EEPROM. M500 throws an error: “field esteppers mismatch” [sic].
- The SD-card slot in the display works well enough to get a listing, but not to read or write files, which makes it kinda useless. I reworked the display adapter a little to use a different chip (a 74HCT244 instead of a 74HC07) that was more readily available, but could this substitution affect SD-card performance? Should I try whacking in a 74HC244, or should I go back to the original design and hope I can find 74HC07s somewhere?
On the other hand, I did get OctoPrint to talk to the Due/RAMPS stack over the Due’s native USB port, which is much faster than the “programming” port that uses the same ATMEGA16U2 as in the 8-bit Arduinos. (Marlin images are burned through the native port in about 4 seconds, vs. 32 seconds when going through the AVR.) I had to patch OctoPrint’s firmware updater plugin to talk to the native port; those changes have been put in a pull request. Maybe faster communication between the Raspberry Pi and the Arduino Due’s native USB port will mitigate the need for the SD-card slot when running complex print jobs.