Add Anycubic I3 Mega with BLTouch, Reversed 2208s

[hub-jba]

Requirements

• A version of the Marlin bugfix-2.0 with this PR merged into it: Anycubic I3 Mega (AI3M) extensible ui implementation Marlin#18655

Description

This adds two config examples for the Anycubic I3 Mega (AI3M), one that is the default set up using Marlin bugfix-2.0.x branch (AI3M_stock), and one with reversed TMC 2208's and a bltouch enabled (AI3M_BLTouch_reversed2208).

I have enabled Linear Advance and Manual Mesh Levelling in the stock configs (obviously ABL enabled in the BLTouch config). These configs are based on the ones set up in this Marlin 1.1.9 fork but have been adapted to the Marlin 2.0 extensible UI setup: https://github.com/davidramiro/Marlin-Ai3M

Benefits

AI3M, on Marlin 2.0, using extensible UI

Related Issues

These configs go with the AI3m extensible UI changes in this PR: MarlinFirmware/Marlin#18655

[thinkyhead]

This won't compile unless a CONTROLLER_FAN_PIN is provided. Did you define a custom one, or should the USE_CONTROLLER_FAN option be disabled?

[hub-jba]

It's defined in line 47 of pins_TRIGORILLA_14.h for me, so I suspect it needs to be conditionally defined somewhere in the configs?

#define CONTROLLER_FAN_PIN  		              TG_FAN1_PIN

[hub-jba]

The more I think about it, the more it makes sense that that line be pulled out of the pins_TRIGORILLA_14.h file and moved into this config file. Is that what should happen here?

[thinkyhead]

that line be pulled out of the pins_TRIGORILLA_14.h file and moved into this config file

Done.

[thinkyhead]

Note that Marlin does not contain any support at this time for ANYCUBIC_TFT_MODEL or ANYCUBIC_TFT_DEBUG so that code will need to be integrated into Marlin first.

[hub-jba]

Yep,

Those two defines are used in my other PR into the MarlinFirmware core over at this PR: MarlinFirmware/Marlin#18655

[hub-jba]

that line be pulled out of the pins_TRIGORILLA_14.h file and moved into this config file

Done.

Does this mean that we need to pull that definition from the pins_TRIGORILLA_14.h definition in the other change request, or at least wrap it in an #ifndef call? I didn't think you could have two #defines of the same macro with in the same compile without undefining it at one point?

[thinkyhead]

Those two defines are used in my other PR

I figured there must be a companion piece.

[thinkyhead]

Does this mean that we need to pull that definition from the pins_TRIGORILLA_14.h definition in the other change request

If it's the common pin that would be used, it is fine to leave in pins, and then it doesn't need to be defined in the config.

[hub-jba]

Does this mean that we need to pull that definition from the pins_TRIGORILLA_14.h definition in the other change request

If it's the common pin that would be used, it is fine to leave in pins, and then it doesn't need to be defined in the config.

That pin shows up in many pins files so I think it is a common pin, but then why did it break the build for you?

[thinkyhead]

That pin shows up in many pins files so I think it is a common pin, but then why did it break the build for you?

I built the configs against current code, not your PR, which I forgot to grab.