Marlin boards

Hi.
Re: Marlin, external Stepper-drivers and controlling them directly from the Arduino (MEGA R3).
Moving along ....
If I change pin use in the pins_ file, do I also need to redefine which pins are input and output aswell ? If so, where ?
I am building the hardware as I move along, so I would like to be able to test each axis, endstops, heaters etc without anything else affecting the operation..
Please advise.

The pin names are standard names and Marln knows to set those as input/output as required

E.g., X stepper driver pins

see Marlin/src/module/stepper/indirection.h

// X Stepper
#if HAS_X_AXIS
  #ifndef X_ENABLE_INIT_STATE
    #define X_ENABLE_INIT_STATE !X_ENABLE_ON
  #endif
  #ifndef X_ENABLE_INIT
    #define X_ENABLE_INIT() SET_OUTPUT(X_ENABLE_PIN)
    #define X_ENABLE_WRITE(STATE) WRITE(X_ENABLE_PIN,STATE)
    #define X_ENABLE_READ() bool(READ(X_ENABLE_PIN))
  #endif
  #ifndef X_DIR_INIT
    #define X_DIR_INIT() SET_OUTPUT(X_DIR_PIN)
    #define X_DIR_WRITE(STATE) WRITE(X_DIR_PIN,INVERT_DIR(X, STATE))
    #define X_DIR_READ() INVERT_DIR(X, bool(READ(X_DIR_PIN)))
  #endif
  #define X_STEP_INIT() SET_OUTPUT(X_STEP_PIN)
  #ifndef X_STEP_WRITE
    #define X_STEP_WRITE(STATE) WRITE(X_STEP_PIN,STATE)
  #endif
  #define X_STEP_READ() bool(READ(X_STEP_PIN))
#endif

Marlin calls X_DIR_INIT(), X_STEP_INIT() etc to setup the pin.

Arduino pins are configured as INPUT by default, so you dont need to set any as input.


Updating the pin name to use a new IO pin is sufficient

Edited 2 time(s). Last edit at 06/25/2026 03:25AM by Dust.

Great, thank you.

A little bit further :
I am still not seeing an output on Arduino pins, nor anything meaningful (to me) on the USB sniffer.
Uploading to a Due, Windows sees it as a 3D printer.
Compiling and uploading to a Mega2560 V3, WIndows just sees it as a USB device.
Either way, no Step output.
With Mega-3, Repetier server console shows:
Mesg:15:21:40.012: Printer reset requested - emergency:false
Mesg:15:21:40.087: Dtr: true Rts: true
Mesg:15:21:40.108: Dtr: false Rts: false
Recv:15:21:43.118: Send init commands because we had no signal from a reset, assuming reset not available.
Recv:15:21:43.120: Response while unconnected:N1 M110*34
Recv:15:21:43.120: N1 M110*34
Mesg:15:21:55.671: Connection started
Mesg:15:21:55.671: Printer reset requested - emergency:false
Mesg:15:21:55.746: Dtr: true Rts: true
Mesg:15:21:55.767: Dtr: false Rts: false
Recv:15:21:58.769: Send init commands because we had no signal from a reset, assuming reset not available.
Recv:15:21:58.770: Response while unconnected:N1 M110*34
Recv:15:21:58.770: N1 M110*34
Mesg:15:22:11.689: Connection started
Mesg:15:22:11.689: Printer reset requested - emergency:false
Mesg:15:22:11.764: Dtr: true Rts: true
Mesg:15:22:11.785: Dtr: false Rts: false
Recv:15:22:14.786: Send init commands because we had no signal from a reset, assuming reset not available.
Recv:15:22:14.788: Response while unconnected:N1 M110*34
Recv:15:22:14.788: N1 M110*34

Please advise

Contradictory information:

"Uploading to a Due, Windows sees it as a 3D printer."
"Compiling and uploading to a Mega2560 V3, WIndows just sees it as a USB device."

You cannot run DUE code on a mega2560 (or vice versa). You need to recompile for each processor.

The log is showing that the board is not responding

The Mega2560 V3 should be seen as a usb serial device.
Depending on what it's using as a UART to USB bridge chip (generally a CH340, FTDI232, or a ATmega8U2/16U2) you may need drivers.

Edited 4 time(s). Last edit at 06/25/2026 03:42PM by Dust.

I have both, and I compiled for both.
I had intended to use the Due for the job but had overlooked the 3.3V aspect. Level converters are on order. I am using industrial Stepper drivers for X, Y, and Z axes. Not sure yet what I will use for the extruder. Limit switches, obviously, are voltage independent .. with care. Low-side switching with a 5V supply wouldn't be good ;-). I am a retired hardware guy. TTL and ECL in my distant past.

Edited 1 time(s). Last edit at 06/26/2026 12:17PM by sbkenn.

I don't know why/how you keep breaking things, but here are some things you need to know about the mega2560 and serial (UART)

It has 4 hardware UARTS [0-3] these are not mappable; they always use the same IO pins. You can use these IO pins for other things; you just loose UART access

The pins are:

UART0 -- TX0 = D01 RX0 = D00 (Connected to UART to USB chip on mega, also on AUX1 on RAMPS)
UART1 -- TX1 = D18 RX1 = D19 (Z-MIN and Z-MAX on RAMPS)
UART2 -- TX2 = D16 RX2 = D17 (AUX4-18 and AUX4-17)
UART3 -- TX3 = D14 RX3 = D15 (Available on some RAMPS-like boards)

In Marlin you need the following for UART 0:

#define SERIAL_PORT 0

Baud rate options: [2400, 9600, 19200, 38400, 57600, 115200, 250000, 500000, 1000000] are applicable as it's a real UART connected to the UART to USB chip (vs CDC USB serial, where baud rate is ignored)
In Marlin you need this with the correct baud rate you're using.
eg

#define BAUDRATE 250000

While using UART 0 you cannot use IO pins 0 or 1.

Edited 2 time(s). Last edit at 06/26/2026 08:55PM by Dust.

Rhetorical: In a C programming book 30 years ago, "He who experiments, learns much but reboots often".
I picked an established 2560 configuration, MEGATRONICS_3 as a starting point. Having found what I think is the top level code,Marlincore.cpp, I suspect the board isn't responding because it is waiting for touch input. I had intended to run the thing from a local PC running repetier rather than having a touchscreen attached to the Arduino.

I have to do my own research. As I do, I may draw a program structure with all the included files listed for publication.

Default Configuration.h and Configuration_adv.h that come with Marlin are for a RAMPS. You literally needed to change nothing at all.

Me again: Hopefully, this is a genuine "bug" but using a Due RAMPS4DUE_EEB , when I select TFT_GENERIC, with driver = AUTO or ILI93421, SanityCheck gives me errors.

#error "TFT_COLOR_UI, TFT_CLASSIC_UI, TFT_LVGL_UI is required for your TFT. Please enable one."
AND
error: #error "Sorry! TFT displays are not available for HAL/DUE."

when I select any of the 3 UI options, PlatformIO switches off the previously selected "TFT generic" and it's options, then

error: #error "TFT_(COLOR|CLASSIC|LVGL)_UI requires a TFT display to be enabled."

If I edit the config file directly and de-comment the UI, I am back to just "TFT displays not available".

I have been able to compile for the Due with SOME displays, but not others, some, not surprisingly, give me pin conflicts.

Is this just missing or misplaced libraries, or something a bit more fundamental. Ideally, I want to use an ILI9341 controlled display as I already have one working on the "Due"

I regenerated the entire Marlin file structure to make sure that I hadn't messed up something else.

Edited 1 time(s). Last edit at 07/01/2026 01:59PM by sbkenn.

Tried compiling in Arduino IDE which said 3 (library) files were missing. Installed them through library manager.

Now, in Visual Studio compile attempt : Marlin-2.1.2.7\.pio\build\DUE\.sconsign311.dblite: No such file or directory.

Doing a quick search indicated that this file is a temporary log of modules that had been compiled recently, however, as the DUE folder didn't exist so I created one.
Rerunning V.S., the system promptly deletes the folder and returns the same error.

Why can a basic TFT test, write to the display with just #include Adafruit_ILI9341.h, but Marlin does things some other way ?

I write these reports substantially to help anyone else experiencing similar problems, as well as working through them, with help.

Edited 1 time(s). Last edit at 07/01/2026 06:01PM by sbkenn.

re TFT_COLOR_UI, TFT_CLASSIC_UI, TFT_LVGL_UI These are the user interfaces available on the TFT screen. You need to pick one. (note TFT_LVGL_UI requires additional flash chip.)

But no one has yet added SPI TFT support to DUE HAL. This is why you get "Sorry! TFT displays are not available for HAL/DUE"
And FSMC_TFT is not an easy option, as not all the pins are broken out.

DUE TFT SPI support has simply not been implemented by anyone yet.

The following functions need to be written and added to the DUE HAL and the deliberate error removed.

void TFT_SPI::init()
void TFT_SPI::dataTransferBegin()
uint32_t TFT_SPI::getID()
uint32_t TFT_SPI::readID()
bool TFT_SPI::isBusy()
void TFT_SPI::abort()
void TFT_SPI::transmit()
void TFT_SPI::transmitDMA()

Edited 6 time(s). Last edit at 07/01/2026 10:37PM by Dust.

Thanks, again.
I suspected that the environment hadn't caught up yet.

I have asked a friend who is an experienced C programmer too look at writing the required files. My brain just says "nope, not going there". I hope to post them to this forum.
Meanwhile, how does this brief program work with Due & TFT, but Marlin doesn't/can't ?

#include <Adafruit_GFX.h>
#include <Adafruit_ILI9341.h>

// Pin definitions
#define TFT_CS   10
#define TFT_DC    9
#define TFT_RST   8   // You can also connect this to 3.3V

// Create display object
Adafruit_ILI9341 tft = Adafruit_ILI9341(TFT_CS, TFT_DC, TFT_RST);

void setup() {
  tft.begin();                 // Start the display
  tft.setRotation (0);
  tft.fillScreen(ILI9341_BLACK); // Clear screen
  
  // Draw a welcome message
  tft.setCursor(20, 20);
  tft.setTextSize(2);
  tft.setTextColor(ILI9341_YELLOW);
  tft.println("ILI9341 Test");

  // Draw a red line
  tft.drawLine(10, 60, 230, 60, ILI9341_RED);

  // Draw a green rectangle
  tft.drawRect(10, 80, 100, 50, ILI9341_GREEN);

  // Filled blue rectangle
  tft.fillRect(120, 80, 100, 50, ILI9341_BLUE);

  // Draw a circle
  tft.drawCircle(60, 180, 30, ILI9341_CYAN);

  // Filled circle
  tft.fillCircle(180, 180, 30, ILI9341_MAGENTA);
}

void loop() {
  // Nothing here for now
}

Edited 1 time(s). Last edit at 07/02/2026 09:39PM by Dust.

That's like asking, "Why can't I use a sledgehammer to do microelectronics?"

You have to fit in with the already existing marlin systems

Your code will display a few simple things, and that is it: no Marlin, no user interface, no supporting multiple display types, no supporting multiple hardware interfaces, no supporting a variety of touch controllers, no supporting different screen resolutions, no supporting multiple different user interfaces, and no supporting a wide variety of microcontrollers.

You can't just add a library like that. Was it written to work cooperatively with other firmware? Or does it use all resources, blocking any concurrent activity, like motion control?

Edited 3 time(s). Last edit at 07/02/2026 09:56PM by Dust.

Take a look and show your friend. [github.com] that I just created

You can see all the changes here: code diff

Note this is completely untested beyond it compiling.
It also only add TFT_SPI, it does not add any touch device support

Edited 4 time(s). Last edit at 07/03/2026 04:21AM by Dust.

Quote
Dust
That's like asking, "Why can't I use a sledgehammer to do microelectronics?"

... what's absolutely doable, if you use a "microscopic" sledgehammer

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

I thank you again for your patience.
Having been mostly away from electronics for 15 years, this project is requiring a major update to my biological firmware !

Almost there, I think !
Having trouble with USB port.
When I upload the f/w, the native USB port ceases to work beyond reporting "Serial g-code 3D printer". A terminal emulator refuses to connect. Erasing the f/w releases it.
Auto build doesn't seem to deal with the dual port nature of the Due.
In order to use the clause below, I have to enable and assign Ports 1 & 2.

Please advise

/**
 * Select a third serial port on the board to use for communication with the host.
 * Currently only supported for AVR, DUE, LPC1768/9 and STM32/STM32F1
 * :[-1, 0, 1, 2, 3, 4, 5, 6, 7]
 */
#define SERIAL_PORT_3 1
#define BAUDRATE_3 250000

Thanks again.
I am also seeing a plethora of warnings when I do get the whole thing to compile, many referring to "delicate pins". I don't know if they are really of any particular relevance !

Edited 1 time(s). Last edit at 07/14/2026 08:25AM by sbkenn.