-
Notifications
You must be signed in to change notification settings - Fork 90
Home
GrblHAL is a rewrite of grbl1.1 aimed at 32-bit processors. A hardware abstraction layer (HAL) has been introduced in order to completely separate the core grbl code from the processor/hardware specific code (driver coder). The driver code is accessed from the core via function pointers and the driver announces implemented functionality via these and flags in the HAL structure.
This approach has resulted in a "clean" grbl core that is not "contaminated" by any processor/hardware specific code. Changes/bug fixes to the core are thus instantly available to all drivers, there should be no need to touch it for updates...
More than 10 drivers for a range of processors are currently available, these with varying functionality depending on available resources like number of GPIO pins and processor peripherals. The driver "tell" the core about what is available via the HAL structure and the core adjusts itself accordingly. Writing additional drivers is relatively easy ase there is no need to tinker with the core - a driver might be implemented in a single separate file.
The use of function pointers has some nice (side)effects, one is that the driver can change pointers to point different code dynamically. One example is stream handling: normally the driver provides the standard serial stream for communication, but may change this on the fly to eg. instead read data from a SD card. This can also be used to provide additional streams such as over BlueTooth, Wifi or Telnet - all with no changes to the core.
The HAL API also provides optional function pointer entries (hooks) allowing the driver to extend settings, add driver specific M-codes, extent the real-time report, add real-time processing etc. etc. Again, no changes to the core is needed for this.
A number of "plugins" are provided for the driver layer: SD-card support, Trinamic driver support and I2C keypad.