BigTreeTech GTR V1.0 / Support 8 extruders, heaters, temp sensors, fans

[yangwenxiong]

Requirements

Good afternoon!
1、Add new 3D printer motherboard BIGTREE GTR V1.0
2、Maximum support for 6 - way extruder, 6 - way fan, 2 - way K thermocouple, external EEPROM

Description

1、Marlin/src/module/temperature.cpp，
The definition of MAX31865 Pin in this file is not subject to change
2、Marlin/src/gcode/control/M42.cpp
Marlin/src/inc/Conditionals_post.h
Firmware adds fan 3 fan 4 fan 5 support

3、Marlin/src/libs/softspi.h
Modify K - type thermocouple initialization
4、Marlin/src/pins/stm32/pins_BTT_GTR_V1_0.h
Marlin/src/pins/pins.h
Add the GTR 3d-printed motherboard pin file
5、platformio.ini
Added environment for GTR 3d-printed motherboard

Benefits

1 、Improve 6 - way fan 6 - way extruder
2 、Supports k-type thermocouple MAX31855 MAX6675
Sensor self-detection can be achieved by Max31855
4 、Default on-board SD card reads Gcode files
3 、If you have any questions, please leave a message. Thank you

Related Issues

[yangwenxiong]

Restore the pins BTT GTR v1.0.h file annotation based on the error

[thinkyhead]

There are some glaring differences between the two printers

@andraisr - Please provide us with correct configurations. Please don't add noise to pull requests which are only for developer use. The correct place to report this is at
https://github.com/MarlinFirmware/Configurations/issues/new

[thinkyhead]

@yangwenxiong — You seem to have deleted the pins file. Are you planning to supply a new one?

[thinkyhead]

I have fixed up this PR and corrected the target. All PRs should be directed to bugfix-2.0.x.

To get the updated commits in your working copy:

git fetch origin
git checkout 2.0.x
git reset --hard origin/2.0.x

[thinkyhead]

Sorry, I had to mess with your repository. Your 2.0.x branch now contains upstream/bugfix-2.0.x plus your changes. After this PR is merged you will need to repair your 2.0.x branch following a command-line procedure that I will describe at that time. To avoid this problem in the future:

• Start with the correct branch (bugfix-2.0.x) and make sure to sync it with the latest upstream version before using it as the basis for new changes. This way you are working with up-to-date source code.
• Always make a copy of the branch you are modifying and give it a descriptive name. For example you could call this one "adc_adjustable_debounce_PR". This prevents your copies of our upstream branches from becoming corrupted or blocked from use because they are tied to a PR.

This PR may be in review for a while. If you need to use the 2.0.x branch in your fork as the basis for other changes in the meantime, be very careful to use the upstream/2.0.x reference as your starting-point and not the reference to your working copy.

[yangwenxiong]

ok!

…

---Original--- From: "Scott Lahteine"<[email protected]&gt; Date: Mon, Jan 20, 2020 16:01 PM To: "MarlinFirmware/Marlin"<[email protected]&gt;; Cc: "Mention"<[email protected]&gt;;"yangwenxiong"<[email protected]&gt;; Subject: Re: [MarlinFirmware/Marlin] BIGTREE_GTR V1.0 (#16595) @thinkyhead commented on this pull request. In Marlin/src/pins/stm32/pins_BTT_GTR_V1_0.h: &gt; + #endif + + // Alter timing for graphical display + #if HAS_GRAPHICAL_LCD + #define BOARD_ST7920_DELAY_1 DELAY_NS(96) + #define BOARD_ST7920_DELAY_2 DELAY_NS(48) + #define BOARD_ST7920_DELAY_3 DELAY_NS(600) + #endif + + +//#define DOGLCD_CS PB12 +//#define DOGLCD_A0 PA8 +//#define LCD_PINS_DC PB14 +//#define DOGLCD_MOSI PB15 + +#endif // HAS_SPI_LCD Thanks! There is no need to do a second Pull Request. Commits you add to your branch will be added to this one. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[tpruvot]

i think that require a cast to pin_t(pin) to use the HAL digitalWrite()

[tpruvot]

Marlin/src/HAL/HAL_AVR/HAL.h:73:typedef int8_t pin_t;
Marlin/src/HAL/HAL_ESP32/HAL.h:82:typedef int16_t pin_t;
Marlin/src/HAL/HAL_STM32F1/HAL.h:201:typedef int8_t pin_t;
Marlin/src/HAL/HAL_STM32/HAL.h:153:typedef int16_t pin_t;

[tpruvot]

but maybe i make a confusion with analogWrite... i just see this one

Marlin/src/HAL/HAL_LINUX/include/Arduino.h:104:void digitalWrite(pin_t, uint8_t);

[thinkyhead]

digitalWrite is of course the Arduino "slow" pin write routine, which may be fully optimized on some platforms, but on AVR we bypass it and use our FastIO WRITE routine whenever possible. Since this is a libs entry it should use the fastest pin manipulation technique available in the headers (e.g., <Arduino.h>) it depends on. If the ARM platforms' digitalWrite variants are just doing the same as we were here, then this change is fine.

[MangaValk]

Shouldn't this be gtr?

[thinkyhead]

It depends on whether the framework contains that board definition. It might be too soon…?

[sjasonsmith]

I'm not very fluent in these pins files, but I believe this is allowing PWM on pins tied to timers used for other purposes. If hardware PWM is actually used on these pins, something will likely misbehave.

Of the newly uncommented timers, I see potential conflicts with two of them:

TIM2 - Assigned to TIMER_TONE in variants.h
TIM5 - Assigned to TIMER_SERVO in variants.h

[thinkyhead]

Is this something that needs to be addressed by using different variants.h files, or should changes be made here?

[sjasonsmith]

That depends on whether the GTR is a superset of the SKR Pro, or if their pin assignments are completely different. If it’s a superset then a single configuration should be possible for both, but the timer numbers will probably need to change to avoid conflicting with PWM pins.

I’m inclined to think they should be separate, especially once support is added for the expansion port/board.

[thinkyhead]

I agree that it will be easier to manage if it can have its own variant.

[GhostlyCrowd]

Just wanted to point out that this change to PeripheralPins.c appears to double define the Servo and Z min PWM (PA1_PA_2) pin timers for the SKR Pro to TIM2 and TIM5. I don't know the consequences of this as I'm not that savvy but I've been chasing BLTouch issues on the latest bug fix and stumbled upon this in my investigations.

[GhostlyCrowd]

@thinkyhead @sjasonsmith

Just an update, after commenting this out as it timer overlaps I've not had a single bltouch failure since on the SKR Pro.

Again im not a pro at this, but i had tracked down my BLtouch issues to either writing to sd or when the speaker makes tones, and it hasn't happened since I undefined the double defining of PA_1 and PA_2 (should be in TIM5 but were then redefined as TIM2)

Unless im not understanding this right and its all in my head and my BLtouch is just waiting to go rogue again.

[sjasonsmith]

Just an update, after commenting this out as it timer overlaps I've not had a single bltouch failure since on the SKR Pro.

@GhostlyCrowd, do you know if there is an open issue you can add that detail to with a link back to this? That is unless you are going to put together a pull request to take care of it.

[GhostlyCrowd]

Just an update, after commenting this out as it timer overlaps I've not had a single bltouch failure since on the SKR Pro.

@GhostlyCrowd, do you know if there is an open issue you can add that detail to with a link back to this? That is unless you are going to put together a pull request to take care of it.

@sjasonsmith No open issue, I'm working on educating my self to put in a PR but maybe it would be more logical to open an issue until I educate my self on how to PR.

Because this may require splitting the BTT GTR and the BTT SKR Pro, thats going obove my level of skill.

[yangwenxiong]

In principle, there are 14 stm32f407xx timers, excluding some used for other functions of the timer, other timers, as long as the pin with Timerx_chx can be configured as PWM output, but it seems that I can not, some timers are configured with PWM output but no output. At the same time, I found that PWM port mainly set in the first several timers, IO port does not exceed PA,B,C,D these four groups of IO timer. You can verify that

…

---Original--- From: "Jason Smith"<[email protected]&gt; Date: Tue, Jan 21, 2020 10:29 AM To: "MarlinFirmware/Marlin"<[email protected]&gt;; Cc: "Mention"<[email protected]&gt;;"yangwenxiong"<[email protected]&gt;; Subject: Re: [MarlinFirmware/Marlin] BIGTREE_GTR V1.0 (#16595) @sjasonsmith commented on this pull request. In buildroot/share/PlatformIO/variants/BIGTREE_SKR_PRO_1v1/PeripheralPins.c: &gt; - //{PA_1, TIM2, STM_PIN_DATA_EXT(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF1_TIM2, 2, 0)}, // TIM2_CH2 - //{PA_2, TIM2, STM_PIN_DATA_EXT(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF1_TIM2, 3, 0)}, // TIM2_CH3 + {PA_1, TIM2, STM_PIN_DATA_EXT(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF1_TIM2, 2, 0)}, // TIM2_CH2 is bltouch analog? + {PA_2, TIM2, STM_PIN_DATA_EXT(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF1_TIM2, 3, 0)}, // TIM2_CH3 is bltouch analog? + //{PA_1, TIM5, STM_PIN_DATA_EXT(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF2_TIM5, 2, 0)}, // TIM5_CH2 + //{PA_2, TIM5, STM_PIN_DATA_EXT(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF2_TIM5, 3, 0)}, // TIM5_CH3 I'm not very fluent in these pins files, but I believe this is allowing PWM on pins tied to timers used for other purposes. If hardware PWM is actually used on these pins, something will likely misbehave. Of the newly uncommented timers, I see potential conflicts with two of them: TIM2 - Assigned to TIMER_TONE in variants.h TIM5 - Assigned to TIMER_SERVO in variants.h — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[thinkyhead]

Rebased to resolve some conflicts. I've also added changes to accommodate up to 8 heaters, temp sensors, and fans, and thus up to 8 extruders.

To get the updated commits in your working copy:

git fetch origin
git checkout 2.0.x
git reset --hard origin/2.0.x