PlatformIO Support

[hotzenklotz]

Have you considered adding first party PlatformIO build support? I think it would fit very well with the project and it's aim to provide GRBL for several modern hardware stacks. I am a big fan of the Marlin configuration which has to provide build steps for many boards and MCUs. This would be a huge plus for getting up and running with grblHAL reliably and easily.

It tried setting up a platformio.ini tonight, but ultimately failed at getting ESP32 to compile. The general project structure, the connection between some config files are all quite new/unknown to me. It also seems the each driver sub-directory has it's own "style"/structure. It would be really cool to have the same easy of use as Marlin for build grblHAL for different boards.

Perhaps, my first attempts can serve as inspiration.

[platformio]
src_dir = .

[common]
framework = arduino
default_src_filter = 
  +<grbl/*> 
  +<plugins/*>

[common_esp32]
extends = common
platform = espressif32

build_flags = -DGRBL_ESP32
src_filter = 
  ${common.default_src_filter} 
  +<drivers/ESP32/*> 

[env:esp32_lolin_d32]
extends = common_esp32
board = lolin_d32

[env:teensy41]
extends = common
platform = teensy
board = teensy41
upload_protocol = teensy-cli

src_filter = 
  ${common.default_src_filter} 
  +<drivers/IMXRT1062/grblHAL_Teensy4/*>

[terjeio]

Did you use the test branch?

I do not like the Marlin way of making a big project with all the supported prossesors included. grblHAL drivers are all self-contained projects using shared code. If someone wants to add a new driver then this can be done without touching the shared code, and if merged then there is no risk of messing up any other drivers. And if published elsewhere there is no need to include the existing driver code.

The current github organisation of grblHAL is not to my liking, each driver should get its own repository with external references to the shared code. To many ideas too little time...

[hotzenklotz]

No, I tried on master.

grblHAL drivers are all self-contained projects using shared code.

Yes, it certainly feels this way. IMHO, to make matters worse each driver is built/compiled differently which is a big hurdle to get started. For instance, I am still unclear whether the STM32 targets are using the Arduino framework, STM32 Cube, CMSIS or libopencm3? There is also no version pining for each of these. Unfortunately there is very little compilation documentation for each specific driver.

I do not like the Marlin way of making a big project with all the supported prossesors included.

Perhaps I misunderstood the goal of the project then. If grblHAL does not want to provide an abstraction layer to cover a wide range of drivers, how is it any different to the countless (unmaintained) forks and ports of GRBL to some architectures. I was rather happy to see someone "centralize" all these ports and make them easily available and extensible. I don't see how this is any different to goal of Marlin.

If someone wants to add a new driver then this can be done without touching the shared code, and if merged then there is no risk of messing up any other drivers. And if published elsewhere there is no need to include the existing driver code.

Again, having a unified build system like PlatformIO would greatly reduce friction here. Not only could be people easily test their changes against all the other driver but there could also be a CI build step to automatically check exactly that.

The current github organisation of grblHAL is not to my liking, each driver should get its own repository with external references to the shared code.

I see your point but from my experience splitting the project into sub-repository will likely make it even harder to maintain.

[dresco]

I am using PlatformIO to build for Teensy and STM32 here. My initial attempt for ESP32 also failed, but will try that again at some point..

The configuration got a little easier with the test branch, as no longer having to deal with symbolic links & relative paths (will update the wiki page when it gets merged to master).

I do think there would be a benefit to a consistent build experience, regardless of board. My PlatformIO experience is quite limited, so I found it a bit challenging incorporating the existing project structure for each driver.

[hotzenklotz]

I am using PlatformIO to build for Teensy and STM32 here. My initial attempt for ESP32 also failed, but will try that again at some point.

Do you have a link to that?

[terjeio]

If grblHAL does not want to provide an abstraction layer to cover a wide range of drivers, how is it any different to the countless (unmaintained) forks and ports of GRBL to some architectures.

It does, the core and plugin code is 100% separate from the driver code and will continue to be so. Keeping it this way is a must for me. Downloading a driver should pull in the core and neccesary plugin code automatically just as I do from the master subversion repository that I currently keep behind the scenes. As I understand it github can be set up to do the same.

Having each driver in a separate repository will IMO making them easier to select, document and maintain. I just created an organization to do that - grblHAL should not be a part of my private account when moving forward.

Different build systems should be supported, however I am not keen to switch over to a single one such as PlatformIO. CI would be nice to get up and running, but I am not able to do everything on my own. Are you willing to join?

[hotzenklotz]

Are you willing to join?

Sure, I am happy to pitch in with PIO/CI. However my experience working with embedded development is somewhat limited. I tend work a lot more in the Python/JS world.

I am using PlatformIO to build for Teensy and STM32 here. My initial attempt for ESP32 also failed, but will try that again at some point.

Can you share the PIO config file for STM32?

[dresco]

Can you share the PIO config file for STM32?

Sure, for the STM32 build, I created a new PlatformIO project folder, and symlinked to the grblHAL/drivers/STM32F4xx folder from the source tree.

One thing to note: I needed to rename startup_stm32f401ccux.S with an upercase extension, see https://github.com/platformio/platform-ststm32/issues/332

My platformio.ini file contents are;

[platformio]
src_dir = STM32F4xx

[env]
build_flags =
    -ISTM32F4xx/Middlewares/ST/STM32_USB_Device_Library/Class/CDC/Inc
    -ISTM32F4xx/Middlewares/ST/STM32_USB_Device_Library/Core/Inc
    -ISTM32F4xx/Drivers/CMSIS/Device/ST/STM32F4xx/Include
    -ISTM32F4xx/Drivers/STM32F4xx_HAL_Driver/Inc
    -ISTM32F4xx/Drivers/CMSIS/Include
    -ISTM32F4xx/Inc
    -DOVERRIDE_MY_MACHINE
    -DBOARD_GENERIC_UNO
    -DN_AXIS=3
    -DUSB_ENABLE
    -DSTM32F411xE
    -DNUCLEO_F411
    -DUSE_HAL_DRIVER

board_build.ldscript = STM32F4xx/STM32F401CCUX_FLASH.ld

[env:nucleo_f411re]
platform = ststm32
board = nucleo_f411re
monitor_speed = 115200

[dresco]

For ESP32, I didn't get very far. I copied the whole source tree into the root of the PlatformIO project folder, and tried to build with the following config;

[platformio]
src_dir = .

[env:az-delivery-devkit-v4]
platform = espressif32
board = az-delivery-devkit-v4
framework = espidf

But it errors when processing the CMakeLists.txt so I stopped there (was only trying out of curiosity, didn't really have a use for a ESP32 build at the time)..

[raininja]

I've convinced this to build in vscode/pio and it's all about the platformio.ini

iosender running grblhal

[brianredbeard]

Since it's related to this, there's now a platformio.ini definition in the iMXRT1062 driver. I've tested it out quite a bit: both making sure it's repeatable by starting from a fresh checkout, but also using it with my day-to-day checkout.

Right now it may require some manual overrides if you wish to stray too far from the default Teensy 4.x pin maps provided, but it should make the "getting started" use case pretty easy. Commentary with improvements/suggestions for the documentation would be greatly appreciated.

[noahwilliamsson]

FWIW, I've posted some initial PRs to add PlatformIO build support to STM32F1xx (https://github.com/grblHAL/STM32F1xx/pull/6) and STM32F4xx (https://github.com/grblHAL/STM32F4xx).