3D printer board support

[hasenbanck]

Since Marlin 2.0 will support many different MCU architectures beside the AVR, STM32 MCU support is also in the work. There is currently planning ongoing to have one HAL for all STM32 boards.

The first such board was REMRAM V1, but there are already other board on the market, which will need support for Marlin for this Arduino core (since this core is the only core, that supports all STM32 targets).

This issue should simply act as a preparation, for future board definition request that will come (and of which I will most likely write quite some).

I think it would be best if remove the "REMRAM" top-level category and add a general "3rd party boards" or "3D printer board" category, so that we can group these board better together.

For reference:
MarlinFirmware/Marlin#11750 and MarlinFirmware/Marlin#7076

[hasenbanck]

Currently there are the following boards that would need an additional variant:

• Armed
• Chitu3D V3.9
• Malyan M200 (There are various motherboard versions I think)
• GTM32_PRO_VB
• GTM32_MINI
• STEVAL-3DP001V1
• RUMBA32
• PicoPrint

There is also the "PrntrBoard" by @ghent360, but that is using the STM32F446 NUCLEO-64 as a platform and is already supported.

@fpistm Do you might have access to the STEVAL-3DP001V1 board? Done

@Phr3d13 @xC0000005 Do you have some of the boards available? I could write the board variants if you could assist in testing them.

[ktand]

I would like to add my board, "Armed", to that list. It's based on STM32F407 and running Marlin 2.0.x with the STM32 core. Karl Den tor 4 okt. 2018 16:54Nils Hasenbanck <notifications@github.com> skrev:

…

Currently there are the following boards that would need an additional variant: - Chitu3D V3.9 - Malyan M200 (There are various motherboard versions I think) - GTM32_PRO_VB - GTM32_MINI - STEVAL-3DP001V1 There is also the "PrntrBoard" by @ghent360 <https://github.com/ghent360>, but that is using the STM32F446 NUCLEO-64 as a platform and is already supported. @fpistm <https://github.com/fpistm> Do you might have access to the STEVAL-3DP001V1 board? @Phr3d13 <https://github.com/Phr3d13> @xC0000005 <https://github.com/xC0000005> Do you have some of the boards available? I could write the board variants if you could assist in testing them. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#347 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AQ8NJAWN155rLnHo1I6vi86gXBiH9tn-ks5uhiFBgaJpZM4XCjuQ> .

[hasenbanck]

Great. But I guess you are doing the board variant yourself? You can ping me if you have any questions / problems.

[ghent360]

Are we doing the right thing?

If I compile Marlin for AVR, I don't have to choose every single RAMPS offspring board ever created in the Arduino IDE. Somehow they manage not to require a board variant for the plethora of AVR based printer controllers.

What are we trying to achieve that is different in this case, so creating a board configuration would actually be beneficial?

Wouldn't it be simpler if we create "generic" variants that correspond to popular CPU packages and number the pins after the actual pin numbers on the chip.

[ktand]

I guess every board maps their PWM, I2C and SPI pins etc. differently, probably requiring variants for every board. Karl Den tor 4 okt. 2018 19:04ghent360 <notifications@github.com> skrev:

…

Are we doing the right thing? If I compile Marlin for AVR, I don't have to choose every single RAMPS offspring board ever created in the Arduino IDE. Somehow they manage not to require a board variant for the plethora of AVR based printer controllers. What are we trying to achieve that is different in this case, so creating a board configuration would actually be beneficial? Wouldn't it be simpler if we create "generic" variants that correspond to popular CPU packages and number the pins after the actual pin numbers on the chip. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#347 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AQ8NJA9-N08EZkPowlBJXqaQBpWQXvnCks5uhj-xgaJpZM4XCjuQ> .

[hasenbanck]

Yes, we are indeed doing the right thing. AVR based boards most often pin compatible with their big Arduino cousin and that's why you often get compability out of the box. As soon as you deviant from that (like the Rambo series of boards) you need also another board definition.

STM32 chips and boards are not that uniform. For example: I use a similar chip from the STM32F765 family then another custom board. But I can't use that variant definition, since even when we use the same CPU number, we use different versions of it (I use the VI with 2 MB Flash). The other board also uses different PWM outputs and we have to use for that reason different timers (which could also lead to the need to user different SPI / I2C peripherals).

And since we have different boards out in the wild, which use different peripherals etc, we have to support them somehow (Since we can't change their silicon).

[chrissbarr]

I'm working on two boards built around the STM32F446VET6: RUMBA32 & PicoPrint.

I have everything running decently with STM32GENERIC + Marlin 2.0.x + STM32F4 HAL, but I'm looking to swap them over to this core so I can move them towards the more unified STM32 Marlin HAL you've been working on @hasenbanck.

I've only started testing out this core yesterday, so not sure if I'll run into trouble yet - but in any case, I think a folder for 3D printer boards is a good idea, as it's sure to be a list that will grow fairly quickly.

[xC0000005]

Seconding this with a real example. The M200 boards (STM32F107 and STM32F070) require different loading offsets than a bluepill because they have a proprietary bootloader, and require some different startup code (The STM32F103 startup code doesn’t load SP by default, because the processor would, but the bootloader doesn’t do it, so the startup code needs to). V1 has a pullup transistor on PB9 that’s required for USB. Sure we could use the generic variants, but that would involve changing their behaviors. Or we could add specific variants and let the bluepills continue to use PB9 for whatever they do while the M200s use it to enable USB, and so on. Variants are good, though they do come with some baggage.

…

On Oct 4, 2018, at 1:42 PM, Nils Hasenbanck ***@***.***> wrote: Yes, we are indeed doing the right thing. AVR based boards most often pin compatible with their big Arduino cousin and that's why you often get compability out of the box. As soon as you deviant from that (like the Rambo series of boards) you need also another board definition. STM32 chips and boards are not that uniform. For example: I use a similar chip from the STM32F765 family then another custom board. But I can't use that variant definition, since even when we use the same CPU number, we use different versions of it (I use the VI with 2 MB Flash). The other board also uses different PWM outputs and we have to use for that reason different timers (which could also lead to the need to user different SPI / I2C peripherals). And since we have different boards out in the wild, which use different peripherals etc, we have to support them somehow (Since we can't change their silicon). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#347 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AeppcaL9-o4cL9P5f2-IPE9qnMti38mCks5uhkiSgaJpZM4XCjuQ>.

[xC0000005]

I believe I own nearly every revision of the M200 V1 and V2 boardsets, and I’d not only be happy to test, I can assist in the varianting when I’m at home instead of traveling.

…

On Oct 4, 2018, at 10:54 AM, Nils Hasenbanck ***@***.***> wrote: Currently there are the following boards that would need an additional variant: Chitu3D V3.9 Malyan M200 (There are various motherboard versions I think) GTM32_PRO_VB GTM32_MINI STEVAL-3DP001V1 There is also the "PrntrBoard" by @ghent360 <https://github.com/ghent360>, but that is using the STM32F446 NUCLEO-64 as a platform and is already supported. @fpistm <https://github.com/fpistm> Do you might have access to the STEVAL-3DP001V1 board? @Phr3d13 <https://github.com/Phr3d13> @xC0000005 <https://github.com/xC0000005> Do you have some of the boards available? I could write the board variants if you could assist in testing them. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#347 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AeppcWkaKsr_5P2e59x5Lky3mAw-II4Bks5uhiFDgaJpZM4XCjuQ>.

[hasenbanck]

@xC0000005 Great to hear. I will wait until you returned and looked into the matter yourself. Since you already wrote the variants for the STM32generic core, it should be faster when you do it yourself (my vacation is soon over, so my time budget will decrease fast soon).

[Phr3d13]

I have both the gtm32 variants. I'd be happy to help whenever you need me.

[hasenbanck]

@Phr3d13 Did you already use those boards with the old HAL with Marlin 2.0? I kinda need some documentation about the pin / peripheral configuration to start with. Do you happen to know if there is some documentation about these topics?

[Phr3d13]

Board support was only partially done. Geeetech has a lot of good info on the boards, the only down side is that they use their own firmware on the boards (Smartto) and not Marlin. After work, I'll comment with specific links.

[Phr3d13]

Smartto - This is their firmware for both of their stm32 boards.
GTM32 Pro VB - Circuit diagram for the PRO VB board
GTM32 Mini - Circuit diagram for the Mini board
They don't have anything like a pins.h file anywhere. pins are defined in each relevant file, IE endstop pins are defined in Smartto-IAR/src/User/endstop.h, etc

[hasenbanck]

I think those files and the information in the pin definition in Marlin should be enough. I will look tomorrow into it!