Commit files for Flexi-HAL support.

[andrewmarles]

Been working on this board for a while and it is ready for release. Design files will be posted shortly.

https://github.com/Expatria-Technologies/Flexi-HAL

[terjeio]

I have added your code manually. The code for fast mode I2C has been merged with i2c.c to make it generally available. IMO the board specific code has to be sorted out as it looks like it is complemented by plugin code. For flexibility it should be made generic so that the plugin code can be used by other boards/drivers? Or if the plugin code is board specific it should be added to flexi_hal.c?

I have also added the board to the Web Builder with this definition and made the changes needed to enable compilation with the STM32CubeIDE.

[andrewmarles]

FWIW the plugin code is here:

https://github.com/Expatria-Technologies/Plugin_I2C_keypad/tree/Remote_MPG_Support

I will likely rename the above as things have moved well beyond the original I2C keypad plugin for GRBLHAL and I do not think that the current efforts are easily merged back without breaking existing implementations.

I agree the plugin should be fully generic - the intent is to allow for encoder counts (as well as other pendant/DRO info) to be exchanged with a remote MCU to facilitate MPG jogging. Still very much WIP. I know dresco is working on similar code and I am definitely watching his development with interest. I don't believe any of the my code needs to be board specific, though right now I am focused on interfacing via I2C in future an interface via CAN or Modbus should be straightforward. Probably the read/write functions should be defined in the plugin and then implemented in the driver code depending on what interfaces are available? I can try to further genericize this as the pendant plugin is further developed.

Regardless, thank you for adding the board and high-speed I2C code.

[terjeio]

I will likely rename the above as things have moved well beyond the original I2C keypad plugin for GRBLHAL and I do not think that the current efforts are easily merged back without breaking existing implementations.

Will it be possible to split your modified keypad plugin into separate plugins? E.g. the could the macro code subscribe to the keypad.on_keypress_preview event to extend the "standard" keypad plugin? And would it be possible to split out the status info code as well? New events is needed for that?

Probably the read/write functions should be defined in the plugin and then implemented in the driver code depending on what interfaces are available?

IMO ideally the interfaces should be defined in the core, implemented in the driver and used by plugins as needed.