search

gnea / grbl

An open source, embedded, high performance g-code-parser and CNC milling controller written in optimized C that will run on a straight Arduino
https://github.com/gnea/grbl/wiki
Other
4.04k stars 1.61k forks source link

Portability Experiments (ARM M4) #92

Open MechaSteve opened 7 years ago

MechaSteve commented 7 years ago

I have started looking at porting grbl to an ARM M4 platform and I have found a few clear area to improve overall portability. I think a good way to port to various platforms would be to use the same .h for the hardware dependent modules and limit all changes to the .c implementation. (Aside from the cpu_map.h file)

DISCLAIMER: these are my very initial findings and will almost certainly be revised, modified, appended and/or discarded. I am in no way an expert on any of this. (or anything really :) )

GPIO Init: The current code has lots of very similar GPIO initialization scattered throughout. There should be a set of general purpose GPIO initialization functions. These should use macros defined in the form FUNCTION_PORT, FUNCTION_BIT . The init functions are not time critical, and can take a little bit of time for simpler logic. There should be GPIOinitInput( ulPort, ulPin), GPIOinitOutput( ulPort, ulPin), and lightweight GPIOset, GPIOclear, and GPIOtest macros for writing and reading individual pins.

Operator Panel / Control Pins: These should really get their own operator.h/operator.c include module. The .h should define a bit packed control word and a getControlWord(void) function.

Interrupts: Reorganizing all ISRs into one include could also simplify portability. The .h should define which interrupt events should call which functions in other modules. i.e. The pin change interrupt for any of the limit switches should call a function OnLimitEvent(uint8 limitState) in the limit module, and then clear all pending limit interrupts. All pin change interrupts can funnel down to the same ISR which can then select a specific handler based on pin mappings.

Serial: Similar to the operator panel, it would be good to separate the platform dependent peripheral functions from the agnostic buffer functions. This would also simplify future modifications using USB, networking, or other communication interfaces.

Stepper.c As expected, this is the largest concentration of HW dependent code. The better the interface is to this module, the easier it will be to experiment with different algorithms and other motor types.

Atomic Set/Reset: Refactor these into a HW specific nuts and bolts area. Many Arm processors have a bit-banded memory that allow for true atomic set/clear of individual bits.

_delay_ms / _delay_us : These should be eliminated and replaced with event, polling, and interrupt driven logic.

Schildkroet commented 6 years ago

Already done: https://github.com/Schildkroet/GRBL-Advanced